The Jobs-to-be-Done framework, explained

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.

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

• 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

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