Jobs to Be Done has a reputation problem caused mostly by its advocates. Underneath the milkshake anecdotes and the schisms between camps, there is one idea that reliably improves product decisions, and a lot of apparatus around it that does not.
The idea: people do not buy products, they hire them to make progress.
Why that framing pays
It changes who you think your competition is. Ask what a project management tool competes with and you get a list of other project management tools. Ask what people hire it to do — "know whether we will hit the date without asking five people" — and the real competition appears: a spreadsheet, a recurring meeting, and doing nothing.
Most products lose to a spreadsheet or to inertia, not to the competitor whose pricing page you have open in another tab.
The strongest competitor for almost every new product is the customer continuing to do exactly what they do now.
Writing a job statement
The structure that works, and stays useful months later:
When [situation], I want to [motivation], so I can [expected outcome].
A weak one:
When I am working, I want to be more productive, so I can get more done.
A useful one:
When I am asked in a Monday review whether we will hit the release date, I want to answer with something defensible in under a minute, so I do not have to promise to follow up and then chase four people.
The second is specific about the situation, honest about the emotional stake, and testable. You can look at your product and say plainly whether it does that. The first could describe any product ever made.
Most weak job statements are weak because the "when" is generic. Situations have triggers — a meeting, a deadline, a complaint, a month end. If you cannot name when the job arises, you probably have not talked to enough people about specific incidents.
The four forces
The most practically useful piece of JTBD apparatus. Any switch is governed by four pressures, two pushing toward change and two holding it back:
| Force | What it is | Where it shows up |
|---|---|---|
| Push | The current situation is painful | Complaints, workarounds, escalations |
| Pull | The new thing looks better | Marketing, demos, peer recommendation |
| Anxiety | Fear about the new thing | Migration risk, learning cost, "what if it breaks" |
| Habit | Comfort with the current thing | Existing process, sunk investment, muscle memory |
Product teams over-invest in pull almost universally. More features, better demos, louder marketing. But when adoption stalls, the binding constraint is usually anxiety or habit — and neither is solved by making your product more impressive.
Anxiety is answered with migration tooling, trials, guarantees and proof. Habit is answered by fitting into the existing workflow rather than demanding a new one. Both are unglamorous, and both move the number more than the next feature will.
The switch interview
Find people who recently changed something — signed up, churned, or moved off a spreadsheet — and reconstruct the timeline backwards from the moment they decided.
- When did you first realise the old way was not working?
- What happened that week specifically?
- What did you look at first? What made you rule it out?
- Who else had to agree?
- What nearly stopped you signing up?
That last question is the one worth the whole interview. It names the anxiety directly, and anxieties are usually cheap to fix once you know they exist.
Two warning signs. First, arguments about whether something is a "real" job — the camps disagree with each other, so this is unresolvable and produces nothing. Second, teams rewriting an existing backlog into job statements after the fact. If the output is the same backlog with different sentences on top, the framework was decoration, not a lens.
When to skip it
JTBD is strongest for positioning, market entry, and understanding why adoption is stalling. It is weak for incremental improvement of a product people already use happily — knowing the job does not tell you whether the button should be at the top or the bottom.
Use it when the question is "why aren't they switching" or "who is this actually for". Use ordinary behavioural interviews for everything else, and let the opportunity tree hold what you learn.