# Jobs to Be Done

Jobs to be done asks what progress a customer is trying to make, and what they hire a product to do, to explain why people buy and switch.

**The question.** What progress is the customer trying to make, in what circumstance, and what do they hire to do it?

Also known as: JTBD. Ulwick's applied method is Outcome-Driven Innovation (ODI), which is proprietary to Strategyn.

## When to use it

- A product is not selling, and the team explains it by demographics or by features the customer "does not get."
- People switch to something that looks like a different category, and a feature comparison cannot explain the switch.
- You are about to segment a market by age, industry, or firm size, and suspect those cuts will not predict who buys.
- Interviews keep producing feature requests, and you need a way to ask about the last time they tried to get something done.

## When to avoid it

- The sale is a committee with several jobs. One job statement will hide the conflict. Map each role, then the politics.
- Demand is already known and the work is delivery. Jobs will not tell you how to build it.
- You cannot reach people who recently hired, or declined to hire, a solution. Internal brainstorming will invent a job that fits the product.
- The question is price against near-identical offers. Jobs will not settle a commodity fight.

## Overview

Jobs to be done asks what progress a customer is trying to make in a particular circumstance, and what they hire to do it. It supports the choice of what to build and whom to interview, when demographics and feature lists cannot explain a purchase or a switch.

The job has to be written without the product in it, and it has to come from stories of actual hires, fires, and abandoned attempts. Two schools share the name. Christensen's version is about circumstance and progress. Ulwick's Outcome-Driven Innovation is a proprietary process that attaches measurable outcomes to the job. Do not mix their templates and then claim a single method.

## The working pieces

### Job

The progress the customer is trying to make. Write it as a verb phrase they would recognize, at a level that does not name your product. "Feel prepared for the board meeting on the train" is a job. "Use our mobile app" is not.

### Circumstance

The situation in which the job arises, including time pressure, who else is involved, and what they have tried. Christensen's point is that the same person hires different solutions in different circumstances. A job without a circumstance is a slogan.

### Progress

What "better" means in that circumstance, functional, emotional, and social. Progress is relative to the current hire, including doing nothing. If you cannot say what would count as progress, you cannot say why someone would switch.

### Competing solutions

Whatever they hire today, including rival products, workarounds, other departments, and nothing. The set is usually wider than the category you think you are in. Switching costs and anxieties sit here, and they often beat a better feature list.

### Hire and fire

The moment of choice. People fire the current solution when the struggle to make progress outweighs the habit and the anxiety of switching. Interviews that start from that moment, the last hire or the last abandoned attempt, beat interviews about preferences.

## What it is not

- A persona with a job title. A role is not a job. Two people with the same title hire different solutions in different circumstances.
- A feature backlog rewritten as "jobs." If every job maps onto an existing epic, you worked backward from the product.
- Proof that a product will sell. It is a way of stating why people buy, so you can test that statement.

## The steps

1. **Pick people who recently hired or refused a solution.** Start from a purchase, a switch, or an abandoned attempt, not from a survey of users. Include people who use a workaround or who do nothing. Output is a short interview list tagged by what they did.
2. **Ask about the circumstance of that moment.** Ask when this last came up, what else was going on, what they tried, and what they fired. Stay in the story. Do not ask what features they want. Capture the job in their words, the circumstance, and the competing solutions.
3. **Write one job per circumstance, solution-free.** Combine stories that are the same progress in the same kind of moment. Split stories that only look similar. Rank by how often the circumstance arises and how painful a stall is. Output is a few job statements, each with competing hires.
4. **Name the struggling moments and the anxieties of switching.** Mark where today's hire fails, and what people fear they would lose by switching. Those anxieties often explain why a "better" product loses. Output is a short list of barriers that any new offer has to overcome.
5. **Test the job with behavior, not with a slide.** Put a prototype, a manual service, or a priced offer in front of people who have the circumstance. Count whether they hire it. A job statement that nobody will pay to make progress on is still a hypothesis.

## In practice

A treasury-software vendor is losing mid-market manufacturers to a cheaper tool and to Excel. The product team has been adding bank-feed features for "finance managers aged 35 to 50 in firms with 200 to 2,000 staff." Twelve interviews, each starting from the last time the person had to explain a cash miss, show two jobs, not one. Eight people hired anything that would let them walk into the Monday operations meeting sure they would not be surprised by a supplier pulling a payment. Four people hired whatever closed the month fastest for the auditors.

The cheaper rival was winning the meeting-prep job because it showed unreconciled items by supplier on one screen. Excel was winning the close job because the auditor already accepted the workbook. Circumstance, not firm size, predicted the hire. The team stopped the bank-feed roadmap for the eight, built a supplier-exception view as a prototype, and put it in front of five of them with a price attached. Three said they would switch if the view existed. The demographic segment would have kept funding bank feeds.

## What you leave with

- A handful of job statements, each tied to a circumstance and written without the product in them.
- Competing solutions for each job, including workarounds and doing nothing.
- Interview notes from hire, switch, and refusal stories, not from preference talk.
- The anxieties and switching costs that keep the current hire in place.
- One test of whether people will hire a different solution for that job.

## Failure points

### Jobs written from the product

The team restates its roadmap as customer jobs. Every interview then "confirms" the product, because that is what the team is listening for.

### A job so broad it fits anyone

"Grow my business" or "be more productive" cannot distinguish a hire. Write at the level of a moment the customer would remember.

### Demographics standing in for circumstance

Age, industry, and company size are easy to pull from the CRM. They rarely predict the hire. Two customers in the same segment fire different products for different jobs.

### Interviews about the future

People are poor at saying what they would hire later. They are good at recounting the last time they struggled. Stay in that story.

### One job for buyer and user

The person who pays and the person who does the work often hire for different progress. Mixing them produces an offer that fits neither.

The failures above are usually [Framing](https://usefulconsultingframeworks.com/your-edge/#framing): the wrong problem was chosen before this framework was applied.

## Origin

Two closely related strands share the name. Anthony Ulwick developed Outcome-Driven Innovation in the early 1990s at Strategyn, treating the job as a process the customer is trying to execute and attaching measurable desired outcomes to each step. Clayton Christensen popularized jobs-to-be-done for managers, first in The Innovator's Solution (2003) with Michael Raynor, then in the September 2016 Harvard Business Review article "Know Your Customers' Jobs to Be Done" with Taddy Hall, Karen Dillon, and David Duncan, and in Competing Against Luck (2016). Christensen's version stresses circumstance and the progress the customer is trying to make, including social and emotional progress, and the idea that customers hire a product.

Ulwick introduced Christensen to the outcome-driven work. The two schools now differ on method, and each side has its own vocabulary and products. ODI is proprietary to Strategyn. The jobs idea as a way of seeing demand is not licensed. This note uses Christensen's progress-and-circumstance language and does not reproduce Strategyn's templates or outcome-statement format.

## Further reading

- [Know Your Customers' Jobs to Be Done](https://hbr.org/2016/09/know-your-customers-jobs-to-be-done). Clayton Christensen, Taddy Hall, Karen Dillon, and David Duncan, Harvard Business Review, September 2016. The clearest short statement of the progress-and-circumstance view. Access is metered.
- [Jobs to Be Done, Strategyn](https://strategyn.com/jobs-to-be-done/). Anthony Ulwick's account of JTBD and Outcome-Driven Innovation, including his claim of origin. Read it to see the other school, and treat ODI as a proprietary method.

## Related frameworks

- [Value Proposition Canvas](https://usefulconsultingframeworks.com/frameworks/value-proposition-canvas/): Matches jobs, pains, and gains to an offer. Pick it when the job is named and you are designing what to sell for it.
- [Business Model Canvas](https://usefulconsultingframeworks.com/frameworks/business-model-canvas/): Maps how the whole business makes money. Pick it when the job is clear and the question is whether the model around it works.
- [Kano Model](https://usefulconsultingframeworks.com/frameworks/kano-model/): Sorts features by how they move satisfaction. Pick it when you already know the job and need to choose which attributes to fund.
- [Segmentation, Targeting, Positioning](https://usefulconsultingframeworks.com/frameworks/stp/): Cuts the market into segments you choose to serve. Pick it when the question is which groups to target, after the job is understood.
- [Design Thinking](https://usefulconsultingframeworks.com/frameworks/design-thinking/): Gives methods for watching people in context. Pick it when you have not yet seen the circumstance in which the job arises.

Last updated October 20, 2026.
