Key Principle
A job map decomposes a core functional job into universal process steps describing what the customer is trying to accomplish (goals), not what they currently do (actions). All jobs share up to eight universal steps: define, locate, prepare, confirm, execute, monitor, modify, conclude. Each step then generates desired outcome statements — specially constructed need statements with a mandatory structure: direction + metric + object + context (e.g., "minimize the time it takes to get the songs in the desired order for listening"). This structure ensures every outcome is measurable, solution-agnostic, stable over time, and controllable by the company.
"Making the core functional job the unit of analysis is the cornerstone of successful innovation." — Ulwick, Chapter 4
The core functional job must be stated as verb + object + contextual clarifier, purely functional and solution-free. The job map is then built against this anchor, and desired outcomes are captured at each step, yielding a typical inventory of 50-150 outcomes per job (200+ in complex markets like healthcare).
Why This Matters
Without a job map, teams default to customer journey maps, which trace the consumption chain (buy, receive, set up, use) and are therefore solution-dependent. Microsoft discovered that Software Assurance "was only really engaging with the customer in one tiny piece of their job — the purchase of the software. But this was just part of a much bigger challenge that they faced" (Chapter 5). A journey map defined by existing product touchpoints would never have revealed that gap. The job map, being solution-independent, exposes the full scope of what the customer is trying to get done.
Desired outcome statements convert qualitative "voice of the customer" data into quantifiable units that can be scored for importance and satisfaction across a population. Without this structure, teams collect statements like "I want it to be easier" — data that sounds actionable but cannot be compared, ranked, or verified. Two teams reading the same qualitative data reach different conclusions about what to build. The structured outcome statement eliminates this ambiguity and feeds directly into the opportunity algorithm for prioritization.
Good Examples
Music listening outcomes (Chapter 2): "Minimize the time it takes to get the songs in the desired order for listening" and "minimize the likelihood that the music sounds distorted at high volume." Both follow the direction (minimize) + metric (time/likelihood) + object (songs in order/music distortion) + context (for listening/at high volume) structure. They are solution-agnostic — equally valid whether the customer uses vinyl, CDs, or streaming.
Circular saw outcome (Chapter 4): "Minimize the likelihood the cut goes off track" — importance 7.4, satisfaction 2.8, opportunity score 12.0. This outcome surfaced only because the job map decomposed "cut a piece of wood in a straight line" into its constituent steps. At the execute step, this underserved outcome became visible and quantifiable.
Bosch CS20 (Chapter 5): Segmentation of the circular saw job map revealed a 30%+ segment of finish/advanced carpenters with 14 unmet outcomes (opportunity scores >10). The market appeared mature and commodity-like when scores were averaged. The job map plus outcome-based segmentation exposed hidden demand invisible to conventional analysis.
Counterpoints
Scope error — too narrow (Chapter 4): A stove-top kettle maker who defines the job as "boil water" misses the real job: "prepare a hot beverage for consumption." The narrow job map omits steps like selecting the beverage, measuring ingredients, and optimizing flavor — leaving the company vulnerable to Keurig, which addressed the entire job on a single platform.
Scope error — too broad (Chapter 4): Defining the job too broadly yields an unmanageable number of outcomes spread across too many segments. The job map becomes non-actionable because there are too many steps to prioritize and too many segments to serve.
Product-centric job elicitation (Chapter 4): Asking customers "what job did you hire that product to do?" anchors the job map to the existing solution rather than the underlying goal. Ulwick warns: "It is incorrect to ask a customer, 'What job did you hire that product to do?' as this may not reveal the entire job. Asking this question is a common mistake. It is indicative of a product-centric mindset" (Chapter 4).
Key Quotes
"Innovation is transformed from a game of chance to a science when the customer's desired outcomes (customer metrics) are known in advance of ideation." — Ulwick, Chapter 2
"Making the core functional job the unit of analysis is the cornerstone of successful innovation." — Ulwick, Chapter 4
"It is incorrect to ask a customer, 'What job did you hire that product to do?' as this may not reveal the entire job. Asking this question is a common mistake. It is indicative of a product-centric mindset." — Ulwick, Chapter 4
"A 28-year-old man from Montana with a college degree can have the same unmet needs as a 55-year-old woman from Florida who dropped out of high school." — Ulwick, Chapter 4
Rules of Thumb
- State the core functional job as verb + object + contextual clarifier before building the job map. If it references a solution or technology, rewrite it.
- Every desired outcome statement must have four components: direction (minimize/increase), metric (time, likelihood, number), object (what is being measured), context (qualifying circumstance). If any component is missing, the statement is incomplete.
- A complete job typically yields 50-150 desired outcomes. If you have fewer than 50, you likely scoped too narrowly or missed job steps. If over 200, check whether you conflated multiple jobs.
- Use the eight universal steps (define, locate, prepare, confirm, execute, monitor, modify, conclude) as a checklist — not every job uses all eight, but skipping the checklist risks missing entire clusters of outcomes.
- Never average satisfaction scores across the whole market — segment first, then score. Averaging masks segment-level extremes that contain the real opportunities.
- Products that get the job done 20%+ better are "very likely to win in the marketplace" (Chapter 2) — use this as a threshold when evaluating whether aggregated outcome improvements are sufficient.
- Capture outcomes from all three customer types: end user (job executor), product lifecycle support team, and purchase decision maker. Missing any one corrupts the analysis.