Jobs-To-Be-Done (JTBD)

01 — TL;DR

Two sentences.

Jobs-To-Be-Done is a framework for understanding why people buy and use products — asserting that users do not acquire products for their features or attributes but to make progress in specific circumstances: to accomplish a functional task, achieve a social outcome, or satisfy an emotional need, and that the product they choose is the one they believe will do that job most reliably given their situation. The implication for product design is profound: if the unit of analysis is the job rather than the user demographic or the feature set, then the competition for any product is not the category competitor but any solution the user might hire to do the same job — including doing nothing, cobbling together existing tools, or hiring a person.

The framework was developed by Harvard Business School professor Clayton Christensen, building on work by Tony Ulwick on outcome-driven innovation, and was popularised through Christensen's milkshake research — the finding that a fast food chain's morning milkshake was primarily hired not as a beverage but as a commute companion that kept a hand occupied, took a long time to consume, and staved off mid-morning hunger. No demographic analysis, feature satisfaction survey, or focus group had surfaced this job because none of them had asked the right question: not "what do you think of the milkshake?" but "what were you trying to accomplish when you hired the milkshake?"

02 — When to Use

Apply this when…

→ Users are churning and the team does not understand why — JTBD interviews with churned users reveal which job the product failed to do and what they hired instead

→ The product is growing slower than its feature quality seems to warrant — JTBD analysis often reveals the product is being positioned around attributes rather than the job users actually care about

→ Competitive analysis is producing a narrow picture — JTBD reveals competitors that the category lens misses entirely (the milkshake competing with bananas and granola bars, not other milkshakes)

→ Onboarding is underperforming — JTBD-informed onboarding guides new users to their first job completion rather than through a feature tour

→ The team is debating which features to build next — JTBD prioritisation asks which features help users complete the job more reliably, not which features are most requested

→ A new market or user segment is being entered and the team needs to understand what job that segment is trying to get done before designing anything

When NOT to apply it

Skip it when the product is a pure utility with a self-evident single job — there is no hidden motivation to uncover in a unit converter. Also skip it when the team has deep, current, validated JTBD knowledge from recent research, or when the decision is about design execution rather than product direction — JTBD informs what to build and why; it does not specify how the interface should work.

03 — How It Works

The mechanism

JTBD works by shifting the unit of analysis from the product to the progress the user is trying to make. Instead of asking "what do users want the product to do?" it asks "what is going on in users' lives that caused them to look for a solution, and what progress are they trying to make?" This shift changes which research questions matter, which competitive forces are relevant, and which product decisions are strategically important.

01

The forces that drive job-switching

Tony Ulwick's outcome-driven innovation research and Bob Moesta's switch interviews established that users hire new products — or fire old ones — when four forces reach a sufficient tipping point. The push of the current situation: the problem, frustration, or inadequacy that creates dissatisfaction with the current solution. The pull of a new solution: the attraction of a product that seems to promise the desired progress. The anxiety about switching: the concern that the new solution might not work, the cost of learning it, or the risk of the transition. The habits and inertia of the present: the comfort of the known, the sunk cost of the current solution, the social pressure of switching. Understanding these four forces for a specific job explains not just whether users will switch but when and why.

02

Functional, social, and emotional dimensions

Every job has three dimensions that must all be satisfied for the product to be fully hired. The functional dimension is the practical task: file my taxes, track my team's work, send money to a family member. The social dimension is how the user wants to be perceived by others as a result: appear organised to my manager, seem like a competent professional to my clients. The emotional dimension is how the user wants to feel: less anxious about money, more in control of my workload, confident I have done the right thing. Products that address only the functional dimension are vulnerable to replacement by any tool that does the function more efficiently. Products that address all three dimensions create switching costs that pure functional competition cannot overcome.

03

The competition is not who you think it is

The most strategically disruptive JTBD insight is competitive redefinition. Demographic analysis and category competition maps describe competition as other products in the same category: Slack competes with Microsoft Teams, Notion competes with Confluence. JTBD analysis describes competition as any solution that could do the same job: Slack competing with email, hallway conversations, and a shared Google Doc; Notion competing with a physical notebook, a filing cabinet, and the habit of keeping everything in email. This competitive redefinition changes what the product needs to be better than — not just the category competitor but every alternative the user might hire for the same job, including doing nothing.

04

How to measure it — job completion rate, switch findings, retention by job clarity

JTBD produces three types of measurable output. Job completion rate measures whether users who hire the product for a specific job are actually getting that job done — users who complete their primary job have dramatically higher retention than those who do not. Switch interview findings produce qualitative job maps — descriptions of the circumstance, the push, the pull, the anxiety, and the habit for the population of users who switched to the product — which inform positioning and onboarding. Retention by job clarity measures whether users who enter the product with a clearly defined job retain at higher rates than users who enter without one — a reliable proxy for whether onboarding is successfully aligning users with a job the product can complete.

JTBD is a research lens, not a specification

A JTBD analysis tells you what job users are hiring the product to do — it does not tell you how to design the interface, what the onboarding should look like, or which specific features to build first. JTBD informs the what and the why; design practice determines the how. Teams that treat JTBD as a specification — "users hired us for job X, so build feature X" — skip the design thinking that translates job understanding into effective product experience. JTBD is the input to design decisions, not a substitute for them.

04 — Real Example

Intercom's JTBD analysis and the three distinct hiring reasons

When Intercom conducted a JTBD analysis of their customer base in the early 2010s, the research revealed something their demographic and behavioural analytics had concealed: the same product was being hired for three completely different jobs by three different user segments, each with its own push, pull, anxiety, and competitive landscape. One segment hired Intercom to do proactive onboarding of new users — the job was "help new users activate before they churn." Another hired it for reactive customer support — "resolve customer problems faster than email." A third hired it for marketing campaigns to existing users — "reach users who have gone quiet."

Each job had different success criteria, different competitive alternatives, and different functional, social, and emotional dimensions. The onboarding job competed with hired customer success managers and drip email sequences. The support job competed with Zendesk and email. The marketing job competed with Mailchimp and in-app notification tools. Intercom's product, designed as a single unified messaging tool, was simultaneously excellent, adequate, and poor at these three jobs depending on which segment was being served. The JTBD insight directly informed the company's eventual product restructure into three distinct products — each designed to be excellent at one job rather than adequate at three.

Intercom · Early 2010s

JTBD analysis reveals multiple distinct jobs hidden behind a single user base

Doing it right — one product restructured into three job-specific products

06 — Common Mistakes

Where teams go wrong

✗ Confusing the job with the feature request. The most common JTBD mistake is treating what users ask for as equivalent to the job they are trying to do. Users who request a dashboard are not expressing a job — they are proposing a solution. The job might be "know at a glance whether my team is on track without having to check individual tasks," or it might be "feel in control of a project I am responsible for." Each of these jobs suggests different design directions. Treating the feature request as the job specification produces a product that satisfies the surface request without serving the underlying progress the user was trying to make.

✗ Defining jobs at the wrong level of abstraction. A job defined as "manage my life better" is too abstract to be actionable — it cannot be completed by any product and therefore cannot inform product prioritisation. A job defined as "add a subtask to a task in my project list" is too narrow — it describes a feature interaction, not a meaningful unit of progress. The right level of abstraction describes a job that a user could complete without your specific product, using alternative means. "Know which of my projects is at risk of missing its deadline before my weekly team meeting" is a correctly scoped job.

✗ Running JTBD research only with current satisfied users. A JTBD analysis conducted only with users who are currently happy with the product produces a map of the job the product is already doing well. The most valuable JTBD insights — the jobs the product fails at, the alternative solutions users hire when the product cannot do the job — come from users who have recently switched away, users who considered the product but chose a competitor, and users in the early stage of realising they have a job to be done. Switch interviews with churned users and non-adopters reveal the jobs the product does not do.

✗ Using JTBD to justify decisions already made. JTBD research conducted with a predetermined conclusion — "we want to build feature X, let's find the job it serves" — produces a job description shaped to fit the feature rather than one that objectively represents user needs. Genuine JTBD research starts with the circumstance and the progress the user is trying to make, then derives which product investments would serve that job most effectively. Teams that construct post-hoc job narratives to validate roadmap decisions are using JTBD as a communication framework rather than as a research method.

07 — Variations & Related Principles

Connected ideas

JTBD is a strategic framework for understanding user motivation — it operates at the level of product direction and positioning rather than interface design. Its closest relationships are with research methods that generate job data and with frameworks that apply job insight to specific design decisions.

The most important pairing is JTBD with user interviews structured as switch interviews. JTBD is a framework; switch interviews are the research method that generates the data the framework requires. Generic user interviews produce preferences and feature requests; switch interviews produce job maps with the four forces — push, pull, anxiety, habit — that drive hiring and firing decisions. Together they produce the most reliable available picture of why users adopt, retain, and abandon products.

08 — 10-Min Exercise

Run it right now

⏱ 10 minutes · Solo · No prep

The Job Audit

1. Think about the last five users who signed up for your product. For each one, write down the job you believe they hired the product to do — in one sentence, describing the progress they were trying to make, not the features they might use. "Understand their team's project status without attending a status meeting" is a job. "Use the dashboard feature" is not.

2. Now review the onboarding flow for your product. Map each onboarding step to the job: does this step help users complete their primary job faster, or does it teach them about a product feature they may not need for their specific job?

3. Count how many onboarding steps are job-relevant versus feature-oriented. If more than half of your onboarding steps are feature-oriented — explaining what the product can do rather than helping users accomplish what they came to do — your onboarding is misaligned with the job your users hired the product for.

4. Write one sentence describing the job your product is primarily hired to do — not what the product does, but what progress users are making when they are using it most effectively. If you and your three closest colleagues cannot agree on this sentence, your product has a JTBD clarity problem worth addressing before your next roadmap planning session.

10 minutes