McDonald's wanted to sell more milkshakes, so it did the obvious thing: asked milkshake buyers how to make the milkshake better, thicker, sweeter, chunkier, and changed the product accordingly. Sales didn't move. Then a research team led by a Harvard professor watched when people actually bought them, and found nearly half of all milkshakes went out the door before 8:30 a.m., to solo commuters who drank them in the car. The milkshake wasn't competing with other milkshakes. It was competing with bagels, bananas and boredom on a long drive. That reframing is the whole point of jobs-to-be-done.

The quick version

  • A "job" is the progress a customer is trying to make in a particular situation, not a product feature and not a demographic.
  • Customers "hire" a product to do that job and "fire" it when something does the job better; your real competitors are anything else they could hire, including doing nothing.
  • You find the job by studying the moment of struggle and the switch, why someone moved from an old solution to a new one, usually through interviews, not surveys.
  • It's a powerful lens, but it's qualitative and easy to fool yourself with; treat a "job" as a hypothesis to test, not a fact you discovered.

The idea in depth

The clearest modern statement of jobs-to-be-done comes from Clayton Christensen and his co-authors Taddy Hall, Karen Dillon and David Duncan, in the 2016 Harvard Business Review article "Know Your Customers' Jobs to Be Done" and the book it accompanied, Competing Against Luck (Harper Business, 2016). Their definition is deliberately tight: a job is "the progress that a person is trying to make in a particular circumstance." Not a task in the abstract, progress, in context, with social and emotional dimensions, not just functional ones. The milkshake's functional job was "keep me occupied and not-hungry on a dull commute"; the morning commuter also had an emotional one ("make the drive a small treat"). Miss either and you optimise the wrong thing.

The line worth memorising is the reframe itself: customers don't buy products, they hire them. The verb does the work. It forces you to ask what the product is being hired instead of, which is where most market definitions are quietly wrong. So the move is: before your next product or roadmap argument, write the job as a sentence in the customer's words, "when ___, I want to ___, so I can ___", and then list every alternative they could hire for that same job, including a spreadsheet, a competitor, and doing nothing. That list is your real competitive set, and it's almost never the one on your slide.

"Customers don't simply buy products or services; they pull them into their lives to make progress.", Christensen, Hall, Dillon & Duncan, HBR, 2016

The intellectual lineage is older than the milkshake. Theodore Levitt, the Harvard marketing professor, made the same point sixty years earlier in "Marketing Myopia" (HBR, 1960), and is widely quoted teaching it with a sharper image: people don't want a quarter-inch drill, they want a quarter-inch hole. (The line is usually attributed to Levitt as a classroom saying rather than a sentence in the paper itself, fair to credit him, fair not to put it in quotation marks as published text.) The job, the hole, is stable; the products that get hired for it churn. Whoever stays focused on the hole keeps reinventing the drill before someone else does.

Two schools: the story version and the spreadsheet version

It helps to know that "jobs-to-be-done" names two related but genuinely different methods, because people argue past each other about it constantly.

The first is the Christensen / switch-interview school, qualitative, narrative, focused on the moment someone changed what they hired and why. Its tool is the in-depth interview that reconstructs the "switch": the first thought, the trigger, the anxieties, the forces pushing toward the new option and the habits pulling back to the old one. The second is Tony Ulwick's Outcome-Driven Innovation (developed at his firm Strategyn from the early 1990s, and the strand Christensen credited as an influence). Ulwick breaks a job into a long list of measurable "desired outcomes", typically phrased as "minimise the time it takes to…" or "reduce the likelihood that…", and then surveys customers at scale to score each outcome on importance and current satisfaction. The gap between the two reveals underserved outcomes worth innovating against. One school gives you a story; the other gives you a quantified opportunity map. (See Ulwick's overview of the ODI framework.)

flowchart TD
  J("A job: the progress a customer wants, in a situation") --> A("Christensen school: switch interviews, the story of why they changed")
  J --> B("Ulwick / ODI: desired outcomes scored on importance vs satisfaction")
  A --> C(["Insight: the forces and anxieties around the switch"])
  B --> D(["Insight: underserved outcomes ranked by opportunity"])
  C --> E(["Where to focus the product"])
  D --> E
Two roads from the same idea: a qualitative switch story and a quantified outcome map both point at where to build. Leaders Loop

Pick the school that fits the decision in front of you. Early and exploratory, with no idea why people choose what they choose? Run a dozen switch interviews, the story is the deliverable. Refining a product in a known market and need to prioritise a backlog? An outcome survey gives you defensible numbers a leadership team can rank. Reaching for one when you needed the other is the most common way the method disappoints.

The honest limitation. Jobs-to-be-Done is mostly a qualitative craft, and that's its soft spot. There's no agreed definition of how big a "job" is, "feed my family," "make a quick weeknight dinner," and "reheat last night's pasta" are all jobs at different altitudes, and the framework won't tell you which altitude is right. Interviews are vulnerable to a confident researcher hearing the story they came to hear. And the celebrated cases, the milkshake above all, are told in hindsight about products that already succeeded, which makes them persuasive teaching tools and weak evidence that the method predicts winners. Use it to generate sharp hypotheses about demand; then test them with a real offer in market, because a well-told job story can be completely wrong and still sound true.

A worked example

Take a regional gym chain, a composite, the figures below are illustrative, worried about January joiners who vanish by March. The instinct is to compete on gym things: more equipment, longer hours, a slicker app, a lower price. Every rival is doing exactly that, so it's a race to the bottom.

Run a handful of switch interviews with people who joined and quit, and with the rarer ones who stayed. The job that surfaces isn't "get access to fitness equipment." For the quitters it was closer to "when a milestone makes me feel I've let myself go, I want to feel I'm finally taking control, so I can stop dreading the mirror." They didn't hire a gym; they hired a fresh start. The thing they actually fired it for wasn't a missing feature, it was the second week, when the fresh-start feeling faded and nothing replaced it. The "do nothing" competitor (the sofa) won by default.

Now the moves write themselves, and none of them is a treadmill. Reduce the anxiety of the switch: a guided first-three-weeks plan and a check-in from a real person, because the forces that kill the job live in week two. Make progress visible: small, early, non-scale wins so the "taking control" feeling outlasts the initial burst of motivation. Re-cast the competitive set: the rival isn't the gym down the road, it's the quiet decision to give up, so the retention budget goes to the fortnight when that decision gets made. The illustrative result is a chain that competes on a job nobody else is serving, using assets it already owns.

flowchart LR
  T("Trigger: a milestone, 'I've let myself go'") --> Push("Push: dread, wanting control")
  Push --> Hire("Hires a gym = hires a fresh start")
  Hire --> Week2("Week two: the feeling fades")
  Week2 --> Anx("Anxiety + habit pull back")
  Anx --> Fire(["Fires the gym, hires the sofa"])
  Hire -.guided start, visible wins.-> Stay(["Stays: progress feels real"])
Illustrative: the job is hired at the trigger and fired in week two, so the intervention belongs there, not in the equipment. Leaders Loop

Frequently asked questions

Isn't this just a fancy word for "customer needs"?

It overlaps with needs identification, but the difference is real. A need is often stated as an attribute ("I need it cheaper / faster / easier"). A job is the progress in a situation, with the competing alternatives and the emotional stakes attached. The job framing is what surfaces a non-obvious competitor, the bagel, the sofa, the spreadsheet, that an attribute list usually misses.

How many interviews do I need?

For the switch-interview school, surprisingly few: practitioners often find the same forces recurring after roughly eight to a dozen well-chosen conversations, especially if you interview recent switchers while the memory is fresh. The aim is depth and pattern, not a statistically representative sample. If you need numbers a board will trust, that's the signal to use Ulwick-style outcome surveys instead, which are built for scale.

Does jobs-to-be-done replace segmentation?

No, it reframes it. Traditional segmentation groups people by who they are (age, income, industry). Jobs-based segmentation groups by what they're trying to get done, which can cut across demographics entirely: a busy parent and a busy executive may hire the same product for the same job. Most teams end up using both, demographics to reach people, jobs to decide what to build for them.

Can a product be hired for more than one job?

Yes, and it's a common trap. The milkshake had a second job, an afternoon treat for a parent stalling at the drive-through with a child, with completely different requirements (smaller, faster, less filling). Optimising blindly for one job can break the other. The discipline is to name the jobs separately, size them, and decide which one the product is primarily hired for before you start changing it.

Where does it most often go wrong?

Two places. First, "job inflation", writing the job so grandly ("help people live their best life") that it guides no decision at all. Keep it concrete enough to point at a specific moment. Second, treating the interview output as proof rather than hypothesis. The story you hear is a starting bet; validate it with a real offer before you reorganise the roadmap around it.

Related in the Toolkit

Jobs-to-be-Done is the connective tissue of customer insight: it sharpens needs identification by reframing a need as progress-in-context, and it gives personas something more durable than demographics to organise around.

Where to go next