Jobs-to-be-Done Framework: Definition, Template & Examples (2026)

Jobs-to-be-Done (JTBD) is a framework that reframes what people buy. Instead of asking "what features should this product have?", JTBD asks "what job is the customer hiring this product to do?". The product is incidental; the job is the durable unit of customer demand. Get the job right and you understand the market.

The framing was developed by Clayton Christensen and colleagues at Harvard Business School, building on earlier work by Tony Ulwick. The canonical example: McDonald's wanted to sell more milkshakes. Years of customer surveys produced incremental tweaks (thicker, sweeter, more flavors) and no growth. When researchers asked instead "what job were buyers hiring the milkshake to do?" they discovered ~40% of milkshakes were bought before 8am — commuters used them as a one-handed, slow-to-finish, mildly entertaining solution to a boring drive. That job — make my morning commute less dull — competed with bagels, bananas, and boredom itself, not with other milkshakes.

The core moves

JTBD's contribution is three reframings:

1. Customers don't buy products; they hire solutions for jobs. A drill is hired to make a hole in a wall. A spreadsheet is hired to think through a decision. A self-help book is hired to feel like you're making progress on a problem you're not yet ready to act on.
2. The unit of competition is the job, not the product category. Your milkshake competes with bananas. Your CRM competes with spreadsheets and post-it notes. Your meditation app competes with a glass of wine.
3. The job is stable; the solutions change. People have been hiring something to "communicate quickly with a distant friend" for centuries (letters → telegraph → telephone → SMS → WhatsApp). The job is the same. The hired solutions change as technology lets them be better-served.

When to use JTBD

• Defining a new product: forces you to articulate the customer's actual goal rather than your assumed feature list
• Repositioning an existing product whose growth has stalled despite good execution — usually means the wrong job is being targeted
• Identifying real competitors before market research overstates the obvious ones and misses the actual substitutes
• Customer-interview design: gives you a question structure (when did you last hire X? what were you trying to accomplish? what almost stopped you?) that produces sharper insights than "what features do you want?"

Skip JTBD when you're optimizing within a well-defined job (e.g., faster checkout, better latency). It's a framing tool, not an optimization tool.

How to actually use it

The lightweight version (good for most teams): run 5–8 interviews with recent buyers using the JTBD interview structure, then synthesize.

1. Pick a recent purchase, narrow the window. "Tell me about the last time you bought/used this — when was it, what triggered it?" Specific recent events produce concrete answers; abstract questions produce abstract answers.
2. Walk the timeline backwards from purchase. First thought → first search → first comparison → decision → first use → reaction. The triggering event is rarely what people first say; keep going further back.
3. Identify what they hired the product to do. Listen for the goal, not the activity. "I bought a Notion subscription" is the activity. "I wanted to stop feeling like my second brain was leaking out my ears" is the job.
4. Identify what almost stopped them. Anxieties about switching, habits they had to break, social signals they were worried about. These tell you the friction attached to your job.
5. Cluster across interviews. When 5+ interviews independently surface the same job, you have signal. When jobs vary widely, your product is being hired for multiple jobs and you're under-serving each.

The trap

The trap is treating JTBD as a category of language rather than a discipline of research. Teams adopt the vocabulary ("our job is to help users feel productive") without actually doing the interviews. The result is a more impressive-sounding version of the same feature list.

The corrective: never write a "job" you didn't hear in an actual customer's words. The McDonald's milkshake job wasn't generated by a strategy offsite. It came from a researcher noticing that 40% of purchases happened pre-8am and asking those buyers why.

What JTBD reveals that feature lists hide

Two examples from real engagements:

• A B2B SaaS team thought they competed with three other SaaS products. JTBD interviews revealed their real competition was Excel + an internal champion's heroism. Their pricing, sales motion, and onboarding all needed to change — they were positioned against software-savvy decision-makers but were actually being evaluated by spreadsheet-savvy operators.
• A consumer mobile app had years of stagnant retention. JTBD interviews showed half the users were hiring it to feel productive while procrastinating something harder. The team had been optimizing the "actually be productive" job. Once they accepted what users were really hiring it for, the redesign was obvious — and retention jumped.

JTBD vs Personas vs User Stories: pick the right artifact

Teams routinely confuse these three because they all "describe the customer." They don't — they describe different layers of the same problem, and using the wrong one produces predictable failures:

	Jobs-to-be-Done	Personas	User Stories
What it describes	A job the customer is trying to make progress on	A type of customer with attributes	A feature a user wants and why
Format	"When [situation], I want to [motivation], so I can [outcome]"	Named profile + demographics + goals + pain points	"As a [role], I want [feature], so that [benefit]"
Best used for	Defining what business you're in; finding non-obvious competitors	Marketing segmentation; design empathy artifacts	Backlog grooming; sprint planning
Worst used for	Sprint-level feature decisions	Strategic positioning (personas hide jobs)	Discovery (you're already assuming the feature)
Stable over time?	Yes — jobs change slowly	Decays as the market evolves	Each story is disposable
When you'd write it	Quarterly or before a pivot	Annually or for a new market entry	Every sprint

The sequencing rule: JTBD comes first, personas come second, user stories come last. Skipping to user stories without a clear job is how teams ship features for problems no one is paying to solve. Jumping from personas to features (without the job in between) is how teams build "what someone like Maya wants" without checking whether Maya is actually trying to do anything with it.

Framework's JTBD vs Personas compare page goes deeper on the first two, including when personas remain the right tool despite JTBD's broader reach.

When JTBD isn't the right tool

• Highly commoditized purchase decisions where the job is obvious and the buyer cares about a single dimension (price, speed). JTBD reveals nothing new.
• Greenfield exploration with no product yet. JTBD requires that something be getting hired — you need real buyers to interview. For pre-product exploration, use First Principles instead.
• Tactical UX decisions. JTBD operates at the level of "what business should we be in"; it's the wrong granularity for "should this button be left or right of the form."

Related frameworks

• JTBD applied to Instagram Stories — worked example of JTBD on a real consumer product launch
• SWOT analysis — pair when you need to map JTBD insight onto strategic position
• Kano Model — once the job is right, Kano classifies which features satisfy vs delight vs dissatisfy
• Lean Canvas — operationalizes a JTBD insight into a testable business model
• Five Forces — useful counterweight: JTBD looks customer-out; Five Forces looks industry-in
• JTBD for healthcare & digital health — industry playbook for the category where the buyer is rarely the user

Want examples? The full JTBD entry → has worked applications across consumer, B2B SaaS, and services.