Jobs to be done has a reputation for being a bit abstract. Workshops full of sticky notes, debates about whether something is a job or an outcome, and a lot of quoting the milkshake story.
Underneath, the idea is simple and useful. People don't buy products for the features. They "hire" them to make progress in a particular situation. If you understand the situation and the progress they want, you understand what you're really competing with.
Clayton Christensen and colleagues explained this in their Harvard Business Review article on knowing your customers' jobs to be done. 1 What follows is how I'd actually apply it.
Write the job as a situation
A job statement I find useful has three parts: the situation, what the person wants, and why.
"When I [situation], I want to [motivation], so I can [expected outcome]."
For a travel streaming service, one job might be:
"When I'm planning a trip somewhere new, I want to get a feel for the place, so I can decide what's worth seeing."
That's very different from "I want to watch travel shows." It tells you something about timing, motivation and what a good result looks like.
The same product can be hired for different jobs
| Job | Situation | What "good" looks like | Competing alternatives |
|---|---|---|---|
| Trip research | Planning a specific trip | Practical, destination-specific, current | Travel blogs, YouTube, guidebooks |
| Armchair travel | Relaxing in the evening | Beautiful, calming, no effort to choose | Other streaming services, TV channels |
| Background viewing | Something on while doing other things | Long, pleasant, no need to pay attention | Music, ambient video, radio |
These are illustrative. But each job leads to different product decisions. Trip research needs search by destination. Armchair travel needs great recommendations and easy browsing. Background viewing might want long-form content and autoplay.
If you design for "people who like travel content," you'll probably serve none of them particularly well.
Find the real competition
JTBD is most useful when it changes who you think you're competing with. For the trip research job, the competition is mostly free blogs and videos that are often more current and more specific.
That's a sobering insight, and a useful one. It tells you where you need to be better, and where you might not be able to compete at all.
A B2B example
For an enterprise AI content tool, a job might be:
"When a new product update goes out, I want to produce training material for the sales team quickly, so they can talk about it confidently before customers ask."
The competing alternatives here are writing it yourself, asking a colleague, or sending the raw release notes and hoping. Each alternative has a time cost and a quality cost. Your product needs to beat them on at least one of those without losing on the other.
Getting the jobs right
Jobs come from research, not brainstorming. The best source is interviews about recent situations. Ask what was happening when they last used a product like yours, what they were trying to achieve, and what else they considered. I wrote about interview questions that help with this.
Listen especially for the moment someone decided to look for a solution. That trigger usually describes the situation part of the job very clearly.
Using it in planning
Once you have a few clear jobs, use them to check roadmap decisions. Which job does this feature serve? Does it make that job meaningfully easier than the alternatives? If a feature doesn't serve any of the main jobs, ask why it's on the list.
I don't think you need to adopt every part of the JTBD method. Even just writing job statements for your main user situations will sharpen a lot of product conversations.