Jobs to be done: why your users say "very disappointed" (or don't)

Your users don't buy your product. They hire it.

That's the whole idea behind Jobs to Be Done, and once you see it, you can't unsee it in your own PMF data. It explains why two users with identical usage stats can give completely different answers to "how would you feel if you could no longer use this?", one very disappointed, one not disappointed at all.

The milkshake that features couldn't fix

Clayton Christensen's most famous illustration of Jobs to Be Done involves, of all things, a milkshake. A fast-food chain wanted to sell more of them. The team did what most product teams do: they tweaked the product. Thicker. Cheaper. More chocolatey. More flavor options. Sales barely moved.

So they tried something different. Instead of asking "what feature should we change," they watched who actually bought milkshakes, and when. The pattern that emerged had nothing to do with taste. A huge share of milkshakes were bought alone, in the morning, by commuters about to face a long, boring drive. They weren't buying dessert. They were hiring something that was easy to drink one-handed, would last the whole commute, and would keep them full until lunch.

Once the team understood the real job, the obvious competitors weren't other milkshakes. They were bananas, bagels, and boredom. That reframing is what JTBD gives you: not a better feature list, but the actual reason someone reaches for your product instead of doing something else, including nothing.

How this explains your PMF score

Here's where it connects directly to the number PMFtracker measures. The Sean Ellis survey asks how a user would feel if they could no longer use your product. That answer isn't really about your feature set. It's a proxy for one question: does this product do a job well enough that losing it creates a real gap in that person's day?

• Very disappointed means you're doing a real job, and doing it well enough that the person has no good substitute.
• Somewhat disappointed usually means you're doing a real job, but not distinctly better than an alternative, including a manual workaround.
• Not disappointed often means there was never a painful job in the first place, only a feature that seemed useful in a demo.

This is why two users with similar usage numbers can land in different buckets. Usage tells you what someone did. The job tells you why, and only the "why" predicts whether they'd fight to keep you.

How to surface the job directly from your survey

You don't need a separate research project to apply this. The standard PMF survey already asks the questions that surface it, if you read the answers through a JTBD lens instead of a feature-request lens:

• "What type of person would most benefit?" Read the pattern across answers, not each answer alone. When strangers describe the same situation in their own words, that situation is the job.
• "What is the main benefit you get?" This is usually the most direct statement of the job you'll get, in the user's own language, not yours.
• "How can we improve it for you?" Read these as clues to where the job is being done imperfectly, not as a feature backlog.

The full mechanics of that question set are in the exact PMF survey questions to ask. The shift here is entirely in how you read the answers: look for the job repeating across strangers, not the feature repeating across requests.

Why this matters more than it sounds like it should

Teams that skip this usually end up optimizing the wrong thing. They see a mediocre PMF score, assume it's a feature gap, and ship more features. Sometimes the score barely moves, because the product was never mismatched on features. It was mismatched on the job. You can't feature your way out of solving the wrong job, the same way a thicker milkshake never fixed a boring commute.

This is also the mechanism behind a strong ICP. Your best-fit customers aren't the ones who match a demographic. They're the ones with the job you solve, badly needing it solved, with no better option. Find the job first, and the ICP tends to fall out of it, not the other way around.