Jobs to Be Done framework

1. What Is the Jobs to Be Done (JTBD) Framework?

Jobs to Be Done (JTBD) is a demand‑side framework for understanding why customers “hire” a product or service—the progress they are trying to make in a specific situation—so you can design, build, and position solutions that they will reliably choose. In JTBD, the unit of analysis is the job (the desired progress) rather than the customer profile or the product features. People don’t buy drills; they “hire” them to make clean, fast holes under certain constraints. They don’t subscribe to software; they “hire” it to reconcile accounts quickly, coordinate teams with less friction, or get paid on time.

Within Agile, Innovation & Networked‑Organization frameworks, JTBD provides the upstream clarity that makes downstream execution effective. It pairs naturally with Design Thinking, Lean Startup, and Agile delivery by defining the problem and outcomes in customer terms. Teams use JTBD to segment by job (not demographics), prioritize outcomes, generate concepts, and craft messaging that matches the reasons customers switch.

In plain terms: JTBD helps you identify the real reasons customers choose, switch, or stay—so you build the right thing, position it correctly, and stop guessing.

2. Origin and Background

JTBD draws on multiple strands of innovation research and practice. The concept was popularized by Clayton Christensen and colleagues through articles (e.g., 2005 HBR “Marketing Malpractice”) and the book Competing Against Luck (2016). In parallel, Tony Ulwick developed Outcome‑Driven Innovation (ODI) in the mid‑1990s, introducing job maps and quantitative outcome prioritization. Practitioners like Bob Moesta and Chris Spiek advanced “switch interviews” that reveal the forces causing people to adopt or reject a solution.

Why it emerged: traditional segmentation (demographics, firmographics) and feature‑led roadmaps often fail to predict behavior. JTBD reframed markets around the progress people seek in specific circumstances, offering a more predictive basis for product strategy and growth.

3. How JTBD Works

The core logic: customers “hire” solutions to make progress (“jobs”), in a context, with desired outcomes and constraints. JTBD provides shared definitions and tools to capture that logic and turn it into design and go‑to‑market choices.

Key Concepts

• Job: The progress a person is trying to make in a given situation. Jobs can be:
  • Functional: Achieve an objective (e.g., “reconcile the month‑end books accurately in under two hours”).
  • Emotional: Feel a certain way (e.g., confident, in control) while doing it.
  • Social: Appear a certain way to others (e.g., professional to clients, responsible to a boss).
• Context: The circumstances that shape choices—constraints, triggers, timing, environment (e.g., “on a tight deadline with incomplete data”).
• Desired outcomes: Measurable criteria people use to judge success (e.g., minimize rework, reduce time to complete, increase certainty of accuracy). Ulwick’s ODI expresses outcomes as direction + metric + object + context.
• Forces of progress: What pushes a customer to switch and what holds them back:
  • Push of the current situation (pain/friction now).
  • Pull of a new solution (attractive benefits).
  • Anxieties about the new (risks, unknowns).
  • Habit/inertia of the present (status quo, switching costs).
• Job map: A generalized set of steps customers go through to get a job done (e.g., define → locate → prepare → confirm → execute → monitor → modify → conclude). Mapping reveals where unmet outcomes cluster.

Working Artefacts

• Job statement: “[Verb] + [object] + [context]” (e.g., “Create a clear project plan before stakeholder kickoff” or “Get paid on time by new clients without awkward follow‑up”). Avoid embedding solutions in the statement.
• Outcome list: 20–50 desired outcomes tied to the job (e.g., “reduce steps to set up payment,” “increase visibility into invoice status,” “reduce risk of underpricing”).
• Switch timeline: A narrative of a recent switch, capturing triggers, evaluation, anxieties, and first use—great for qualitative insight.

How It Comes Together

You identify and define key jobs, capture desired outcomes and constraints, analyze which outcomes are underserved (important but poorly satisfied), and target those with concepts and positioning. You then test concepts and messaging against the job and outcome criteria, iterating quickly with experiments.

4. When to Use JTBD

Most helpful when:

• Growth has plateaued and existing segmentation doesn’t explain adoption or churn.
• You’re exploring new products, pricing, or positioning and want a more predictive basis than personas or features.
• Teams disagree on “what customers want”; you need a common, non‑solution language to align design, engineering, and marketing.
• You operate in markets where switching is episodic and context matters (B2B workflows, financial services, health, complex consumer journeys).

Especially powerful: Combined with Design Thinking (to generate/iterate concepts), Lean Startup (to test hypotheses), and Agile (to deliver increments linked to outcomes). JTBD sharpens problem framing; the others accelerate learning and delivery.

Less suitable or potentially misleading:

• As a shallow relabeling of features or tasks (“the job is to click less”); that misses the underlying progress and context.
• When used only for messaging without informing product design or prioritization.
• If treated as a one‑time research project rather than a living basis for decisions.

5. How to Apply JTBD: Step‑by‑Step

1. Clarify scope and business outcomes.

   Define the arena (“market” as the job, not the category). Example: Instead of “we compete in accounting software,” frame “we help small businesses get paid on time and close the books confidently.” Set success metrics (e.g., activation, conversion, retention, NPS, ARPU) to judge impact.

2. Recruit the right customers (around “switch” moments).

   Find people who recently switched, nearly switched, or churned. In B2B, include end users, buyers, and influencers. Aim for diversity in context (industry, size, maturity) tied to the job, not demographics.

3. Conduct JTBD interviews (switch timelines).

   Use timeline interviews to reconstruct the last switch: triggers, choices considered, anxieties, decision criteria, first‑use experience. Avoid “would you” questions; focus on what happened. Capture quotes and behaviors tied to the four forces of progress.

4. Extract job statements and outcomes.

   Synthesize across interviews:

   • Draft job statements: functional + emotional + context (keep solutions out).
   • List desired outcomes and constraints (time, accuracy, effort, risk, cost).
   • Map the job steps (job map) and tag outcomes to steps.

   Validate with additional interviews until patterns stabilize (often ~15–25 for a focused product area).

5. Prioritize needs (qual + quant).

   Qualitatively, identify “hot spots” (frequent, painful, underserved). If the stakes warrant, field a survey using ODI‑style importance and satisfaction ratings for each outcome to find “opportunity scores” (important + dissatisfied). Focus on outcomes with the largest gap.

6. Translate into job stories and concepts.

   Write job stories: “When [situation], I want to [motivation/job], so I can [expected outcome].” Use these to ideate features, workflows, and service changes. Explore multiple solution paths; avoid converging too early.

7. Test with Build–Measure–Learn loops.

   Design experiments (prototypes, fake doors, A/B tests, concierge MVPs) to validate that your concepts improve key outcomes (e.g., time‑to‑complete, error rate, willingness to pay). Measure behavior, not opinions; predefine thresholds for pivot/persevere.

8. Infuse JTBD into roadmap and backlogs.

   Organize epics by jobs/outcomes (“Reduce time to issue a compliant invoice by 50%”) and link user stories to job stories. Track outcome metrics per job—e.g., activation for “get started quickly,” on‑time payment rates for “get paid on time,” etc.

9. Align go‑to‑market with jobs.

   Craft messaging around jobs and outcomes (“Get paid on time without awkward follow‑ups”), not feature lists. Segment by job contexts (e.g., freelancers vs. agencies) and tailor onboarding, pricing, and channels accordingly.

10. Maintain the JTBD system.

    Revisit jobs and outcomes quarterly; update as contexts change (regulation, macroeconomy, tech). Keep a shared repository of job statements, outcome data, interviews, and decisions so learning compounds across teams.

6. Example: JTBD in Action

Context: A $250M fintech served SMBs with invoicing and payments. Growth stalled; trial‑to‑paid conversion hovered at 7%, and churn was higher among freelancers. Leadership suspected feature gaps; the team used JTBD to reframe.

Application:

• Scope: Redefine the market as the jobs “get paid on time by new clients without awkward follow‑up” and “close the books with confidence each month.”
• Research: 24 switch interviews (won and lost deals, churn, recent switchers). Patterns:
  • Push: Cash flow anxiety; clients delaying payment; time wasted chasing.
  • Pull: Promise of automated reminders, professional invoices, status visibility.
  • Anxieties: Fear of appearing unprofessional with too many reminders; concerns about fees; setup complexity.
  • Habit/inertia: Manual spreadsheets, email templates, and bank transfers “good enough.”
• Job definition & outcomes:
  • Job statement: “Get paid on time by new clients without harming the relationship.”
  • Top desired outcomes (important, poorly satisfied): reduce time to set up payment links; increase on‑time payment rate for new clients; reduce awkwardness of reminders; increase visibility into invoice status; reduce disputes.
• Concepts: “Smart first‑invoice flow” (guided setup + branded payment link), “polite reminder cadence” (tone + timing templates), and “status transparency” (client‑side status page; sender visibility).
• Experiments: Fake‑door for branded payment link (54% click‑through among target); A/B test for reminder cadence (on‑time payments +12 points; no NPS drop); concierge setup reduced first‑invoice setup time by 60%.
• Roadmap: Prioritized the “smart first‑invoice flow,” shipped behind flags; added “status transparency”; packaged reminder cadences as presets. Messaging shifted from “all‑in‑one invoicing” to “get paid on time without awkward follow‑ups.”

Outcomes (12 weeks): Trial‑to‑paid conversion increased from 7% to 12%; on‑time payment rates for first‑time clients improved from 52% to 67%; setup time for first invoice dropped by 58%; churn among freelancers fell 22%. Revenue lift exceeded the opportunity cost of deprioritized features that did not map to top outcomes.

7. Strengths and Limitations

Strengths

• Predictive segmentation: Segments by jobs and contexts that actually drive choices, not superficial demographics.
• Alignment tool: Gives product, design, engineering, and marketing a shared, non‑solution language.
• Outcome focus: Prioritizes measurable customer outcomes over features, enabling better roadmaps and experiments.
• Versatility: Works for new product creation, feature prioritization, pricing/packaging, and positioning.

Limitations

• Method variance: Different “schools” (Christensen, ODI, switch interviews) can create confusion; teams must pick and standardize.
• Interview skill required: Poorly run interviews yield stories and opinions instead of decision‑grade insights.
• Not a silver bullet: JTBD doesn’t replace strategy or address supply‑side constraints; it informs them.
• Quant not always feasible: ODI‑style surveys can be expensive/time‑consuming; over‑precision can mask obvious qualitative patterns.

8. Common Pitfalls (and How to Avoid Them)

• Confusing tasks with jobs.
  What goes wrong: Teams document steps (“upload receipt”) instead of progress (“reconcile expenses with confidence”).
  Avoid by: Asking “what progress were you trying to make, in what situation, and why did it matter?” Keep solutions out of job statements.
• Persona or feature rebranding.
  What goes wrong: Demographic personas or feature wishlists relabeled as “jobs.”
  Avoid by: Centering interviews on real switch decisions and forces; tie outcomes to measurable progress.
• Solution‑laden job statements.
  What goes wrong: “Use AI to categorize receipts” (technology assumption baked in).
  Avoid by: Writing solution‑agnostic job statements and mapping multiple solution options.
• No quant prioritization when stakes are high.
  What goes wrong: Betting big based on a dozen interviews; misses the real demand curve.
  Avoid by: Running an ODI‑style survey to size unmet outcomes when making material investments.
• Ignoring context/constraints.
  What goes wrong: One job statement used everywhere; solutions flop in real settings.
  Avoid by: Capturing contexts (time pressure, compliance, device) and designing variants or guardrails.
• Poor handoff to delivery and GTM.
  What goes wrong: Insights live in decks; backlogs and messaging don’t change.
  Avoid by: Translating jobs into job stories, epics tied to outcomes, and messaging/testing that mirrors the job.
• Stale JTBD repository.
  What goes wrong: Jobs/outcomes don’t reflect new tech, regulations, or behaviors.
  Avoid by: Quarterly refresh and governance; treat JTBD as a living asset with owners.

9. How JTBD Relates to Other Frameworks

• Design Thinking (Double Diamond): JTBD sharpens Discover/Define (problem framing and outcomes). Double Diamond provides process structure; JTBD provides the “why.”
• Lean Startup Build–Measure–Learn: JTBD generates hypotheses (jobs/outcomes); B–M–L runs the experiments to validate them and guide pivots/perseverance.
• Agile (Scrum/Kanban): JTBD informs epics and user stories (via job stories). Agile manages delivery cadence and flow.
• Outcome‑Driven Innovation (ODI): A quantitative JTBD approach (Ulwick) to prioritize outcomes using importance/satisfaction data and job maps.
• Value Proposition Canvas: A complementary tool to express pains/gains aligned to jobs; JTBD helps avoid solution bias.
• Kano and RICE: Use Kano to classify features (basic, performance, exciting) once jobs/outcomes are known; use RICE/ICE to prioritize validated opportunities.
• OKRs: Set OKRs around jobs/outcomes (“increase on‑time payments”) and track them through delivery and growth.

10. Key Takeaways

• JTBD reframes markets around the progress customers seek in specific contexts; segment and prioritize based on jobs and outcomes, not features or demographics.
• Use switch interviews to uncover forces of progress, job statements, and desired outcomes; map jobs to identify where unmet needs cluster.
• Prioritize outcomes qualitatively and, when stakes are high, quantitatively (ODI); generate multiple concepts and test them with Build–Measure–Learn.
• Translate jobs into job stories, outcome‑tied epics, and messaging; measure success with customer‑observable outcomes (activation, time‑to‑value, conversion, retention).
• Treat JTBD as a living asset—refresh with new evidence and integrate into product, design, and go‑to‑market rhythms.

11. FAQs About Jobs to Be Done

How is JTBD different from user stories or personas?
Personas describe who; user stories describe what a user does in a system. JTBD describes why a customer hires a solution (the progress they seek) in a specific context. Use JTBD to frame outcomes; express delivery work as user/job stories; keep personas only if they add context that affects choices.

What does a good job statement look like?
Keep it solution‑agnostic and contextual: “When [situation], I want to [make progress], so I can [desired outcome].” Example: “When starting with a new client, I want to get paid on time without awkward follow‑ups, so I can focus on work instead of chasing.” Avoid embedding features or technologies.

How many interviews do we need?
For a focused area, 12–20 well‑run switch interviews usually surface stable patterns; complex B2B contexts may require more roles (user/buyer/influencer). Use quant (ODI‑style) when investment is high or disagreement persists.

Can JTBD work in B2B?
Absolutely. JTBD shines in B2B because context, switching risks, and multi‑role decisions matter. Capture jobs for users and buyers; include compliance, integration, and risk constraints in the job map and outcomes.

Do we always need quantitative ODI surveys?
No. Many decisions can be made with strong qualitative evidence and behavioral tests. Use quant when the stakes are high, markets are heterogeneous, or you need to align many stakeholders on which outcomes are truly underserved.

How do we connect JTBD to the backlog?
Translate jobs into job stories and epics with outcome metrics. Example: Epic “Increase on‑time payment rate for first‑time clients” with KPIs; user stories implement features (e.g., branded payment link, reminder templates) that move the epic outcome.

What’s the first practical step?
Recruit 8–10 recent switchers; run timeline interviews to extract jobs/outcomes and forces of progress. Write 3–5 job statements and top outcomes; test one concept with a small experiment (fake door, prototype) within two weeks. Build a visible JTBD repository and expand from there.