Skip to content
All tools
InnovationIntermediate

Jobs to Be Done

Explain why people change behaviour by studying the progress they seek in specific circumstances.

Study the circumstances and desired progress behind a real choice, then design the experience that helps people make that progress.

In one minute

Jobs to Be Done asks why a person “hires” a product, service or workaround in a particular situation. The unit of analysis is not a demographic profile or feature request. It is the progress a person seeks under specific circumstances.

A useful job has functional, emotional and social dimensions:

  • Functional: what the person needs to accomplish.
  • Emotional: how the person wants to feel or avoid feeling.
  • Social: how the person wants to be seen by others.

A practical job statement is:

When [circumstance], I want to [make progress], so I can [achieve a meaningful outcome].

Best for: discovering demand, understanding switching behaviour, positioning an offer and designing a complete adoption experience.
Avoid when: the team needs a satisfaction score, market-size estimate or usability diagnosis of a known interface.

The problem it addresses

Conventional segments describe who customers are but often fail to explain why they change. Feature surveys also encourage people to speculate about solutions.

JTBD reconstructs actual decisions. It identifies the forces that made change necessary, attractive, risky or avoidable. The output is a demand hypothesis that can guide product, service, sales and onboarding choices.

When to use it

Use JTBD when:

  • customers with similar profiles behave differently;
  • growth depends on switching from an established alternative;
  • a product has strong usage in one context and weak usage in another;
  • the team needs to understand non-consumption or delayed adoption;
  • feature requests conflict but underlying outcomes may be shared;
  • marketing describes the product but not the progress customers seek.

Interview people who made a relevant choice recently enough to reconstruct the timeline.

When not to use it

Do not use JTBD:

  • as a slogan-writing exercise;
  • to replace direct usability testing;
  • with only hypothetical “would you buy?” questions;
  • to force every customer into one universal job;
  • when the scope lacks a clear decision or switching event;
  • as a substitute for market sizing, economics or causal experimentation.

Use Customer Journey Mapping when the primary question is how the current experience unfolds across touchpoints.

Inputs required

  • a defined choice event: adoption, switch, renewal, cancellation or non-consumption;
  • participants with recent first-hand experience;
  • interview access to buyers, users and influencers where roles differ;
  • a neutral interview guide;
  • artefacts such as searches, comparison notes, messages or trial records;
  • a synthesis method for timelines and repeated patterns;
  • behavioural or commercial data for later validation.

Step-by-step process

1. Define the choice

Name the change you need to understand. “Use accounting software” is too broad. “Move from spreadsheets to a paid cash-flow tool” is researchable.

2. Recruit from behaviour

Recruit recent switchers, active evaluators, abandoners and people who stayed with the old solution. Avoid recruiting only loyal advocates.

3. Reconstruct the timeline

Start before active shopping:

  1. first thought;
  2. passive looking;
  3. triggering event;
  4. active comparison;
  5. decision;
  6. first use;
  7. confirmation or regret.

Ask for events, people, alternatives and trade-offs.

4. Map the forces of progress

Identify:

  • Push of the current situation
  • Pull of the new solution
  • Anxiety about the new solution
  • Habit of the present

The first two support change; the second two resist it.

5. Identify the desired progress

Separate the functional outcome from emotional and social consequences. Ask what became possible after a successful change.

6. Write a job hypothesis

Use language that remains solution-independent and specific enough to guide design.

Weak: “Manage appointments.”
Better: “When a patient requests an urgent change during a busy clinic session, I want to update every dependent record with confidence so I can end the call without creating a later surprise.”

7. Find repeated job patterns

Compare timelines across interviews. Segment by recurring circumstances and progress, not by memorable quotes.

8. Design the full experience

Address the core outcome and the forces around adoption. Product capability, proof, migration, trial, pricing, onboarding and support may all matter.

9. Validate demand

Test with behaviour: realistic prototypes, switching offers, pilots, deposits, usage and retention. Treat the job statement as a hypothesis.

Visual model

Text alternative: current struggle and the attraction of progress push a person toward change, while anxiety and existing habits resist change. The selected solution is judged by whether it creates the expected progress.

Interactive example

Scenario

Five independent consultants recently moved from email and spreadsheets to a client portal. Three say they wanted “professionalism,” but their decision timelines differ:

  • two switched after sending an outdated file to a client;
  • one switched when an enterprise buyer required a secure portal;
  • two waited until a colleague offered migration help;
  • all worried that clients would resist another login.

Your move

Identify one possible job and two forces the provider should address.

Worked answer

Job hypothesis: When client work involves several versions and decision makers, I want one trusted place for the current material so I can appear in control and avoid damaging mistakes.

Push: embarrassment and rework caused by version confusion.
Anxiety: fear that clients will reject a new login.
Design implication: demonstrate client access in a realistic workflow and provide a low-effort invitation or guest-access path.

The enterprise compliance event may represent a separate job and should not be averaged into the same segment without further evidence.

Facilitation notes

  • Ask for the last real decision, then move backwards and forwards in time.
  • Use silence and concrete follow-ups: “What happened next?” “Who was there?”
  • Do not reveal the preferred product claim during the interview.
  • Capture competing solutions, including manual work, delay and doing nothing.
  • Let several researchers code the same early interviews and compare interpretations.
  • Preserve contradictory cases; they may signal a different job.

Expected output

A sound study produces:

  • decision timelines;
  • switching forces and important trade-offs;
  • functional, emotional and social outcomes;
  • one or more job hypotheses;
  • circumstance-based segments;
  • experience and messaging implications;
  • assumptions requiring behavioural validation.

Common mistakes

  1. Interviewing opinions rather than events. General preferences hide the decision mechanism.
  2. Writing the product into the job. This narrows alternatives too early.
  3. Making the job universal. Different circumstances can create different demand.
  4. Ignoring anxiety and habit. Strong value does not remove switching resistance.
  5. Treating a memorable quote as a segment. Patterns require comparison across cases.
  6. Stopping at insight. A job must change a product, service, adoption or positioning decision.

Quality checklist

  • The research concerns a specific recent choice or non-choice.
  • Participants were recruited by behaviour, not only demographics.
  • Interviews reconstruct a timeline rather than collect feature wishes.
  • The analysis includes push, pull, anxiety and habit.
  • Functional, emotional and social outcomes are considered.
  • Job statements avoid product names and remain circumstance-specific.
  • Competing alternatives include workarounds and non-consumption.
  • The job hypothesis has a behavioural validation plan.

Template

Decision stageEventPerson involvedEvidenceInterpretation
First thought
Passive looking
Trigger
Active comparison
Decision
First use
ForceFindingDesign implication
Push of current situation
Pull of new solution
Anxiety of new solution
Habit of present

Job hypothesis: When ___, I want to ___, so I can ___.

Knowledge check

Which statement is the strongest JTBD hypothesis?

A. Busy managers want an AI dashboard.
B. Customers aged 30–45 prefer mobile tools.
C. When a client challenges a delivery date, I want to see the latest commitments and dependencies so I can respond without making a promise the team cannot keep.
D. Users need better project management.

Answer: C. It describes circumstances, desired progress and a meaningful outcome without prescribing a solution.

Related tools

References

  1. Clayton Christensen Institute. “Jobs to Be Done Theory.” Official theory overview (opens in a new tab).
  2. Christensen, C. M., Hall, T., Dillon, K., & Duncan, D. S. Competing Against Luck. HarperBusiness, 2016.
  3. Christensen, C. M., Hall, T., Dillon, K., & Duncan, D. S. “Know Your Customers’ ‘Jobs to Be Done.’” Harvard Business Review, September 2016. Article record (opens in a new tab).

Sources reviewed 28 July 2026.