Jobs-to-Be-Done

Type: Concept Confidence: 0.93 Sources: 4 Verified: 2026-02-28

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

Constraints

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

ConceptKey DifferenceWhen to Use
Jobs-to-Be-DoneFocuses on the progress customers seek, independent of solutionsWhen defining what problem to solve, identifying unmet needs, or deciding where to innovate
PersonasDemographic/psychographic user profilesWhen designing UX for known user types (but does not reveal what drives their choices)
Value Proposition CanvasMaps product features to customer pains/gainsWhen aligning a specific product's features to customer needs (works well paired with JTBD)

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.

Related Units