Jobs to Be Done Framework

The Jobs to Be Done (JTBD) framework starts from a deceptively simple reframe: instead of asking who your customer is, ask what job they're "hiring" your product to do. That shift — from demographics to motivation — has proven durable enough that it's still the go-to framework product teams reach for when demographic and behavioral segmentation alone isn't producing useful product decisions.

The core insight: people hire products, they don't buy features

The framework's founding metaphor, borrowed from Clayton Christensen's original formulation, is that customers "hire" a product to accomplish a specific job, the same way you'd hire a contractor for a specific task. If the product does the job well, you "rehire" it (keep using it, buy it again); if it doesn't, you "fire" it and hire something else. This reframing matters because it forces a question that pure demographic segmentation skips entirely: two customers who look identical on paper — same age, same income, same job title — can be hiring completely different jobs from the same product category, while two very different-looking customers might be hiring the exact same job.

The classic illustration of this is the milkshake study: a fast food chain trying to sell more milkshakes discovered, through JTBD research, that a huge share of milkshake purchases happened in the morning, bought by commuters, consumed alone in a car. The "job" wasn't dessert — it was a filling, one-handed, slow-to-consume breakfast that would keep someone occupied and full during a long commute. That's a completely different product opportunity than "make a better-tasting milkshake," and it's the kind of insight demographic segmentation (age, income, family status) would never surface, because the job has almost nothing to do with who the customer is and everything to do with the situation they're in.

Three dimensions of every job

A genuinely well-applied JTBD framework looks at three distinct dimensions of the job a customer is trying to get done, not just the surface-level functional task:

• Functional job — the practical task or problem being solved. For a luxury watch, that's telling time.
• Emotional job — how the customer wants to feel about themselves while using the product. For the same watch, that might be feeling accomplished, confident, or established.
• Social job — how the customer wants to be perceived by others. Still the same watch: being seen as successful, tasteful, or established by people around them.

A product built to satisfy only the functional dimension while ignoring the emotional and social dimensions is usually competing purely on price and features — which is a much harder, lower-margin place to compete than a product that understands and serves all three dimensions of the job.

Real examples worth studying

Several well-known products map cleanly onto specific jobs, which is useful for building intuition about how the framework actually gets applied:

• Uber solved the job of getting reliable transportation quickly and without friction — not "owning a car is inconvenient," but the specific moment-to-moment job of needing to get somewhere right now without the uncertainty of hailing a cab or waiting for a bus.
• Slack addressed the job of staying coordinated with a team without the clutter and latency of email — a job that existing tools (email, in-person meetings) were serving poorly for fast-moving teams.
• Duolingo and Netflix are both frequently cited JTBD case studies as well, each mapped against functional (learn a language / be entertained), emotional (feel a sense of progress / feel relaxed), and social (show off language skills / have something to discuss with friends) dimensions of their respective core jobs.

Where the biggest opportunities live

The strategic application of JTBD that product teams actually use: map the jobs your customers are trying to get done by two axes — how important the job is to them, and how well existing solutions (yours or competitors') currently serve it. The biggest product opportunities cluster in jobs that are highly important to customers but poorly served by anything currently available. A job that's important but already well-served is a crowded, competitive space; a job that's unimportant, even if poorly served, isn't worth building for. It's the intersection — important and underserved — that tends to produce genuine product opportunities rather than incremental feature additions to an already-served job.

How to actually apply this

Interview around situations, not personas. JTBD research typically involves interviewing people about the specific circumstance that led them to seek out (or "hire") a solution — what was happening right before, what alternatives they considered, what finally pushed them to act — rather than asking abstract questions about preferences or asking them to describe themselves demographically.

Look for what people are currently "firing" and why. Understanding why customers abandon or switch away from a current solution often reveals the job that solution was failing to serve, which is frequently more instructive than understanding why they chose it in the first place.

Write job statements, not feature requests. A well-formed job statement takes the shape "when [situation], I want to [motivation], so I can [expected outcome]" — this format forces clarity about the actual circumstance and goal, rather than jumping straight to a feature or solution.

Check all three dimensions before building. A product roadmap built purely around the functional job while ignoring emotional and social dimensions is likely to underperform against a competitor who's built for the same functional job but has also nailed how the product makes people feel and how it makes them look to others.

JTBD isn't a replacement for demographic or behavioral data — it's a complementary lens that answers a different question. Demographics tell you who's buying; JTBD tells you why, in terms specific enough to actually inform what to build next, rather than which segment to target with the same product.

Sources: ProductPlan: Jobs-To-Be-Done Framework, Product Leadership: JTBD Framework Explained, Parallel HQ: What Are Jobs to Be Done — 2026 Examples