Jobs to be done

What it is

The framework was developed by Clayton Christensen, Bob Moesta and colleagues at Harvard Business School through work at Innosight and Rewired Group, and popularised through Christensen's 'Competing Against Luck' (2016) and the 'When Coffee and Kale Compete' book by Alan Klement. The framing came from asking why customers buy what they buy — and finding that demographic profiles and feature preferences predicted purchase far less reliably than the circumstances that triggered the purchase and the underlying job the customer wanted done.

A JTBD statement follows a specific structure: 'When [situation], I want to [motivation], so I can [expected outcome].' The situation names the trigger, the motivation names the functional goal, and the outcome names what success looks like.

Why it matters

Product decisions get made against a lot of noise — feature requests, competitor mimicry, stakeholder opinion, personality-based personas. JTBD cuts through by asking what the user is genuinely trying to accomplish. Two users with identical demographics might be hiring the same product for entirely different jobs; two users with different demographics might share a job. Designing to the job reveals opportunities feature-list thinking misses.

When to use it

Product strategy, feature prioritisation, competitive analysis, market sizing, discovery research, opportunity identification. JTBD is most useful when the team needs to decide what to build (or not to build) — less useful once the job is settled and execution is the challenge.

What it looks like in practice

A property portal might discover through JTBD interviews that some users are hiring it to 'quickly rule out unsuitable areas' rather than 'find a house to buy'. Designing to the ruling-out job changes what the product should surface — negative filters, quick disqualifiers, wider area views — from what a 'find a house' framing would suggest.

A note-taking app might find users hiring it to 'think out loud without commitment' as opposed to 'store notes for later retrieval'. The thinking-out-loud job needs frictionless capture and forgiving structure; the storage job needs strong retrieval and organisation. Different jobs, same product surface, different design priorities.

What people get wrong

• Treating JTBD as a replacement for personas rather than a complement. Personas describe who; JTBD describes what they're trying to do. Both are useful; neither fully substitutes for the other.
• Writing job statements at the wrong abstraction. 'I want to feel happy' is too abstract; 'I want to click a blue button' is too tactical. The useful abstraction sits at the outcome level.
• Skipping the situation. The trigger context is often where the design opportunity lives — the job looks different at 2am on a phone in bed than at 10am at a desk.
• Using JTBD to rationalise features already decided. The framework only works when it's genuinely used to challenge assumptions upstream.

Learn next

JTBD sits alongside mental models (what the user expects the product to do), personas (who the user is), and user journeys (what the user does over time). It intersects with UX research methods, particularly the switch interview format Moesta popularised.

Reviewed 29 September 2026 · Editorial standards