Kasra VaziriJobs to Be Done: The Product Framework in Plain English
Jobs to be done, minus the jargon: the milkshake story, a modern example, switch interviews, the four forces of progress, and how teams misuse it.
A restaurant chain once tried to sell more milkshakes the obvious way: better flavors, thicker texture, a fancier menu board. Nothing moved. Then a team that included Clayton Christensen asked a different question — not "how do we improve the milkshake" but "what job are people hiring this milkshake to do?" That reframe is the entire jobs to be done framework in one anecdote, and it remains the most useful lens I know for figuring out what to actually build.
The punchline of the milkshake story is that a surprising number were sold before 8 a.m., to solo commuters who weren't even hungry. They had a long, boring drive ahead, one free hand, and a need to stave off mid-morning hunger without making a mess. A bagel crumbled. A banana vanished in two minutes. A milkshake was thick enough to last the whole commute and survived a one-handed grip. The customer wasn't buying a beverage. They were hiring something to make a dull drive tolerable. As Christensen put it in his Harvard Business Review essay, "Customers don't simply buy products or services; they pull them into their lives to make progress."
What jobs to be done actually means
Strip away the jargon and jobs to be done says one thing: people don't want your product, they want the progress it makes possible. A job is the progress someone is trying to make in a particular circumstance — functional, emotional, and social all at once. The milkshake's functional job was "keep me full and occupied"; the emotional job was "let me feel a little less bored"; the social job was "don't make me look like a slob at my desk."
The framing has two parents who rarely get mentioned together. Tony Ulwick conceived the structured version in 1990, applying Six Sigma thinking to innovation and building it into Outcome-Driven Innovation, which Strategyn reports carries an 86% success rate against an industry average closer to 17%. Christensen later popularized the storytelling version that most of us first encountered. Ulwick gives you rigor and measurable "desired outcomes"; Christensen gives you the narrative instinct. You want both.
The most practical consequence of thinking in jobs is that it redraws your competition. If commuters hire a milkshake to survive a drive, the real rivals aren't Wendy's and McDonald's — they're bananas, coffee, podcasts, and the radio. Your competitor is whatever the customer fired to hire you. Miss that, and you'll benchmark against the wrong companies and optimize the wrong things.
A modern example: why people "hire" Notion
The milkshake is forty years old, so here's a contemporary one. Watch how teams actually adopt a tool like Notion and you'll see it rarely wins on a feature checklist. It gets hired for a job that sounds like: "When my team's knowledge is scattered across Slack threads, Google Docs, and someone's memory, I want one place we all trust, so I can stop being the human search engine." The thing being fired isn't a competitor app — it's the chaos of five disconnected tools and the anxiety of not knowing where the truth lives.
Notice what's absent from that job statement: no demographics, no persona, no feature request. Just a situation, a motivation, and a desired outcome. That's the shape of a real job, and it's why two very different companies can hire the same product for the same reason.
How to actually use the framework
Most teams nod along to jobs to be done and then never change what they do on Monday. Here are the two tools that make it operational.
The switch interview. Pioneered by Bob Moesta and Chris Spiek of the Re-Wired Group, the switch interview is a structured conversation with people who recently bought your product, reconstructing the timeline of their decision in forensic detail. You're not asking what features they want. You're rewinding the tape: When did you first realize the old way wasn't working? What did you do next? What almost stopped you from switching? The goal is to map the journey from first thought through passive looking, active looking, and finally the purchase — and to find the struggling moment that set the whole thing in motion.
The four forces of progress. Every switch is a tug-of-war. Two forces push someone toward change — the push of frustration with the current situation, and the pull of the new solution's promise. Two forces hold them back — the anxiety of the unknown, and the habit of what they already do. People only switch when push plus pull beats anxiety plus habit. This is the most underrated insight in the whole framework: you can win by reducing anxiety and breaking habits, not just by piling on more pull. A free trial, a migration tool, a money-back guarantee — those are anxiety-killers, and they often move the needle more than another feature.
If you want the lightweight version for everyday feature work, Intercom's job stories are the cleanest format I've found: When [situation], I want to [motivation], so I can [expected outcome]. Unlike a persona-driven user story, a job story forces you to name the circumstance and the anxiety, which is exactly where causality lives.
The common ways teams get it wrong
Jobs to be done is simple to say and easy to mangle. The failure modes are predictable.
Confusing a job with a feature. "The job is dark mode" — no, that's a solution. The job is "let me work at night without burning my eyes." Features are how you serve a job; they are never the job itself.
Writing the job at the wrong altitude. "I want to be happy" is too abstract to act on. "I want a milkshake" is too narrow — it bakes in the solution. The useful altitude sits in between, where the situation is specific but the answer is still open.
Treating jobs as static. The job is stable, but the best way to do it changes constantly. People have always wanted to make a boring commute bearable; the milkshake, the podcast, and the audiobook are just successive answers. (And yes, the latest answers increasingly involve AI — but that's a how, never the job.)
Inventing jobs at your desk. The biggest one. Jobs to be done is a research practice, not a brainstorming exercise. If you haven't talked to people who recently switched, you're not doing JTBD — you're writing fiction with better vocabulary. This is also why most of what teams ship goes unused: features built for imagined jobs rarely match real ones.
The takeaway
Jobs to be done isn't a template to fill in — it's a habit of asking, relentlessly, what progress your customer is trying to make and what they had to fire to hire you. Get the job right and the roadmap gets quieter, the competition comes into focus, and the features you build start earning their keep. Get it wrong and you'll keep shipping thicker milkshakes to people who only wanted to survive the drive.
Sources
Clayton Christensen, "Know Your Customers' Jobs to Be Done" — Harvard Business Review — the milkshake story and the "hire/fire" definition of a job
Tony Ulwick / Strategyn, "Jobs to Be Done" — origins of JTBD, Outcome-Driven Innovation, and the 86% success-rate figure
Jobs-to-be-Done.org (Bob Moesta / Re-Wired Group) — the switch interview and the four forces of progress
Intercom, "Designing Features Using Job Stories" — the job-story format and why it beats persona-based user stories