Jobs to Be Done (JTBD) is a framework for understanding why customers buy or use a product. Instead of describing customers by demographics or features they request, JTBD describes the progress they are trying to make — the “job” they hire a product to do.
The classic example, from Clayton Christensen, is a fast-food chain studying milkshake sales. The job customers were hiring the milkshake for was making a long, dull morning commute more interesting and keeping them full until lunch. Once that job was visible, the design choices became obvious — make the shake thicker so it lasts longer, sell it from a drive-through so it is fast, and stop competing with breakfast pastries that customers were clearly rejecting for the same role.
The shape of a job statement
When [a situation], I want to [motivation], so I can [expected outcome].
For example: “When I’m leading a kickoff with a new client, I want to align everyone on what we’re building, so I can avoid scope arguments later."
That statement is product-agnostic. A whiteboard, a slide deck and a story mapping tool could all be hired for that job — and JTBD asks why someone would hire one over the others.
Why teams use JTBD
- It clarifies competition — your real competitors are everything someone could hire for the same job, not just other products in your category.
- It survives feature changes — jobs are stable even as products evolve.
- It pairs well with personas and customer journeys, providing the motivation that personas and journeys can lack.
- It anchors prioritisation in customer outcomes rather than internal opinion.
Common pitfalls
- Confusing tasks with jobs. “Click the export button” is a task. “Get this plan into the format my client expects” is a job.
- Writing jobs that are really feature requests in disguise — “I want to filter by tag” is not a job; it is a solution.
- Stopping at one job statement when a single product is hired for several different jobs by different segments.
Further reading
