Key Principle
The JTBD Needs Framework organizes all customer needs into six distinct types, each anchored to a core functional job and each serving a different strategic function. The six types are:
- Core functional job desired outcomes (50-150 per job): Metrics customers use to measure success at each step of the core functional job. These are the primary input for ODI opportunity identification.
- Related jobs (5-20): Other functional jobs the user wants done alongside the core job. These inform platform-level solution design.
- Emotional jobs (subset of 5-25 emotional/social): How customers want to feel while executing the job. These inform positioning and value proposition.
- Social jobs (subset of 5-25 emotional/social): How customers want to be perceived by others. These inform messaging and brand strategy.
- Consumption chain jobs: Jobs across the full product lifecycle — from purchasing through disposal — each with its own desired outcomes. These inform customer experience innovation.
- Financial desired outcomes (40-80): The buyer's financial metrics for purchase decisions, distinct from the user's functional outcomes.
The taxonomy matters because "without it, teams conflate different need types — mixing emotional desires with functional metrics, or user needs with buyer criteria — producing muddled prioritization and solutions that optimize for the wrong dimension." (Chapter 2)
Why This Matters
The framework answers not just "what are the needs?" but "what kinds of needs exist, how do they differ, and what strategic decisions does each type inform?" Without a complete taxonomy, teams collapse qualitatively different inputs into a single undifferentiated list. A user's desire to "feel confident" (emotional job) demands a different design response than "minimize the time it takes to get songs in the desired order" (functional outcome). Treating both as generic "needs" guarantees that one or both are addressed poorly.
The core functional job acts as a stable anchor for the entire framework. Jobs do not change — only solutions change. "Listen to music" persisted from record players through streaming. This stability means needs research remains valid across technology transitions, has no geographical boundaries, and is solution-agnostic. Companies that anchor to product categories instead ("how do we improve our CD player?") get blindsided when the job migrates to a different platform.
Good Examples
Related jobs expanding a product's scope: The telescopic pointer evolved into the wireless presenter by addressing related jobs like advancing slides and timing presentations. Recognizing these as related jobs — not feature requests — enabled a platform-level redesign rather than incremental improvement. (Chapter 2)
Consumption chain jobs driving differentiation: Dyson's bagless vacuum simplified the disposal step of the consumption chain; non-iron shirts simplified the maintenance step. Both innovations targeted consumption chain jobs rather than the core functional job itself. (Chapter 2)
Financial outcomes requiring a distinct lens: A hospital administrator wanting to "reduce the patient's length of stay" is expressing a financial desired outcome — a buyer-side metric. When buyer and user are the same person, the buyer must adopt a distinct "buyer's hat" to avoid conflating financial outcomes with functional outcomes. (Chapter 2)
Counterpoints
Conflating need types into a single list: Teams that mix "I want to feel safe" (emotional) with "minimize the time to complete the task" (functional outcome) with "reduce total cost of ownership" (financial) produce prioritization rankings that compare incommensurable dimensions. Each type requires its own analysis and feeds different strategic decisions. (Chapter 2)
Anchoring to product categories instead of jobs: Companies that define needs relative to a product ("how do we make a better CD player?") rather than the core functional job ("listen to music") cannot see cross-platform opportunities and are blindsided by disruption from different solution categories. (Chapter 2)
Assuming needs are unknowable: The "latent needs" myth — that customers have needs they cannot articulate — causes companies to conclude a complete needs inventory is impossible. This is a self-fulfilling prophecy: "the assumption that needs are unknowable justifies not investing in the methodology to know them." The real failure is not providing structure, not the customer's cognitive limitation. (Chapter 1)
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
"The mathematical probability of someone coming up with an idea that satisfactorily addresses all the customer's unmet needs without knowing what they are or whether or not they are satisfied is close to zero." — Ulwick, Chapter 1
"Despite all the talk about satisfying customer needs, there is very little understanding of what characteristics a customer need statement should possess and what the structure, content, and syntax of a need statement should be." — Ulwick, Chapter 1
"Coming up with the winning solution is not the customer's responsibility. It is the responsibility of the company." — Ulwick, Chapter 1
Rules of Thumb
- Always classify a need by type before prioritizing it. Functional outcomes, emotional jobs, and financial outcomes each feed different decisions.
- Define the core functional job first. Every other need type is defined relative to it.
- Expect 50-150 desired outcomes per core functional job; 200+ in complex markets like healthcare.
- When buyer and user are the same person, explicitly separate the "buyer's hat" analysis from the user analysis to avoid conflating financial and functional outcomes.
- A new product that gets the job done 20%+ better than alternatives is "very likely to win in the marketplace." Use this as a predictive threshold, not a vague aspiration.
- If your needs list mixes verbs like "feel," "minimize," and "reduce cost" without categorization, you are conflating need types. Stop and sort.
- The job is stable over time and across geographies. If your needs research expires when technology changes, you anchored to the wrong unit of analysis.
Related References
- Jobs-to-be-Done Theory & Outcome-Driven Innovation - the overarching JTBD thesis
- Job Mapping & Desired Outcome Statements - how to decompose jobs and construct outcome statements