Jobs to be Done, without the dogma

Jobs to be Done has a problem that has nothing to do with its central idea: there are competing schools that disagree fundamentally about method, and a team adopting it can lose weeks to arguing about whether a job statement is correctly formed. The formalism is not the value. The reframe is.

The reframe

People don’t buy products because of who they are. They hire them to make progress in a particular circumstance.

The practical consequence is a change in how you describe your user. Compare:

Our users are marketing managers at mid-size B2B companies.

with

Someone has to prove last quarter’s spend worked, before Thursday’s board meeting, using data spread across four tools.

The first sentence tells you nothing about what to build. The second one tells you almost everything: the deadline matters, the aggregation matters, the output is a defence rather than an exploration. You could design from it.

That’s the whole idea. Everything else in JTBD is scaffolding around it, and some of the scaffolding is optional.

What’s worth keeping

The circumstance, not the persona. Personas describe who people are; jobs describe what’s happening to them. The same person has different jobs on different days, and a persona flattens that away.

Competing alternatives, defined honestly. In JTBD terms your competitor is whatever the person currently hires for the job — and it’s usually a spreadsheet, an email to a colleague, or doing nothing. Teams that name their competitors as “the two other companies in our category” are almost always wrong, and it’s an expensive kind of wrong because it aims the roadmap at feature parity instead of at the actual alternative.

The forces around a switch. Push away from the current solution, pull toward the new one, habit holding them in place, and anxiety about the change. Useful because it explains the most common failure in B2B: the new thing is genuinely better and nobody moves, because habit and anxiety together outweigh a modest improvement. That’s a design and onboarding problem, not a marketing one.

Timeline interviews. Asking someone to walk back through what actually happened before they bought — what triggered the search, what they tried first, who else got involved — produces better material than any “what would you like” question.

What’s worth dropping

Job statement syntax. There are templates for this and disagreement about them. Whether you write “when I ___, I want to ___, so I can ___” or something else changes nothing about the product. If your team is peer-reviewing job statements for grammar, the method has become the work.

The claim that JTBD replaces everything. It’s a discovery and framing lens. It doesn’t prioritise, doesn’t size, doesn’t tell you what to build first. Pair it with something that does — the opportunities in an opportunity solution tree are essentially jobs, which is why the two fit together well.

Micro-jobs. Decomposing a job into forty sub-jobs produces a taxonomy nobody uses. Stop at the level where the job would change what you build.

The purity arguments. There are two main schools and they disagree about whether jobs are functional-only or include emotional and social dimensions. In twelve years I have never seen that argument change a product decision. Pick whichever you find useful and move on.

Using it in a week

1. Ten timeline interviews with recent customers. Not “what do you want” — “walk me through the week before you signed up.” Record them.
2. Write the circumstance for each, one sentence, in the customer’s own words rather than yours.
3. Cluster them. You’ll get three or four recurring circumstances. Those are your jobs.
4. Name the real alternative for each. What did they actually do before?
5. Check your roadmap against the list. Anything that doesn’t serve one of the circumstances is either a bet on a job you haven’t validated or it shouldn’t be there.

Step 5 is where the value lands, and it’s usually uncomfortable. That discomfort is the method working — and holding your nerve through it, in front of stakeholders who liked the old roadmap, is a skill separate from the method itself. It’s one of the more common things to work through in coaching.

The most common mistake

Doing the interviews and then building what people asked for during them. JTBD interviews are for understanding the circumstance, not for collecting requests. Someone describing their Thursday board meeting is giving you a problem to solve; if they also say “you should add a PDF export,” that’s a solution guess from a person with less context about your product than you have.

Take the circumstance. Treat the requests as data about the circumstance, not as a backlog. And when you’ve got a candidate solution, test it cheaply — a fake door beats another round of interviews for finding out whether anyone actually wants the thing.