The milkshake story is the most quoted anecdote in product development and the least useful one. It taught an entire industry to invent a nice narrative after the purchase and call that research.
A quick reminder: McDonald's wanted to sell more milkshakes, asked customers what they wanted, got thicker shakes and more flavours, and sold nothing. Then somebody looked at when people bought. Mornings, alone, in the car. The job was not "dessert", it was "survive the commute". Great story. And that is usually where the thinking stops.
Any job fits, once you pick it afterwards
The problem with the milkshake explanation is not that it is wrong. The problem is that it cannot be wrong. For every observed behaviour there is a job that fits it perfectly. Somebody buys a shake in the morning, so the job was "make the drive bearable". They buy one in the afternoon with their kid, so the job was "be a good parent". Both sentences sound smart. Neither would have told you beforehand what to build.
It is the same trap I already ran the numbers on for economic forecasts: explaining is easy, predicting is hard. An explanation costs nothing, because it only appears once the outcome is settled. A prediction commits first and can fail. In almost every workshop, Jobs to Be Done gets used as an explanation machine. It is only worth anything as the opposite.
A job you formulate after the purchase is a narrative. A job that forbids you to build something is a hypothesis. Only the second one is work.
The only test that counts: what does your job statement forbid?
Take your last job statement and write down the three things it forbids your team to do. If nothing comes to mind, you do not have a job statement. You have a tagline with a framework sticker on it.
| Job statement | What it forbids |
|---|---|
| "Our customers want to save time." | Nothing. Every feature ever conceived is compatible with it. |
| "Our customers want better reports." | Almost nothing. That is a solution, not a job. |
| "When the month-end close comes around, I want to pull numbers from five sources without anyone having to double-check them." | Every feature with a manual review step. Every import that creates hand work. Every number without a traceable origin. |
The third one is useful because it has enemies. It rules out roadmap items nobody else dares to cut. That is exactly what the framework is for.
I leave the standard format almost untouched and add a fourth clause that most people drop:
When [SITUATION], I want [PROGRESS], so that [OUTCOME], and I give up [PRICE] for it.
The fourth clause is the honest one. It forces you to name the sacrifice: money, habit, status, a tool, the comfort of doing nothing. A job that costs nothing was never done.
Hiring means firing
The metaphor says customers hire products. The half that always gets lost is the dismissal. Every purchase is also a firing. Something goes out. A tool, a spreadsheet, an agency, an afternoon coffee, an excuse.
And that is the only hard data point in the entire framework. The job is an interpretation. The firing is an event. It has a date, a trigger and a price.
Which is why the most important question in a customer conversation is not "why did you buy", but: what did you throw out for this?
If the answer is "nothing", you did not win a customer. You got added. Those users look identical to real switchers in your dashboard and behave nothing like them: they leave at the first price increase, painlessly, because they never gave up anything they would have to get back.
The four forces, and why your budget sits on the wrong one
Anyone who switches is pushed and held by four forces. Two drive them toward the switch: the pain with the old solution (push) and the draw of the new one (pull). Two hold them in place: the anxiety about what could go wrong and the habit that works today.
The switch only happens when push and pull together outweigh anxiety and habit. Pull on it yourself:
The four forces your customer’s decision actually hangs on
Pull the sliders. The switch only happens once Push and Pull together outweigh Anxiety and Habit.
Rises when the old solution gets pricier, breaks, or embarrasses someone.
Rises with features, demo, design, price. Almost your entire budget sits here.
Falls with data import, a trial, a money-back promise, references.
Falls with migration, training, familiar workflows, running both in parallel.
STATUS QUO
6 points short. The customer stays put. In your pipeline that reads as “later”, never as “no”.
Every slider moves the same number. But Pull costs you a release, and Anxiety costs you an import button. That is why the better product loses to the installed one so often.
The uncomfortable insight is in the symmetry. Each of the four sliders moves the result by exactly the same amount. But one point of pull costs you a quarter of engineering, and one point less anxiety costs you a data import, a trial period or a money-back promise.
Almost every product team I see works on pull alone. More features, prettier interface, longer demo. The blocking mass sits on the right, in anxiety and habit, and it is orders of magnitude cheaper to move. That is precisely why the better product keeps losing to the installed one.
The switch interview: the only data source that cost somebody something
Wishes are free, which is why questions about wishes are worthless. A switch cost somebody money, time and nerves. That is the only thing worth talking about.
The rules are short and strict:
- Only talk to people who actually switched. Ideally within the last 90 days, after that people reinvent their reasons.
- Reconstruct a timeline, not an opinion. Weekdays, rooms, triggers, people in the room.
- Never ask "why". People answer "why" with whatever sounds reasonable. Ask "what happened".
- The most valuable moment is not the purchase, it is the first thought. That is where your marketing either stands or does not.
| Instead of | Ask |
|---|---|
| "What would you like?" | "When did you first think this could not go on?" |
| "Why did you buy?" | "What happened on the day you placed the order?" |
| "What matters to you?" | "What did you throw out for this?" |
| "Would you use this?" | "What did you last pay for something like this?" |
| "Did anything bother you?" | "What could still have stopped you at the last moment?" |
Ten to fifteen of these conversations per segment is enough. Not because the number proves anything statistically, but because the timelines start repeating around there. If they do not repeat, you do not have a segment. You have a pile of individual cases.
Your competition is written on the dismissal notices
Netflix supplied the famous line that its biggest competitor is sleep. The quote gets passed around as wisdom and mostly misunderstood as a brainstorming exercise: everyone sits down and imagines a broader market.
That is not how it works. The honest competitive set can be read off, not invented. It is whatever your customers fired when they switched.
If forty percent of your new customers dismissed a spreadsheet, then spreadsheets are your market. Not the vendor with the nicer website that you keep building feature comparison tables against. That changes the roadmap immediately: you do not beat a spreadsheet with more functions, you beat it with import, familiarity and permission to go back if it fails.
The opportunity formula, read honestly
For prioritisation, Anthony Ulwick's formula is usable:
OPPORTUNITY = IMPORTANCE + (IMPORTANCE - SATISFACTION)
Example: "communicate project status to the team" Importance 9 out of 10 Satisfaction 4 out of 10 Opportunity 9 + (9 - 4) = 14
A high score means important and badly solved. That is a decent starting point for your next bet.
And here is the part missing from the conference talks: both numbers are self-reported. People rate importance high when they want to feel professional, and satisfaction low when they hope somebody will fix their problem. The formula sorts opinions. It proves nothing. Use it to decide what you test next, never to claim you knew it all along.
Four mistakes I keep seeing
The solution posing as the job. "The job is: check email" describes a tool. The job is "not miss anything important". Test question: what would be lost if this solution disappeared tomorrow? Whatever is lost is the job.
The job that forbids nothing. If your statement survives every roadmap, it is decoration. Delete it and write one that hurts.
Context in the bin. "Customers want fast delivery" is nothing. "When customers need a gift for tonight, they want same-day delivery so they do not show up empty-handed" is an instruction to logistics, pricing and copy.
Only the functional half. The functional job explains that they bought. The emotional job explains at what price. A business suit covers the body. It is paid for because nobody in the room questions you. Collect only the functional half and you will spend the rest of the year confused about your margins.
Conclusion
Jobs to Be Done is not an explanation machine. As an explanation machine it is a generator of sentences that are always true and never forbid anything.
Take three things away. First: a job statement becomes a hypothesis only when it forbids you something. Second: nothing gets hired where nothing got fired, so ask about the dismissal instead of the wish. Third: the forces blocking the switch are cheaper to move than the ones attracting it, and your entire budget is still sitting on pull.
So the question for your next meeting is not "what job do we do". It is: who did our customers fire for us, and what does the dismissal notice say?
Want to know how to translate the emotional half of the job into money? The guide to pricing psychology for SaaS shows how to price along perceived value instead of your own costs.