Jobs To Be Done

Jobs to Be Done reframes customer research around the progress people are trying to make in their lives — the "job" they hire products to perform. Demographics tell you who buys; JTBD tells you why they buy now.

Origin

JTBD developed across several authors. Anthony Ulwick formalized "Outcome-Driven Innovation" in the early 1990s, codified in his 2005 book What Customers Want. Clayton Christensen popularized the JTBD framing through his 2003 book The Innovator's Solution and the famous "milkshake" study, where the actual job customers hired McDonald's morning milkshakes for turned out to be "keep my hand busy and stomach full during a long boring commute," not "have a sweet treat for breakfast." Bob Moesta and Chris Spiek developed the interview methodology. The schools differ on emphasis but agree on the core insight: customers don't buy products, they hire them for jobs.

The job statement

A well-formed job statement has three parts: situation (when this happens), motivation (I want to do X), expected outcome (so I can achieve Y). Example: "When I'm onboarding a new engineer, I want to grant the right access permissions in one place, so I don't spend a week chasing down access tickets."

Jobs come in three flavors: functional (the literal task — "clean my floor"), emotional (the feeling — "feel competent at my job"), and social (how others perceive me — "look like a good host"). Most purchases serve all three; misunderstanding the dominant one is a common product-marketing error.

When JTBD is the right tool

JTBD is most useful for: identifying unmet needs (where customers are hiring inadequate solutions), understanding why customers churn (they fired your product because it stopped doing the job), positioning new products against unexpected competitors (your real competitor for a productivity app might be a paper notebook, not another app), and segmenting markets by behavior rather than demographics.

It's a poor fit for: incremental feature prioritization within an existing product (use Kano); pricing decisions; or commodity markets where the job is well understood and competition is on price/distribution.

How to apply it

1. Find recent switchers. Interview people who recently switched into or out of your product. The switching moment surfaces the job, because that's when the customer made a deliberate choice. People who have used a product for years can't easily articulate why.
2. Reconstruct the timeline. Walk back from the purchase decision: what triggered them to start looking? What were they using before, and what made it inadequate? What did they consider? What pushed them over the edge?
3. Identify forces. The Moesta school maps four forces: pull of the new (attractive features), push of the situation (problems with the current state), anxiety of the new (concerns about switching), habit of the present (inertia). Switching happens when push + pull exceeds anxiety + habit.
4. Write the job statement. Specific situation, specific motivation, specific outcome. "When my team is reviewing a PR, I want to leave inline comments tied to specific lines, so reviewers don't have to interpret my feedback ambiguously."
5. Map competitors by job, not category. What else gets hired to do this job? Often the real competitors are non-obvious — a paper notepad, a Slack thread, a face-to-face meeting.
6. Identify under-served outcomes. For each job, customers want certain outcomes (e.g., faster, lower error rate, less anxiety). Survey importance vs. satisfaction; the gaps are the opportunities.

Worked example: a project management tool

A project management tool researching why customers churn discovers two distinct jobs being done poorly:

• Job A: "When I'm running a small client engagement, I want to share status with the client without exposing internal mess." Customers hire the tool initially for this. They fire it when client-facing views require too much configuration. Real competitor: shared Google Docs.
• Job B: "When my engineering team is planning a sprint, I want everyone to see priorities and dependencies in one place." Different customers hire the tool for this. They fire it when it's slow and the engineering team migrates to Linear or Jira.

The two jobs require different products. Trying to serve both produces a tool that's mediocre at each. Strategic implication: pick a job, win it, then expand. The framework reveals what no demographic or persona analysis would: the same buyer profile (a 30-person services agency) uses the product for different jobs, and serving both is the cause of the churn.

How JTBD goes wrong

• Confused with personas. JTBD is about jobs, not people. Two very different people may share a job; one person has different jobs in different contexts. Mixing the two collapses the framework.
• Job statements are too abstract. "Communicate effectively" is not a job; "share status with a client without exposing the internal Trello mess" is. Specificity is everything.
• Skipping the switching interview. Generic customer research about preferences produces persona-flavored output, not job statements. The switching moment is the methodology.
• Ignoring forces. Understanding the job without understanding the forces (push, pull, anxiety, habit) produces feature lists, not adoption strategies.
• Single-job tunnel vision. Real customers do many jobs. Picking one and building around it is right; pretending the others don't exist isn't.

Critique

The JTBD methodology can feel circular: you find what people "really" want by interviewing them, then design for it; the rigor of the interviews determines the quality of the output, and there's no objective ground truth to check against. Practitioners disagree on key methodological points (is functional or emotional job dominant? how granular should jobs be?). Despite these critiques, the central insight — that customers buy outcomes, not products — has proven durable and is now embedded in most modern product methodologies.