Key takeaways
  • Customers don't buy products; they hire them to do a job (Christensen).
  • The four forces of switching explain what drives adoption and inertia.
  • JTBD beats personas for framing competition, but can over-claim, so use it where it fits.

The Jobs to be Done framework, as Clayton Christensen tells it in his 2016 Harvard Business Review piece, starts with a fast-food chain trying to sell more milkshakes. The marketing team had already segmented the customer base by age, income, family status, and personality type. They'd asked thousands of customers what would make the milkshake better (thicker, fruitier, chunkier) and improved the product against the feedback. Nothing moved. The lever was missing because the question was missing.

Then a researcher spent a day in the restaurant watching who actually bought milkshakes, when, and what happened next. The surprise was the morning. Forty percent of milkshakes were sold before eight a.m. — to solo commuters, who drove off the lot with the shake in the cup holder. None of them ordered fries, none of them ordered anything else. Interviews followed. The job, it turned out, wasn't feed me a treat. The job was make my forty-minute commute less boring, fill me up so I don't get hungry at ten, and keep my hands clean while I'm driving. The competition wasn't the McDonald's milkshake. It was a bagel (crumbly, two hands), a banana (gone in three bites), a coffee (no calories), or skipping breakfast altogether. That is Jobs to be Done.

The framework, simply.

Christensen's claim is structural. People don't buy products. They hire products to make progress in a specific situation. The product is the means; the progress is the end. If you understand the job in enough detail, you understand who you're really competing with, what features actually matter, and why someone switches.

The job statement template that's settled into the canon is straightforward: when [situation], I want to [motivation] so that I can [expected outcome]. The milkshake job becomes: when I'm commuting alone in the morning and dreading a forty-minute drive, I want to keep my hands and mind occupied with something filling so that I can arrive at work not hungry and not bored. Compare that to a persona ("married 35-year-old commuter, 60k household income, two kids"). The persona tells you who they are. The job tells you what they're doing and why, which is what predicts what they'll buy.

The four forces of switching.

The most usable extension of JTBD comes from Bob Moesta, who co-developed the framework with Christensen and has spent twenty years interviewing customers about moments of switching. His Forces of Progress model says that every switch, from old product to new, is governed by four forces: two pushing toward the new product and two pulling back.

Diagram · The Four Forces of Progress · Bob Moesta
The Four Forces of Progress that govern every customer switching decision A two-by-two diagram of the four forces that govern a customer's decision to switch from an old product to a new one. The top row contains the two forces pushing toward the switch — Push of the current situation on the top left in marigold, with an arrow pointing right toward the centre, and Pull of the new product on the top right in marigold, with an arrow pointing left toward the centre. The bottom row contains the two forces pulling back — Anxiety of the new on the bottom left in ink, with an arrow pointing left away from the centre, and Habit of the old on the bottom right in ink, with an arrow pointing right away from the centre. In the centre sits the equation Push plus Pull greater than Anxiety plus Habit equals Switch. The customer switches only when the forces toward the new outweigh the forces holding them in the old. The framework reframes product strategy from selling more features to reducing anxiety and overcoming habit. FORCE 01 · PUSHES TOWARD NEW Push of the current situation Old product is failing. Pain has built up. FORCE 02 · PUSHES TOWARD NEW Pull of the new product New solution looks better. Imagined progress is real. FORCE 03 · PULLS BACK Anxiety of the new Will it work? Will I look stupid for choosing it? FORCE 04 · PULLS BACK Habit of the old Switching is effort. Today already works. Push + Pull > Anxiety + Habit → SWITCH Most product teams optimise Pull. The forces holding people in the old product are usually larger.
Push and Pull get the user looking. Anxiety and Habit keep them where they are. The switch only happens when the forward forces beat the backward ones, which is rarely about adding features and almost always about removing fear and friction.

Push of the current situation. What's failing about today? The pain that's built up against the existing solution. Without push, the customer isn't actually shopping. They're just looking. Push is the energy that makes them ready to switch.

Pull of the new product. What does the new solution promise? The imagined progress. This is where most marketing teams concentrate — features, benefits, the better future. Pull matters, but it's only half the equation.

Anxiety of the new. Will it work? Will it integrate? Will I look stupid for choosing it if it fails? Anxiety is the soft block — it's the reason most demos go great and most deals stall. Most teams under-invest here because anxiety isn't logical and isn't on the feature list.

Habit of the old. Switching is effort. The current setup already works, partly. Migrating data is annoying. Retraining people is annoying. The old product, however flawed, is the path of least resistance. Habit kills more switches than features ever convert.

The implication for product strategy is significant. Most teams compete on Pull, building a better version of the same feature set. The Jobs frame reveals that the competitive lever is often Anxiety reduction (proof, guarantees, trial paths, integration tooling) or Habit subversion (migration tools, behavioural triggers, switching incentives). The product that wins isn't always the best one. It's the one that moves the equation.

People don't buy products. They hire them to make progress in their life. Sometimes they hire a milkshake to make the commute bearable.

Switch interviews — the actual research.

Where JTBD gets methodological is in the switch interview. Find a customer who recently changed from one product to yours (or anywhere else). Walk them backward through the timeline. When did they first realise the old solution wasn't working? What were they thinking? What did they try first? What made them shortlist? What nearly stopped them buying? What did they have to do internally to make the switch happen?

Done well, switch interviews surface the four forces in the user's own words. They're harder than they look. Most people rationalise after the fact, claim they bought because of features, and skip over the anxiety. A good interviewer keeps anchoring back to what were you actually thinking, at the moment you decided. Twenty interviews of that quality, run across recent switchers and recent non-switchers, will tell you more about your market than a year of feature feedback.

Where JTBD beats personas.

Personas describe people. Jobs describe situations. The same person hires different products for different jobs across their day. A senior engineer hires Slack for quick coordination, Notion for thinking out loud, and email for paper-trail compliance. The persona is constant, the job switches by context. Persona-led product work assumes the persona drives the decision. JTBD-led product work assumes the situation drives the decision. In practice, situations are far more predictive of behaviour than demographics.

That doesn't make personas useless. They're useful as a communication shorthand and for design empathy. But if you're making prioritisation calls about which problem to solve next, JTBD is the sharper lens. The question isn't "what does the persona need?" It's "what job, in what situation, is currently going badly enough that someone would switch?"

Where JTBD over-claims.

JTBD is a lens, not a methodology. The community sometimes oversells it as the complete operating system for product, which it isn't. It doesn't tell you how to build, how to scope, how to size, or how to run a team. It tells you how to frame demand. Pair it with a delivery method (Lean, dual-track agile, whatever fits) and a pricing model and a roadmap discipline. JTBD is one piece of the picture, not the whole one.

It's also weaker for new-to-the-world categories where customers can't articulate the job yet because they've never had a product like yours. JTBD reveals switching from an existing alternative; it's less useful when the alternative is "do nothing" or "didn't realise this was possible". For genuine zero-to-one work, you need first-principles problem-discovery alongside JTBD, not instead of it.

How we use this at Product Pieces.

When a product team is stuck on prioritisation (three roadmap items, all of them defensible, no clear signal), we run a JTBD pass on the recent quarter's wins and losses. Switch interviews with five recent customers who chose us. Switch interviews with three recent prospects who chose someone else. The pattern that emerges almost always changes the roadmap. Sometimes the right next bet isn't a new feature; it's an anxiety-reduction asset (a guarantee, a migration tool, a sandbox) or a habit-breaker (a trial path that gets the user past the cost of switching). The Jobs frame tells you which lever is actually short.

If your roadmap is full of features and your sales cycle is lengthening, the issue is rarely product fit. It's almost always anxiety. Name the four forces, weight them honestly, and the next bet usually picks itself.

Next issue: N°30 — OKRs. The discipline of saying no.