Job Step

Origin & evolution

The step structure comes from Anthony Ulwick's work on Outcome🏆OutcomeStrategyA desired business or user outcomeView reference →-Driven Innovation and was set out in his Harvard Business Review article The Customer-Centered Innovation Map (Bettencourt and Ulwick, 2008). Analysing hundreds of jobs, they found that every functional job follows the same skeleton of eight universal steps: define, locate, prepare, confirm, execute, monitor, modify, and conclude. The claim is that the steps are solution🔧SolutionDiscoveryA proposed approach to address an opportunityView reference →-agnostic and stable: the technology a customer uses changes constantly, but the structure of the job they are doing does not.

The insight🔦InsightUser ResearchA synthesised finding from researchView reference → that makes the map useful is where it directs attention. Most product effort concentrates on the execute step, the moment of doing the core task☑️TaskProduct SpecificationA unit of work within a story or epicView reference →, while the unmet needs that competitors🥊CompetitorMarket IntelligenceA competing product or companyView reference → miss often hide in the steps around it: the preparation nobody streamlined, the monitoring nobody made visible, the conclusion left messy. Mapping the steps turns "improve the product" into a search across a fixed structure for the stage where customers struggle most.

How it works in practice

A team builds expense software and assumes the job is "submit an expense", treating execute as the whole game. Mapping the universal steps reframes it. Locate is hunting for the lost receipt. Confirm is checking the claim won't be rejected by policy. Monitor is wondering, for three weeks, whether reimbursement is coming. The execute step, filling in the form, was already fine. The real friction lived in locate and monitor, and that is where the next two features⭐FeatureProduct SpecificationA product capability or featureView reference → go: receipt auto-capture and a live status tracker. The step map moved the roadmap🛣️RoadmapProduct SpecificationA strategic plan of features and milestonesView reference → off the obvious stage and onto the painful ones.

Job step vs. its neighbours

• Job is the whole objective🏁ObjectiveStrategyA strategic goal (OKR)View reference → the customer is pursuing. A job step is a constituent stage of it; the edge job_decomposes_into_job_stepJobdecomposes intoJob Stephierarchy makes that part-of relationship explicit.
• Need is what the customer requires to make progress at a given point. Needs are precisely what surface at specific steps, which is why the map is a discovery tool rather than a flowchart.
• Journey step🪜Journey StepExperience DesignA single step in a user journeyView reference → describes a stage in the customer's experience with a particular solution, tied to touchpoints👆TouchpointCustomer SuccessA customer interaction touchpointView reference → and channels. A job step is solution-agnostic; it would still exist if your product, and every competitor, vanished tomorrow.

In the graph

In the Unified Product Graph, a job step sits in the users region and hangs off its parent through job_decomposes_into_job_stepJobdecomposes intoJob Stephierarchy. Breaking a job into its steps gives needs and pain points a precise home: they anchor to the stage where they bite, not to a vague whole-job statement. That structure keeps the discovery honest, because a job whose steps carry no needs is a job nobody has actually examined, and the graph shows the gap rather than hiding it.