012 min
What Jobs to Be Done claims
Clayton Christensen, Taddy Hall, Karen Dillon and David S. Duncan set this idea out in its current form. They wrote "Know Your Customers' 'Jobs to Be Done'" (Harvard Business Review, September 2016). The article opens with a McKinsey poll of executives worldwide. 84% said innovation was extremely important to their growth strategy. 94% were unhappy with how their own organisation performed at it. That gap is the problem the theory was written to explain. Companies hold more customer data than ever. They still cannot say why anybody bought anything.
The reason, in this account, is that most customer data shows correlation rather than cause. Correlation means two things tend to appear together. Cause means one of them made the other happen. A dashboard can tell you that most buyers live in cities and are middle-aged. That tells you who bought. It does not tell you what happened in their day that made them buy.
So the thing you study changes:
- Not "who is the customer" but "what situation were they in"
- Not "which features do they want" but "what were they trying to get done"
- Not "who else sells this category" but "what else could they have used instead"
One thing is worth settling before you read anything else about Jobs to Be Done. The name covers two methods that disagree with each other. Most of the confusion around the term comes from one name being used for both.
022 min
The two rival schools of Jobs to Be Done
Two groups use the name for approaches that run different research. They produce different documents. They define a job differently.
Jobs as Progress is the Christensen line, carried on by Bob Moesta and Alan Klement. Here a job is the progress someone wants in a moment when they are struggling. That progress has functional, emotional and social parts. You find it through switch interviews. In a switch interview you talk to someone who recently changed solutions, and rebuild the timeline of their purchase with them. You keep going until you can see what made them give up the old solution, and what made the new one attractive. The output is a story about a single moment.
Jobs as Activity is Tony Ulwick's line, published as Outcome-Driven Innovation (ODI). Here a job is a function a person is trying to carry out. The person carrying it out is the job executor. You map the job into steps. Then you write outcome statements. An outcome statement names one improvement people want at one step (Strategyn). It is worded so people can rate it for importance and satisfaction in a survey. The output is a ranked list of outcomes that people rate as important but are not satisfied with.
| Jobs as Progress | Outcome-Driven Innovation | |
|---|---|---|
| What a job is | Progress wanted in a moment of struggle | A function a person carries out, mapped into steps |
| Core research | Switch interviews, small numbers | Outcome statement surveys, large numbers |
| What you end up with | A story about what caused a purchase | A scored list of opportunities |
| Strongest at | Explaining why demand appeared | Sizing and ranking where to invest |
| Where to start reading | Christensen et al., HBR 2016 | Ulwick, HBR 2002 and HBR 2008 |
The difference is not one of emphasis. Ulwick argues that Christensen's milkshake example is fundamentally flawed. He also argues that vague definitions of the job are the main reason this work fails in practice (Ulwick, The Marketing Journal). Christensen's side kept the story-based method and built a following on it. The argument is real and unresolved.
The practical consequence is small, but it matters. If someone hands you a Jobs to Be Done deliverable, ask which school produced it before you judge it. A story-based job statement scored against ODI's standards will look imprecise. An outcome statement judged against the progress school will look like a requirements document that says nothing about the person. Each criticism is valid inside the school that makes it, and useless outside it.
032 min
Where Jobs to Be Done came from
Jobs to Be Done has two origin stories. Only one of them gets repeated.
- 1990 — Tony Ulwick works out the approach by applying Six Sigma thinking to innovation. A factory process can be defined by the outputs it has to hit. So, he argued, can the process of inventing a product.
- 1991 — the process itself starts.
- 1992 — the first big success. Ulwick helps Cordis Corporation reinvent its angioplasty balloon product line.
- 1999 — Ulwick names the approach Outcome-Driven Innovation.
- 1999-2000 — Ulwick introduces the approach to Clayton Christensen (Strategyn, History of JTBD; Ulwick, 2016).
- January 2002 — Ulwick publishes "Turn Customer Input into Innovation" in Harvard Business Review.
- December 2005 — Christensen publishes "Marketing Malpractice: The Cause and the Cure" in HBR. It is the first appearance in print of the version most people now know.
- May 2008 — Ulwick publishes "The Customer-Centered Innovation Map" in HBR, the job-mapping method.
- September 2016 — the Christensen, Hall, Dillon and Duncan HBR article appears, followed by an HBR IdeaCast episode in December. Together they put the phrase into everyday product vocabulary.
The order explains the split better than any argument about it does. Ulwick built the method first. Christensen explained the idea as a story later. Ulwick's method came out of quality management, where a requirement you cannot measure is not a requirement. Christensen's came out of disruption theory. That theory explains why established companies lose to cheaper, simpler products. The established company has better data and more money. The product that beats it looked unserious at first.
So one school produces numbers and the other produces stories. Neither is a corrupted copy of the other. They were built to answer different questions, and then given the same name. That shared name causes nearly every argument you will see about what Jobs to Be Done "really" is.
042 min
The McDonald's milkshake story, and the argument about it
McDonald's wanted to sell more milkshakes. The usual approach had already been tried. Find the people who buy milkshakes. Ask them how the milkshake could be better. Make it thicker or sweeter or cheaper, based on what they said. Sales did not increase.
The team working with Bob Moesta and the Re-Wired Group asked a different question. They did not ask buyers what they wanted. They looked at when milkshakes were actually bought, and what else was going on around the purchase. A large share were sold early in the day. Those buyers were alone, in a car, and taking the milkshake with them.
They had a long, boring drive ahead. They needed something to occupy a spare hand and make the drive more interesting. That is the job. A focus group would have called the thickness a defect. Thickness is the reason the shake lasts the length of the drive.
The 2016 HBR retelling draws one lesson from this. The product's real competition is whatever else could have been bought for that drive. It is not the other milkshakes on the menu board.
Why the milkshake story is contested
Ulwick's objection is not a footnote. He argues the example is fundamentally flawed as a demonstration of the theory. He has also written directly against the segmentation logic people draw out of it (Strategyn, "Market Segmentation Is Soured by Milkshake Marketing"). The story is the single most repeated thing about Jobs to Be Done. So a great many teams have learned the idea entirely from an example that one of its two originators rejects.
Use it for what it is good at. It shows quickly what it means to stop describing the buyer and start describing the situation. It is not a method. The number of times it has been retold is not evidence for it.
052 min
The quarter-inch drill quote is not Theodore Levitt's
"People don't want a quarter-inch drill. They want a quarter-inch hole." This is the line most often used to introduce Jobs to Be Done. It is almost always credited to the wrong person.
| Year | Who | What actually happened |
|---|---|---|
| 1942 | C.C. Wagner, Provident Mutual Life Insurance | Earliest known use, in a newspaper advertisement in Somerset, Pennsylvania |
| 1947 | Percy H. Whiting, "The Five Great Rules of Selling" | Credits the line to Leo McGivena |
| 1969 | Theodore Levitt, "The Marketing Mode" | Cites McGivena, and does not claim the line as his own |
| 2005 | Clayton Christensen, "Marketing Malpractice" (HBR) | Credits it to Levitt |
Quote Investigator traced the line back through each source. It found the 1942 advertisement and the 1947 credit to McGivena.
There are two reasons this is worth the space, rather than being a small pedantic note.
The first is that the wrong credit fails in the same way the theory warns about. A famous name is a correlation, not a cause. Levitt was the best-known marketing academic of his generation, so people assumed the line was his. Tracing the real chain takes work that nobody did for decades. The easy answer was already available, so nobody looked further.
The second reason is practical. If you use the line to make an argument in a meeting, credit it accurately or drop the credit entirely. "There's an old line in selling that people want the hole, not the drill" costs you nothing and is true. Name Levitt as the author, and the one person present who has checked will correct you.
062 min
How to write a Jobs to Be Done job story
The job story is the document most teams actually carry out of Jobs to Be Done and into a backlog. It came out of Intercom in 2013, from Paul Adams and Alan Klement. Klement gave the format its name.
When [situation], I want to [motivation], so I can [expected outcome].
The first clause is the whole change. A user story opens with a persona: as a marketing manager, I want. A persona describes a person, and that description stays true all day. So it never tells you when the need appears. The job story opens with a circumstance instead. The moment that starts the need is written into the sentence (Intercom, 2013).
Here is an illustrative one, for a shared support inbox. When a customer replies to a conversation I closed an hour ago, I want it back at the top of my queue, so I can answer before they give up. The engineer reading that knows when the behaviour should happen. They also know what "done" looks like. A persona sentence about a support agent wanting a tidy inbox gives them neither.
Writing them without fooling yourself
The situation must be observable.
"When I am busy" is not a situation. "When three conversations arrive while I am writing a reply" is.
The motivation is not the solution.
If the middle clause names a control — a button, a filter, a notification — you have written a feature request with the wording changed.
The outcome has to be something the person cares about
, not a system state. "So the queue is sorted correctly" is a system state.
One story, one situation.
A story with "and" or "or" in the first clause is two stories.
Job stories are not always better than user stories. Mike Cohn's Mountain Goat Software is about as close to the source of the user story practice as you can get. It published a piece treating job stories as a viable alternative rather than a replacement. That is the honest position. Use the job story where the moment that starts the need is what explains the need. The persona form still reads better where the whole point is that different roles need different things.
072 min
Choosing which Jobs to Be Done method to run
The two schools are not interchangeable. So the first decision is which question you are actually asking. Work down this list. Stop at the first line that matches.
- You need to know why people switched to you or away from you. Run switch interviews. Find people who bought from you, or left you, in the last few weeks, while they still remember the sequence. Rebuild the timeline until you can see the moment the old solution stopped being acceptable. This is what the progress school is built for.
- You need to rank where to invest across a whole market. Use Outcome-Driven Innovation. Map the job into steps and write outcome statements. Get them rated for importance and satisfaction at a sample size where the gaps mean something (Ulwick, HBR 2008).
- You need to redraw your competitor set. Either school gets you there, and you need fewer people than you think. The output is a list of things customers bought instead. That list rarely matches the one in your competitive analysis.
- You need to write the next six tickets. Neither. Use job stories, which come after both. Go back to research when the stories start being guesses.
What each method costs before it pays
| Switch interviews | Outcome-Driven Innovation | |
|---|---|---|
| Needs | Access to people who recently switched | A sample large enough for the ratings to separate |
| Fails when | Nobody has switched recently | You cannot reach that sample |
| Turnaround | Days to weeks | Weeks to months |
| Best first use | A product whose demand you cannot explain | A roadmap argument nobody can settle |
The cost line is the one teams skip. Outcome-Driven Innovation run on twelve responses is not Outcome-Driven Innovation. It asks the same questions a small survey asks, using different terms. Switch interviews with people who bought two years ago test how well those people remember. They are not evidence.
082 min
Where Jobs to Be Done goes wrong
Ulwick has written a piece called "How to Fail at Jobs to Be Done". Its focus is the definition of the job itself. Get the job wrong and every later step carries the same error, however good the research process looks (The Marketing Journal).
Each failure mode has a warning sign you can check in a document review, without running any research at all.
- A feature request called a job. Teams often submit a feature request and call it a job. Warning sign: the job statement names a control. "Customers want to filter by owner" is a request. A real job still exists if the product is deleted.
- The job is written at the wrong level. Too broad and it is true of every company on earth. "Be more productive" cannot be wrong, which is why it is useless. Too narrow and it describes a single interaction. Warning sign: you cannot name one competitor outside your own category, or you can name only one.
- Personas renamed as jobs. Warning sign: the job statements match the persona list you already had, one for one. Real jobs cut across people. The same person has different jobs on different days.
- One interview treated as a market. Warning sign: a slide says "customers told us" and the sample is three. The progress school's methods use small samples by design. That makes them good at producing a theory about cause, and bad at sizing anything.
- The milkshake used as method. Warning sign: the research plan is "observe when people buy and infer the job". That is a retelling of an anecdote, not a procedure.
- The job discovered conveniently. Warning sign: every job found supports something already on the roadmap. Research that never surprises anybody was not research.
The common thread is that Jobs to Be Done has no built-in way to prove itself wrong. A badly defined job still produces clean-looking documents: statements, maps, stories, a workshop everybody enjoyed. The method will not tell you the job was wrong. Only a prediction that fails will. So write down what the job says should happen, before you go and build on it.
092 min
Jobs to Be Done vs personas and user stories
These three get positioned as rivals, and teams really do choose between them. So the difference that separates them is worth naming precisely.
A persona describes a person and stays true whatever the moment. A job describes a circumstance and changes as the circumstance does. That is the entire difference. It also explains why the same person can be two customers. Someone buying software for a team of forty is not in the same segment as that same person buying a note-taking app for themselves.
| Describes | Stable across | Answers | Breaks down when | |
|---|---|---|---|---|
| Persona | A type of person | Situations | Who are we building for | The same person behaves differently by context |
| Job | A situation and the progress wanted in it | People | Why did they buy | The job is written too broadly to limit anything |
| User story | A requirement, framed by role | Neither | What are we building next | The role says nothing about when the need appears |
They are not mutually exclusive. Personas remain useful for the things jobs are bad at. They tell you who to recruit for research. They tell you whose vocabulary to write interface text in. They tell you which accessibility needs are actually represented in your audience. The Nielsen Norman Group covers directly how personas and jobs to be done relate. Read it if you want the usability view rather than the strategy view.
The failure worth avoiding is running all three as separate documents that nobody reconciles. The workable chain is short. A job explains why demand exists. A job story turns one part of that job into something buildable. A persona tells you whose language the interface should use. Three documents, one argument. Your job statements and your personas may contradict each other. If both still stay in the deck, at least one is not being used to make decisions.
?7 questions
