People don't buy products, they hire them to make progress in their lives. A plain-English guide to the Jobs To Be Done framework: the milkshake story, the three dimensions of a job, the four forces that decide every switch, and how to write job stories you can actually build against.
Here is a question that sounds silly until you sit with it: why does anyone buy a milkshake at 7 a.m.?
McDonald's asked exactly that, years ago, when they wanted to sell more milkshakes. They did what most companies do. They profiled the typical milkshake customer, ran focus groups, asked people whether the shake should be thicker, chunkier, cheaper, more chocolatey. They made the improvements people asked for. Sales didn't move.
Then a researcher named Bob Moesta, working with Harvard professor Clayton Christensen, tried a different question. Instead of asking "how can we improve the milkshake," he asked "what job are people hiring this milkshake to do?"
The answer surprised everyone. Nearly half the milkshakes were sold before 8:30 in the morning, to solo commuters facing a long, boring drive. They didn't want dessert. They wanted something to keep one hand busy and their stomach quiet until lunch, something that wouldn't crumble on their lap like a bagel or vanish in two bites like a banana. A thick shake through a thin straw lasts twenty minutes. It was the perfect employee for the job.
Once you see the milkshake's real competition (bananas, bagels, boredom), you know exactly how to improve it. Make it thicker so it lasts longer. Add little chunks of fruit to make the commute more interesting. Move the dispenser to the front so commuters can grab it fast. None of that shows up when you ask people what flavor they prefer.
That is Jobs To Be Done in one story. Now let's unpack the framework properly.
The central claim of Jobs To Be Done (JTBD) is simple: people don't buy products, they hire them to make progress in a specific circumstance.
Every word in that sentence is doing work:
This is why Theodore Levitt's old line has become the unofficial JTBD motto: people don't want a quarter-inch drill, they want a quarter-inch hole. And if you push one level deeper, they don't even want the hole. They want the shelf up, the books off the floor, and the feeling of a tidy home. The drill is just the current hire.
A common mistake is treating the job as purely practical. Real jobs almost always have three layers stacked on top of each other:
The functional layer gets you considered. The emotional and social layers usually decide the winner. Nobody buys a Peloton purely to move their legs, and nobody chooses a Moleskine notebook because it holds ink better than a legal pad.
The bottom half of the infographic is, for my money, the most practical piece of the whole framework. Every switch, from changing banks to changing note-taking apps, is governed by four forces:
Two forces push the switch forward:
Two forces hold it back:
Here is the uncomfortable truth this reveals: most product teams work exclusively on force number two. More features, better design, sharper pricing. All pull. Meanwhile the switch is being lost to forces three and four, which no feature roadmap addresses.
The teams that get this right spend real effort reducing anxiety and breaking habit: free migration tools, generous trials, import-from-competitor buttons, onboarding that produces a win in the first five minutes. When a customer says "I love it, but not right now," that is not a pricing objection. That is anxiety and habit winning, and it needs a different response than a discount.
User stories in agile usually look like this: "As a marketing manager, I want to export reports so that I can share them."
The JTBD community offers a sharper alternative called the job story:
When [I'm in this situation], I want to [make this progress], so I can [get this outcome].
Compare the two for our milkshake:
The job story is longer, but every extra word is a design constraint. One-handed. Slow to consume. No mess. Solo. Morning. The persona ("commuter") gave you none of that; the situation gave you all of it. That is the practical payoff of JTBD: it converts vague customer descriptions into buildable requirements.
You don't find jobs in surveys or dashboards. You find them in switch interviews: conversations with people who recently started or stopped using your product. Recency matters because the memory of the decision is still fresh.
A few questions that consistently produce gold:
Notice that none of these ask about your product's features. You are reconstructing the story of the switch: the push, the pull, the anxieties, the habits. Five to ten of these interviews will teach you more about why people buy than a thousand survey responses, because people are unreliable about predicting their behavior but surprisingly honest about narrating their past.
One more tip: ask what the customer would do if your product vanished tomorrow. If the answer is a spreadsheet, a notebook, or a phone call, congratulations, you have found your real competition. Your competitor set is defined by the job, not by your industry category. The milkshake competed with bananas. Zoom competed with airplane tickets. Netflix, by its own admission, competes with sleep.
A few failure modes show up over and over:
Jobs To Be Done is not really a process or a template. It is a change in the question you ask. Instead of "who is our customer and what do they want," you ask "what progress is this person trying to make, in what situation, and what is getting in their way?"
Ask that question honestly and a few things happen. Your competitor list gets weirder and more accurate. Your roadmap tilts away from feature parity and toward anxiety reduction. Your user research starts producing stories instead of ratings. And every so often, you discover that your product's best customer is a bored commuter at 7 a.m. who just needs one hand free and twenty minutes of something to do.
That insight was sitting in the drive-through line the whole time. Someone just had to ask what the milkshake was being hired for.