Key Principle
A desired outcome statement is a precisely structured metric customers use to measure success while executing a job. The formula is: direction of improvement + performance metric + object of control + contextual clarifier (p. 94). This four-part syntax converts qualitative wishes into quantitative instruments that can be surveyed, scored, and ranked.
The Job Map (Define, Locate, Prepare, Confirm, Execute, Monitor, Modify, Conclude) is the generation scaffold for these statements. Each of the eight steps produces its own set of outcomes, which is how teams reach the required 50-150 outcomes per core job (pp. 50, 93). Without the map, coverage skews heavily toward Execute while non-obvious phases like Confirm, Monitor, and Conclude are systematically overlooked (p. 92-93).
Why This Matters
Outcome statements are the foundational input to the entire ODI quantitative pipeline. If they are malformed, every downstream artifact -- importance ratings, satisfaction ratings, opportunity scores, segments -- inherits the error. As Ulwick states: "Differences in structure, terminology, and syntax from statement to statement can introduce unwanted sources of variability that alter the importance and satisfaction ratings" (p. 94). The rigid syntax is not a style preference; it is a calibration protocol for a measurement instrument.
The payoff of getting them right is durable strategic insight. Because outcomes describe success metrics for the job rather than solution features, a complete set remains valid across technology generations: "Desired outcomes don't change over time -- only the solutions that address them do" (p. 95). This makes a validated outcome set a long-lived asset, unlike technology-specific research that obsoletes each product cycle.
Good Examples
Correct -- music listening job: "Minimize the likelihood that the music sounds distorted when played at high volume" (p. 94).
- Direction: Minimize
- Metric: the likelihood
- Object of control: that the music sounds distorted
- Clarifier: when played at high volume
Correct -- needs-view job map step: "Monitor vital signs" maps the customer goal, not the product action "look at the display." The goal framing opens the design space to any solution; the action framing anchors innovation to an existing device (p. 91).
Scale calibration: The Bosch circular saw case identified 14 specific unmet outcomes in a 25% segment; the product team conceptualized a winning solution in 3 hours because the needs were known in advance (pp. 51-52).
Counterpoints
Antipattern 1 -- Solution-contaminated job maps. Mapping what customers do with a product rather than what they are trying to get done contaminates every outcome derived from the map. "A job map does not show what the customer is doing (a solution view); rather, it describes what the customer is trying to get done (a needs view)" (p. 91).
Antipattern 2 -- Confusing job maps with journey maps. "If you are focusing on the customer journey, you are not focused on the core functional job" (p. 91). Journey maps track consumption chain jobs (buy, set up, use, maintain a product); job maps track the underlying goal. These produce separate outcome sets and must not be conflated.
Antipattern 3 -- Inconsistent statement syntax. Varying phrasing across statements introduces survey noise that distorts importance/satisfaction ratings and produces incorrect opportunity scores, leading to wrong innovation bets (p. 94). Every statement must follow the same four-part structure without exception.
Key Quotes
"Jobs-to-be-Done Theory provides a framework for (i) categorizing, defining, capturing, and organizing all your customer's needs, and (ii) tying customer-defined performance metrics (in the form of desired outcome statements) to the job-to-be-done." -- Tony Ulwick, p. 48
"While a job describes the overall task the customer is trying to execute, an outcome is a metric the customer uses to measure success and value while executing a job." -- Tony Ulwick, p. 49
"For any given job-to-be-done, we often uncover between 50 and 150 desired outcome statements." -- Tony Ulwick, p. 93
"Desired outcomes don't change over time -- only the solutions that address them do." -- Tony Ulwick, p. 95
"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." -- Tony Ulwick, p. 52
Rules of Thumb
- Every outcome statement must have all four parts: direction + metric + object of control + clarifier. No exceptions.
- Use the 8-step Job Map as a completeness checklist, not a forced template -- not every job uses all 8 steps (p. 92-93).
- Expect 50-150 outcomes per core functional job; if you have fewer than 50, you likely have coverage gaps in non-Execute steps.
- Map the job from the needs view (goals), never the solution view (actions). Test each step: could this describe what the customer does with a specific product? If yes, rewrite.
- Never mix job map outcomes with consumption chain (journey) outcomes; they are separate analytical objects (p. 91).
- Treat the outcome set as a durable asset -- it outlasts any single product generation.
- A product must get the job done ~20% better across outcomes to reliably trigger switching (pp. 48-49).
Related References
- Jobs-to-be-Done Theory & the Needs Framework - The JTBD Needs Framework and six need types these statements serve
- The Opportunity Algorithm & Opportunity Landscape - How outcomes get scored quantitatively via importance and satisfaction ratings