Jobs-to-Be-Done

Definition

Jobs-to-Be-Done (JTBD) is a theory of innovation holding that customers do not buy products — they "hire" them to accomplish a specific "job" that arises in their lives. Developed by Tony Ulwick (who conceptualized it in 1990) and popularized by Clayton Christensen (in "The Innovator's Solution," 2003), the framework shifts product strategy from demographic segmentation and feature competition to understanding the functional, emotional, and social progress a customer seeks to make. [src1] The job, not the customer or the product, is the fundamental unit of analysis. [src2]

Key Properties

• Key figures: Tony Ulwick (Outcome-Driven Innovation, 1990), Clayton Christensen (Jobs Theory, 2003), Bob Moesta (Switch interviews)
• Job statement format: "When I [situation], I want to [motivation], so I can [expected outcome]" [src2]
• Three job dimensions: Functional (practical task to complete), Emotional (how the customer wants to feel), Social (how the customer wants to be perceived) [src1]
• Core insight: Customers are not loyal to products — they are loyal to getting a job done. Products are temporary solutions that can be displaced by better ones [src1]
• Two main schools: Christensen/Moesta (qualitative, interview-driven, "Switch" method) and Ulwick (quantitative, outcome-driven, ODI method with desired-outcome statements) [src4]

Constraints

• Identifies jobs, not solutions: JTBD reveals what progress customers seek but does not prescribe how to build a product or service. Must be paired with product development frameworks. [src1]
• Qualitative research is hard to scale: The Christensen/Moesta Switch interview method requires skilled interviewers. Untrained interviewers default to feature-request conversations. [src4]
• Two incompatible schools: Mixing Christensen's qualitative approach with Ulwick's ODI method creates conceptual confusion. Choose one and apply consistently. [src4]
• Requires direct customer access: Secondary research and surveys are poor substitutes for observing customers in the context where the job arises. [src2]
• Job vs. solution confusion: Teams must understand that a job is stable over decades while solutions change constantly. Without this distinction, JTBD collapses into conventional product analysis. [src1]

Framework Selection Decision Tree

START — User needs a strategic analysis framework
├── What is the primary goal?
│   ├── Understand what progress customers are trying to make
│   │   └── Jobs-to-Be-Done (this unit)
│   ├── Understand competitive forces in an existing industry
│   │   └── → Porter's Five Forces
│   ├── Assess internal + external factors and generate strategy options
│   │   └── → SWOT/TOWS Analysis
│   ├── Scan macro-environment (political, economic, social, tech, legal, environmental)
│   │   └── → PESTLE Analysis
│   ├── Decompose a complex strategic problem into non-overlapping parts
│   │   └── → MECE / Issue Trees
│   ├── Allocate resources across a portfolio of business units
│   │   └── → BCG Growth-Share Matrix
│   ├── Create uncontested market space / escape red ocean competition
│   │   └── → Blue Ocean Strategy
│   └── Set and align measurable organizational goals
│       └── → OKR Framework
├── Does the user have access to customers for research?
│   ├── YES → JTBD research is feasible
│   └── NO → Start with secondary research and Five Forces first
└── Which school of JTBD is appropriate?
    ├── Need qualitative depth → Christensen/Moesta Switch interviews
    ├── Need quantitative rigor → Ulwick's Outcome-Driven Innovation
    └── Not sure → Start with 5-10 Switch interviews
  

Application Checklist

1. Identify the job context
   • Inputs needed: Customer interviews, observation data, support tickets, switching behavior
   • Output: 3-8 candidate job statements: "When I [situation], I want to [motivation], so I can [outcome]"
   • Constraint: Job statements must describe customer progress, not product features [src1]
2. Map the job dimensions
   • Inputs needed: Candidate job statements from step 1
   • Output: Functional, emotional, and social dimensions for each job
   • Constraint: Do not skip emotional and social dimensions — they often drive switching more than functional performance [src1]
3. Identify competing solutions
   • Inputs needed: Mapped job dimensions, customer "hire/fire" data
   • Output: Competitive landscape organized by job, showing all current solutions
   • Constraint: Competing solutions cross product categories — do not limit to your industry [src1]
4. Prioritize underserved jobs
   • Inputs needed: Job map, satisfaction data, job frequency
   • Output: Ranked list of underserved, high-frequency jobs
   • Constraint: High-frequency, poorly-served jobs are best opportunities — avoid low-frequency jobs regardless of satisfaction gap [src2]

Anti-Patterns

Wrong: Defining jobs by product category

Teams write "hire a better project management tool" — a solution-centric statement disguised as a job. This locks thinking into existing categories and misses cross-category competition. [src1]

Correct: Defining jobs by customer progress

Write jobs as circumstance-driven progress: "When I join a new project, I want to quickly understand responsibilities, so I can contribute without stepping on toes." [src2]

Wrong: Conducting JTBD research via surveys

Surveys capture stated preferences rather than revealed preferences — what customers say they want vs. what actually drives behavior. [src4]

Correct: Using Switch-style interviews

Interview customers who recently switched. Ask about the timeline, moments of struggle, emotional triggers, and what they hired the new solution to do. [src1]

Wrong: Treating Christensen and Ulwick methods as interchangeable

The two methodologies define "jobs" at different levels of abstraction and use incompatible analytical structures. [src4]

Correct: Choosing one school and applying it consistently

Select either Christensen/Moesta (qualitative) or Ulwick/ODI (quantitative) based on goals. Start with 5-10 Switch interviews if unsure. [src3]

Common Misconceptions

Misconception: JTBD is just another way to describe user needs or use cases.
Reality: JTBD is specifically about the progress a customer is trying to make in a particular circumstance — it includes the full context, constraints, and tradeoffs. Unlike traditional needs analysis, JTBD recognizes that a "job" is stable over time even as the solutions change. People have been "hiring" solutions to "get from A to B quickly" for centuries — horses, trains, cars, ride-sharing. [src1]

Misconception: The job is defined by the product category.
Reality: Jobs cut across product categories. The classic "milkshake" example from Christensen shows that a morning milkshake competes not with other milkshakes but with bagels, bananas, and boredom — all of which are "hired" for the job of making a morning commute less tedious and keeping hunger at bay until lunch. [src1]

Misconception: Christensen and Ulwick created the same framework.
Reality: They developed related but distinct approaches. Ulwick's ODI framework is process-driven and quantitative, using structured "desired outcome statements" to measure unmet needs. Christensen's approach is more narrative and qualitative, emphasizing circumstance and "hiring/firing" language. Both are valid but differ significantly in methodology. [src4]

Comparison with Similar Concepts

When This Matters

Fetch this when a user asks about product strategy, customer-centric innovation, understanding why customers switch products, or needs to reframe a product decision around customer progress rather than features or demographics.