> ## Documentation Index
> Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Jobs to Be Done (JTBD)

> Jobs to Be Done is a method for understanding what progress customers are trying to make in specific situations. Learn origin, practical workflow, and common failure modes.

<Info>
  **Category**: Methods<br />
  **Type**: Customer-Centered Innovation and Positioning Method<br />
  **Origin**: Theodore Levitt's demand framing (1960) and Clayton Christensen's JTBD development (2000s-2010s)<br />
  **Also known as**: JTBD, Job-Centered Innovation
</Info>

<Note>
  **Quick Answer** — Jobs to Be Done (JTBD) is a method for identifying the "job" customers are trying to accomplish in a real context, then designing products and messages around that progress goal. It evolved from marketing insights like Levitt's "customers buy outcomes, not products" and was systematized by Christensen and collaborators. Its core insight is that people "hire" solutions to make progress in a situation, not because they belong to a demographic segment.
</Note>

## What is Jobs to Be Done (JTBD)?

Jobs to Be Done is a framework that explains demand by the progress a person wants in a specific context, including functional, emotional, and social dimensions.

> In JTBD, the unit of analysis is not the customer profile but the struggle for progress in a situation.

Instead of asking only "Who is the user?", JTBD asks "What is this person trying to get done right now, and what blocks them?" This lens complements `/methods/hypothesis-driven-thinking`, `/methods/lean-methodology`, and `/methods/decision-journal` when teams need clearer product positioning.

### Jobs to Be Done (JTBD) in 3 Depths

* **Beginner**: Define the job as a progress statement, not a feature request.
* **Practitioner**: Conduct switch interviews to map triggers, desired outcomes, anxieties, and competing alternatives.
* **Advanced**: Use job maps to align product, pricing, onboarding, and messaging around the same progress mechanism.

## Origin

JTBD has intellectual roots in Theodore Levitt's 1960 argument that customers do not simply buy products; they seek outcomes. This framing was later expanded in innovation research by Clayton Christensen and colleagues, especially in *Competing Against Luck* and the HBR article "Know Your Customers' Jobs to Be Done."

The mature JTBD model emphasizes circumstance over demographics. Two people with similar profiles can "hire" different solutions because their context, constraints, and desired progress differ.

## Key Points

JTBD is effective when teams study real switching behavior instead of relying on feature preference surveys alone.

<Steps>
  <Step title="Write a precise job statement">
    Frame the target progress in one sentence, such as "Help busy managers prepare credible weekly updates in under 20 minutes." Good job statements focus on progress under constraints.
  </Step>

  <Step title="Map the push-pull forces around switching">
    Document what pushes users away from current solutions, what pulls them toward a new one, what habits keep them stuck, and what anxieties slow adoption.
  </Step>

  <Step title="Design around moments of struggle">
    Prioritize product and service changes that remove friction in the actual job context rather than adding disconnected features.
  </Step>

  <Step title="Align positioning with the job story">
    Ensure messaging, onboarding, and pricing all reinforce the same job narrative, so users quickly recognize fit.
  </Step>
</Steps>

## Applications

JTBD is especially useful when growth stalls despite continuous feature releases.

<CardGroup cols={2}>
  <Card title="Product Positioning">
    Reframe value propositions around customer progress instead of internal feature taxonomy.
  </Card>

  <Card title="Onboarding Redesign">
    Remove first-use friction by matching setup flow to the user's immediate job.
  </Card>

  <Card title="Segmentation Strategy">
    Segment by job context and constraints, not only by demographic or firmographic attributes.
  </Card>

  <Card title="Roadmap Prioritization">
    Fund improvements that reduce struggle in high-frequency jobs with high switching potential.
  </Card>
</CardGroup>

## Case Study

The McDonald's milkshake study, frequently cited in JTBD literature, is a classic case of job-based reframing. Researchers observed purchase patterns and found that roughly **40% of milkshakes were bought in the morning**, often by commuters.

Instead of treating "milkshake buyer" as one segment, the team identified at least **two distinct jobs**: a morning commute companion and an afternoon treat context. This shifted attention from flavor-centric tweaks toward context-fit design, such as convenience and satiation during travel.

## Boundaries and Failure Modes

JTBD can fail when teams use "job" as a new label for old persona assumptions. If interviews are shallow or context data is weak, the framework becomes storytelling without predictive value.

Two boundaries are critical. First, JTBD explains demand structure but does not replace execution disciplines like pricing tests or operations design. Second, job narratives can overfit if based on too few contexts. A common misuse is claiming one universal job for all customers.

## Common Misconceptions

Many JTBD failures come from confusing the method's depth with slogan-level interpretation.

<AccordionGroup>
  <Accordion title="JTBD means demographics no longer matter">
    Demographics can still matter, but they are secondary descriptors, not the primary causal explanation of demand.
  </Accordion>

  <Accordion title="JTBD is only for B2C products">
    B2B buyers also "hire" tools to reduce risk, save time, or gain credibility in organizational workflows.
  </Accordion>

  <Accordion title="A job statement directly gives the final product">
    JTBD clarifies direction; teams still need experiments to choose specific features, delivery models, and pricing.
  </Accordion>
</AccordionGroup>

## Related Concepts

These methods help operationalize JTBD into repeatable discovery and delivery loops.

<CardGroup cols={3}>
  <Card title="Hypothesis-Driven Thinking" href="/methods/hypothesis-driven-thinking">
    Convert job assumptions into testable statements.
  </Card>

  <Card title="Lean Methodology" href="/methods/lean-methodology">
    Run build-measure-learn cycles around job outcomes.
  </Card>

  <Card title="MVP" href="/methods/mvp">
    Launch the smallest offer that proves job fit.
  </Card>

  <Card title="Five Whys" href="/methods/five-whys">
    Probe root causes of user struggle in job completion.
  </Card>
</CardGroup>

## One-Line Takeaway

<Tip>
  JTBD helps teams stop building for profiles and start building for the real progress users are trying to make.
</Tip>