Jobs to Be Done

The idea

Clayton Christensen argued that customers do not buy products because of who they are. They hire a product to make progress in a particular circumstance, and fire it when something does the job better. In "Know Your Customers' Jobs to Be Done" (Harvard Business Review, September 2016), written with Taddy Hall, Karen Dillon and David Duncan, he set out the idea for a wide audience. The best-known illustration is the milkshake: a fast-food chain found that many morning milkshakes were bought by commuters who wanted something filling and slow to finish on a long, dull drive. Their competition was bananas and bagels, not other milkshakes.

A job has functional, social and emotional sides, and it is defined by its circumstance: who, where, when, and what else is going on. Demographics and product categories tell you who might buy; the job tells you why. Christensen popularised the framing, and practitioners such as Tony Ulwick (outcome-driven innovation) and Bob Moesta (switch interviews) developed their own methods for uncovering jobs.

Why it works

Jobs are more stable than solutions. People have needed to pay suppliers, onboard staff or find a document for decades; the tools change. Designing around the job gives you a requirement that survives technology shifts.

The job reveals the real competition. If the job is "get a quick answer on an order's status", your rival may be a phone call to a colleague, not another portal. That changes what good enough looks like.

Circumstance explains behaviour that personas cannot. The same person hires different things on Monday morning and on Friday at month-end. Circumstance is what you can design for.

Where it applies

• Product and platform strategy, deciding which capabilities to invest in and which to leave to commodity tools.
• Domain modelling, where jobs point to the workflows and boundaries that matter to users rather than to internal departments.
• Vendor selection, judging tools against the job and its circumstances, not against a feature checklist.
• Enterprise portfolio reviews, where several systems turn out to be hired for the same job.

How to apply

1. Interview about a real recent moment. Ask what happened just before someone switched to, or away from, a tool. Look for the struggle, not opinions.
2. Write the job as progress in a circumstance. "When I am closing the month with missing invoices, help me see what is blocking payment so I can chase the right person."
3. List what is hired today. Include workarounds; they are the true competitors and often the cheapest baseline.
4. Trace architecture to jobs. For each major component, name the job it serves. Components that serve no job are candidates for removal.
5. Prioritise the underserved jobs where the current workaround is most painful.

Example scenario

An insurer planned a new broker portal with every policy entity exposed as a screen, mirroring the core system's data model. Usage of the old portal was low, and the business case assumed more features would fix it.

The architects ran a dozen interviews and found brokers hired the portal for one main job: "when a client calls with a claim question, give me an answer while they are still on the line." Today they phoned the claims desk instead. The team rebuilt around that job, with a fast claim-status lookup backed by an event-fed read model, and dropped most of the planned screens. The architecture got simpler because the job, not the database, set its shape.

Questions to ask

When not to use it

• Pure compliance or infrastructure work, where the requirement is fixed by regulation or a platform constraint and interviews add little.
• Well-understood, commoditised needs, where buying the standard tool is clearly right.

How it misleads you