--- # === IDENTITY === id: business/frameworks/jobs-to-be-done/2026 canonical_question: "How do I use the Jobs-to-Be-Done framework for product strategy?" aliases: - "Jobs to Be Done" - "JTBD framework" - "Jobs Theory" - "Outcome-Driven Innovation" entity_type: concept domain: business > frameworks > Jobs-to-Be-Done region: global jurisdiction: global temporal_scope: 1990-2026 # === VERIFICATION === last_verified: 2026-02-28 confidence: 0.93 version: 1.0 first_published: 2026-02-28 # === TEMPORAL VALIDITY === temporal_validity: status: stable last_breaking_change: null next_review: 2026-08-27 change_sensitivity: low # === CONSTRAINTS === constraints: - "Identifies customer jobs but does not prescribe how to build solutions — must be paired with product development or strategy execution frameworks" - "Qualitative JTBD research (Christensen/Moesta school) is difficult to scale — requires skilled interviewers and resists standardization" - "The two schools (Christensen vs. Ulwick) have incompatible methodologies — mixing them creates conceptual confusion" - "Job identification requires direct access to customers in context — secondary research and surveys are poor substitutes for Switch interviews or outcome-driven analysis" - "Prerequisite: must understand the difference between a job (stable need) and a solution (temporary product) before applying" skip_this_unit_if: - condition: "User needs to analyze industry-level competitive structure rather than customer needs" use_instead: "business/frameworks/porter-five-forces/2026" - condition: "User needs to allocate resources across a product portfolio" use_instead: "business/frameworks/bcg-growth-share-matrix/2026" - condition: "User needs to create new market space by redefining value factors" use_instead: "business/frameworks/blue-ocean-strategy/2026" inputs_needed: - key: "strategic_situation" question: "What is the user's strategic situation?" type: choice options: - "Understanding why customers choose or switch between products" - "Identifying unmet customer needs for innovation" - "Reframing product strategy around customer progress" - "Comparing frameworks for strategic analysis" # === DISTRIBUTION === canonical_source: "https://knowledgelib.io/business/frameworks/jobs-to-be-done/2026" suggested_citation: "Source: knowledgelib.io — AI Knowledge Library (verified 2026-02-28)" # === RELATED UNITS === related_kos: related_to: - id: "business/frameworks/blue-ocean-strategy/2026" label: "Blue Ocean Strategy" - id: "business/frameworks/okr-framework/2026" label: "OKR Framework" often_confused_with: [] depends_on: [] solves: [] alternative_to: [] # === SOURCES === sources: - id: src1 title: "Jobs to Be Done Theory" author: Christensen Institute url: https://www.christenseninstitute.org/theory/jobs-to-be-done/ type: official_docs published: 2024-01-01 reliability: authoritative - id: src2 title: "Jobs-to-be-Done: A Framework for Customer Needs" author: Tony Ulwick url: https://jobs-to-be-done.com/jobs-to-be-done-a-framework-for-customer-needs-c883cbf61c90 type: primary_research published: 2019-09-01 reliability: authoritative - id: src3 title: "The History of Jobs-to-be-Done and Outcome-Driven Innovation" author: Tony Ulwick url: https://jobs-to-be-done.com/the-history-of-jobs-to-be-done-and-outcome-driven-innovation-a2fdfd0c7a9a type: primary_research published: 2017-04-01 reliability: authoritative - id: src4 title: "Jobs to Be Done Theory and Frameworks Explained" author: GoPractice url: https://gopractice.io/product/jobs-to-be-done-the-theory-and-the-frameworks/ type: technical_blog published: 2024-01-01 reliability: moderate_high --- # 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, service, or business model to serve that job. It must be paired with design thinking, product development frameworks, or strategy execution tools. [src1] - **Qualitative research is hard to scale**: The Christensen/Moesta "Switch" interview method requires skilled interviewers who can uncover the emotional and social dimensions of a job. Untrained interviewers default to feature-request conversations that miss the point entirely. [src4] - **Two incompatible schools**: Mixing Christensen's qualitative, narrative approach with Ulwick's quantitative ODI method creates conceptual confusion. Teams must choose one methodology and apply it consistently. [src4] - **Requires direct customer access**: JTBD cannot be done from a conference room. Secondary research, surveys, and focus groups are poor substitutes for observing and interviewing customers in the context where the job arises. [src2] - **Job vs. solution confusion prerequisite**: Teams must understand that a job is stable over decades (e.g., "keep food fresh") while solutions change constantly (ice blocks, refrigerators, smart fridges). 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 competitive analysis (Five Forces) first └── Which school of JTBD is appropriate? ├── Need qualitative depth (why customers switch) → Christensen/Moesta Switch interviews ├── Need quantitative rigor (measurable unmet needs) → Ulwick's Outcome-Driven Innovation └── Not sure → Start with 5-10 Switch interviews to identify jobs, then consider ODI for validation ``` ## Application Checklist 1. **Identify the job context** - **Inputs needed**: Customer interviews, observation data, support tickets, switching behavior data - **Output**: A set of 3-8 candidate job statements in the format "When I [situation], I want to [motivation], so I can [expected outcome]" - **Constraint**: Job statements must describe the customer's progress, not your product's features — "When I commute to work, I want to stay entertained and not hungry" not "When I drive, I want a milkshake" [src1] 2. **Map the job dimensions** - **Inputs needed**: The candidate job statements from step 1 - **Output**: For each job, identification of functional (what), emotional (how they want to feel), and social (how they want to be perceived) dimensions - **Constraint**: Do not skip emotional and social dimensions — they often drive switching behavior more than functional performance [src1] 3. **Identify competing solutions** - **Inputs needed**: The mapped job dimensions, customer interview data on what they currently "hire" and "fire" - **Output**: A competitive landscape map organized by job (not by product category), showing all solutions customers currently use for this job - **Constraint**: Competing solutions cross product categories — do not limit the competitive set to your own industry [src1] 4. **Prioritize underserved jobs** - **Inputs needed**: The job map, satisfaction data on current solutions, frequency of the job arising - **Output**: A ranked list of the most underserved, high-frequency jobs where current solutions leave significant gaps - **Constraint**: High-frequency, poorly-served jobs represent the best innovation opportunities — avoid low-frequency jobs regardless of how poorly they are served [src2] ## Anti-Patterns ### Wrong: Defining jobs by product category Teams write job statements like "hire a better project management tool" or "find a faster CRM." These are solution-centric statements disguised as jobs. They lock thinking into existing product categories and miss cross-category competition. [src1] ### Correct: Defining jobs by customer progress Write jobs as circumstance-driven progress statements: "When I join a new project with unfamiliar teammates, I want to quickly understand who is responsible for what, so I can contribute without stepping on toes." This opens the competitive landscape to all solutions serving that need. [src2] ### Wrong: Conducting JTBD research via surveys Teams send out surveys asking customers "What features do you want?" or "Rate the importance of these capabilities." This captures stated preferences (what customers say they want) rather than revealed preferences (what actually drives behavior). [src4] ### Correct: Using Switch-style interviews Interview customers who recently switched to or from your product. Ask about the timeline of events, the specific moments of struggle, the emotional triggers, and what they were "hiring" the new solution to do that the old one could not. [src1] ### Wrong: Treating Christensen and Ulwick methods as interchangeable Teams start with Christensen-style qualitative interviews and then try to plug results into Ulwick's quantitative desired-outcome framework. 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 depth, switch interviews) or Ulwick/ODI (quantitative breadth, outcome statements) based on research goals and resources. If starting from scratch, begin with 5-10 qualitative Switch interviews to identify jobs before considering quantitative validation. [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 | Concept | Key Difference | When to Use | |---|---|---| | Jobs-to-Be-Done | Focuses on the progress customers seek, independent of solutions | When defining what problem to solve, identifying unmet needs, or deciding where to innovate | | Personas | Demographic/psychographic user profiles | When designing UX for known user types (but does not reveal what drives their choices) | | Value Proposition Canvas | Maps product features to customer pains/gains | When 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 - [Blue Ocean Strategy](/business/frameworks/blue-ocean-strategy/2026) - [OKR Framework](/business/frameworks/okr-framework/2026) - [Porter's Five Forces](/business/frameworks/porter-five-forces/2026)