Jobs to Be Done: The Framework Explained Properly

Jobs to Be Done is a framework that says people do not buy products — they hire them to make progress in a specific circumstance, and understanding that circumstance predicts behaviour better than knowing anything about the customer themselves.

The central claim is a reframe of what a market is. Conventional segmentation groups customers by attribute: age, income, industry, company size. Jobs to Be Done groups them by situation — what they were trying to get done at the moment they reached for a solution. Two people with nothing demographically in common can be hiring the same product for the same reason, and the same person can hire completely different products on Tuesday morning and Saturday night.

Where Jobs to Be Done comes from

The lineage usually starts with Theodore Levitt’s observation that people buying a quarter-inch drill do not want a drill — they want a quarter-inch hole. The idea that customers buy outcomes rather than objects is much older than the framework built on it.

Clayton Christensen developed that instinct into the theory of innovation now known as Jobs to Be Done, arguing that the reason so many well-researched products fail is that companies collect enormous amounts of data about customers and almost none about the situations customers find themselves in. The most-cited illustration involved a fast-food chain trying to improve milkshake sales: the breakthrough came from noticing that a large share were bought early in the morning by solo commuters, who were not buying a beverage so much as hiring something to make a long, dull drive tolerable, with one free hand, for the next twenty minutes. The competition was not other milkshakes. It was bagels, bananas, and boredom.

Anthony Ulwick built a parallel and more quantitative tradition, Outcome-Driven Innovation, which treats a job as a process to be mapped and success as a set of measurable outcome statements. Bob Moesta contributed the demand-side interviewing methods that most practitioners now use to reconstruct why someone actually switched.

The competition was not other milkshakes. It was bagels, bananas, and boredom.

The two schools, and why the difference matters

Most explainers blur these together, which is why teams often find Jobs to Be Done hard to apply. They are genuinely different in method.

The Christensen school treats a job as progress a person is trying to make in a circumstance, including emotional and social dimensions. It is qualitative, narrative, and interview-driven. Its strength is discovering jobs nobody had articulated. Its weakness is that “job” is defined loosely enough that two researchers can produce different answers from the same interviews.

The Ulwick school treats a job as a functional process, decomposed into steps, with dozens of desired-outcome statements phrased in a fixed grammar — direction of improvement, unit of measure, object of control. It is quantitative and survey-driven, producing an opportunity score that ranks unmet needs. Its strength is rigour and prioritisation. Its weakness is that it presumes you already know which job to study.

The practical resolution: use the Christensen approach to find the job, and the Ulwick approach to prioritise work within it. Teams that pick one and treat it as the whole of Jobs to Be Done tend to get either rich stories they cannot act on or precise measurement of the wrong thing.

The four forces of switching

The most immediately useful component of Jobs to Be Done explains why people change — or, more often, do not. The model is generally credited to Bob Moesta and the demand-side research tradition rather than to Christensen directly.

Push of the situation — the frustration with the current state
Pull of the new solution — the attraction of the alternative
Anxiety about the new — fear of the switch itself, learning cost, risk of being wrong
Habit of the present — the inertia of what already works well enough

Switching happens only when push plus pull exceeds anxiety plus habit. This has a sharp consequence most product teams resist: the strongest competitor is usually not another product but non-consumption — the customer continuing to do nothing. And the most effective intervention is frequently not adding pull by building more features, but reducing anxiety, which is a job for onboarding, guarantees, migration tooling, and proof.

Teams over-invest in pull because it is the part they control most visibly. The forces model says roughly half the battle is on the other side of the equation.

The strongest competitor is usually not another product but non-consumption — the customer continuing to do nothing.

How to run a Jobs to Be Done study

Interview switchers, not users. The people worth talking to are the ones who recently changed something — bought, cancelled, or switched. They can reconstruct a decision. Satisfied long-term users cannot; they will describe preferences rather than causes.

Reconstruct the timeline backwards. Start from the purchase and work back to the first thought. When did you first realise something needed to change? What did you do next? What did you try that did not work? Who else was involved? The aim is a sequence of events, not opinions.

Listen for the emotional and social layer. Functional jobs are rarely the whole story. There is usually something about how the person wants to feel, or be seen, running alongside the practical task.

Define the job without naming your product category. “Get a car” is not a job. “Get to work without depending on someone else’s schedule” is. If your job statement contains your category, you have written a feature request.

Then find the real competitive set. Once the job is defined properly, the alternatives usually include things that look nothing like your product — including spreadsheets, doing nothing, and asking a colleague.

The danger: how Jobs to Be Done gets misused

Retrofitting. By far the most common failure in Jobs to Be Done work. A team builds what it wanted to build, then writes a job statement that describes it. Because job statements are easy to phrase in flattering ways, Jobs to Be Done becomes a justification layer rather than a discovery tool. The test is whether a study has ever caused you to cancel something.

Defining the job at the wrong altitude. Too narrow and it is a feature description. Too broad — “be productive”, “be happy” — and it applies to everything, so it guides nothing. A workable job statement is specific enough to exclude most products and general enough to admit surprising ones.

Interviewing the wrong people. Talking to happy current users produces validation, not insight. The information is concentrated in switchers and, more painfully, in people who considered you and chose something else.

Treating anecdote as evidence. Christensen-school work produces compelling narratives, and compelling narratives are persuasive out of proportion to their sample size. Three vivid interviews can redirect a roadmap that thirty would have contradicted.

Ignoring economics. A real, well-articulated Jobs to Be Done statement is not automatically a viable business. People genuinely have the job, and may still be unwilling to pay enough, in sufficient numbers, for it to matter.

The milkshake problem. The framework’s most famous story is so well told that teams import its shape rather than its method — searching for a surprising counter-intuitive insight because the case study had one. Most jobs are mundane. A study that only counts as successful if it produces a delightful anecdote will manufacture one.

Why Jobs to Be Done is worth the effort

The real contribution of Jobs to Be Done is not the interview technique. It is a reframing of the competitive question.

Ask “who are our competitors” and you get a list of companies that resemble you. Ask “what else could someone hire to make this progress” and you get a list of things your customers actually consider — which is a different, longer, and more uncomfortable list, and the only one that predicts where your demand goes when it leaves.