Jobs to Be Done (JTBD) is a research framework that says customers do not buy products or features. They hire them to make progress in a particular situation, so a product team should define the job, the person doing it, and the outcomes they want before deciding what to build.
Applied well, it changes what a strategy argues about. Instead of ranking features, you rank the progress customers are trying to make, then fund the bets that serve the highest-stakes jobs. That is how to use jobs to be done in product strategy, and it takes a domain, about a dozen recent switchers to interview, one canvas, and a scoring session with the people who own the roadmap. The whole cycle usually runs somewhere between six weeks and a quarter, depending on how many job domains you cover.
Table of Contents
- What You Need
- A tight domain, not your whole product
- Participants who recently switched
- A structure for the interview, not a script
- People who can actually fund the result
- Step-by-Step: How to Use Jobs to Be Done in Product Strategy
- 1. Define the customer problem and the decision
- 2. Recruit people who have made the decision
- 3. Interview customers about real experiences
- 4. Turn interview evidence into job statements
- 5. Map job segments and opportunity areas
- 6. Prioritise opportunities using Jobs to Be Done
- 7. Test concepts against the job
- 8. Connect insights to the product roadmap
- Common Mistakes
- Frequently Asked Questions
- Does Jobs to Be Done replace personas?
- How many JTBD interviews do I need?
- How long does a Jobs to Be Done study take?
- How do I prioritize features with Jobs to Be Done?
- Should I validate JTBD research with quantitative data?
- What are the common mistakes in applying JTBD?
- Conclusion
What You Need
Before the first interview, get four things sorted. Skipping any one of them is how most JTBD programs quietly turn into a canvas nobody reads.
A tight domain, not your whole product
A domain is the situation where a customer makes a choice, not the category your company sells into. “Expense reporting” is a domain. “Our finance suite” is not. Pick a domain where the choice is difficult enough that people think about it before buying.
Participants who recently switched
You are looking for people who bought, cancelled or moved to a different solution for this job in the last few months. Recruiting from support tickets, sales calls, win-loss notes and review sites works better than recruiting from your own user base, because existing loyal users rarely describe a switching moment. Twelve to twenty interviews is a realistic working range for a single domain.
A structure for the interview, not a script
You need a chronological timeline. Most of the value comes from the first thought the person had about the problem, the moment they started looking, what they tried before you and what nearly stopped them. Bring a recorder, not a list of feature questions.
People who can actually fund the result
One researcher runs the interviews, one product manager owns the job map, and one decision maker with budget authority sits in the prioritisation session. GitLab’s public playbook puts the whole effort at roughly a quarter, which is a fair benchmark to set with your team before you start.
Step-by-Step: How to Use Jobs to Be Done in Product Strategy
1. Define the customer problem and the decision
Write down the job performer, the situation, and the boundary of the category in one page. If your statement needs the word “and” twice, the scope is too wide. The test is simple: could two different teams disagree about who belongs in this domain? If yes, keep narrowing.
2. Recruit people who have made the decision
Screen for a real event, not for interest. A good screen asks when they last made this choice, what they used before, and whether the purchase went through. Someone who says “I would use that someday” tells you nothing useful, so treat enthusiasm as a disqualifier rather than a sign of engagement.
3. Interview customers about real experiences
Start with “walk me back to the first moment you noticed a problem” and keep moving forward in time. Push, pull and habit forces all surface in this narrative: the push of what hurt with the old option, the pull of what they heard about yours, and the habit of doing nothing at all. The final question, “what was the very first thought when you started looking?”, usually contains more strategy than any other answer in the session.
4. Turn interview evidence into job statements
Cluster the timelines, then write one main job statement. The formula is an action verb, an object of action and a clarifier that names the situation.
When [situation], I want to [action verb] so I can [desired outcome].
Three rewrites of a weak statement show the difference. “Provide reporting” is a feature. “Track expenses so finance can close the month faster” is a job. “Reconcile receipts at month end so my manager stops chasing me” is a job with a real person and a real cost attached to getting it wrong.
5. Map job segments and opportunity areas
Group people by the situation they were in and the progress they wanted, not by demographics. Two accountants at the same company may share a job while someone in a different role does not. Pull the emotional layer too: how do they want to feel in front of their boss when the numbers land.
6. Prioritise opportunities using Jobs to Be Done
Ask participants to rate each desired outcome on importance and on how well current solutions satisfy it. The gap between the two is where the opportunity lives.
| Outcome | Importance (1-5) | Satisfaction today (1-5) | Opportunity score | Band |
|---|---|---|---|---|
| Close the month without manual reconciliation | 5 | 2 | 12 | High |
| Attach a receipt on a phone | 4 | 3 | 7 | Medium |
| Share a report with an auditor | 3 | 2 | 5 | Low |
Importance minus satisfaction is the standard calculation. Anything at 16 or above is a roadmap candidate, 10 to 15 goes into the next planning cycle, and 7 or below stays on the list but off the quarter. The scores are a ranking device, not proof. Confidence should be written next to each one, so the team can see which ones came from verified behaviour and which are still assumptions.
7. Test concepts against the job
Turn each high-scoring outcome into a “how might we” question, then build something small enough to put in front of the same job performer. The test is whether they can describe the job as easier after using it, not whether they compliment the prototype. If nobody can place your concept inside their own timeline, the concept is answering a job nobody has.
8. Connect insights to the product roadmap
Write the strategy document as a set of bets tied to jobs, each with an owner, a measure and a date. A typical line reads: bet on the month-end reconciliation job for finance managers, because it scores 12 on importance minus satisfaction, with cycle time as the measure. This is the step where how to use jobs to be done in product strategy stops being a research exercise and starts being a budget argument. Then record what you are explicitly not building and why. That list is the most read part of the document six months later.
Common Mistakes
Most of the criticism you will hear about Jobs to Be Done comes from teams making the same handful of errors. Each has a straightforward fix.
- Asking what features people want. Feature requests are an output of whatever they already know, so they smuggle the current product into your strategy. Fix: ask about the situation and the outcome, and treat every feature answer as a hypothesis.
- Studying people with no relevant experience. Enthusiasts who have never switched have no switching moment to describe. Fix: screen for a real past purchase, cancellation or move.
- Treating averages as universal. A statement that comes from three interviews is a lead, not a fact. Fix: report the count behind each statement so the team knows which ones carry weight.
- Overclaiming from a small sample. Qualitative research finds meaning, not proportions. Fix: never quote a percentage from a dozen interviews; use it to decide what to build next and test that with data.
- Confusing jobs with personas. A persona is a description of who someone is. A job is a progress they are trying to make. Fix: keep personas for messaging and segmentation, keep jobs for prioritisation.
- Stopping at the canvas. A beautiful job map that no roadmap decision cites is decoration. Fix: require every roadmap item to name the job and the outcome it serves.
- Ignoring the non-obvious alternatives. If you only study named competitors, you miss spreadsheets, doing nothing and an internal build. Fix: ask what they would have done if your category did not exist.
A practical habit from teams that get real value out of this: run the job research, then run a second prioritisation pass with a model you already trust, such as a willingness-to-pay test or KANO. Two different lenses agreeing on the same outcome is stronger evidence than either one alone. And keep the research alive after launch, because a job that changes with the market is a normal thing, not a failure of the method.
Frequently Asked Questions
Does Jobs to Be Done replace personas?
No. A persona describes who someone is; a job describes the progress they are trying to make in a specific situation. Personas are still useful for messaging, segmentation and channel choice, while jobs are what you use to rank what to build. Most teams end up using both, with jobs driving prioritisation and personas shaping communication.
How many JTBD interviews do I need?
For a single domain, twelve to twenty recent switchers is a realistic working range. You are looking for repetition in the timeline and the forces, not statistical significance, because qualitative interviews explain why people behave a way rather than how common it is. If new interviews keep producing the same job statement and the same top outcomes, you have enough to act on.
How long does a Jobs to Be Done study take?
Plan for six weeks to a quarter. Two to three weeks go to scoping and recruiting, which is the slowest part because you need people who actually switched. Interviews and synthesis take another two weeks, and mapping, scoring and the strategy session take one to two. GitLab’s public playbook budgets roughly a quarter for the full cycle with a workshop-based team.
How do I prioritize features with Jobs to Be Done?
You do not prioritise features directly. You score the desired outcomes inside each job on importance and current satisfaction, and the gap becomes the opportunity score. Fund the concepts that serve the highest-scoring outcomes first, then require every roadmap item to name the job it serves. A feature request with no job behind it gets deferred by default.
Should I validate JTBD research with quantitative data?
Yes, treat it as a sequence rather than a replacement. Interviews find the forces, the job statements and the outcomes that matter; survey or product data then tells you how big each segment is and whether the outcome you are targeting is common. If the two disagree, run more interviews on the segment that data says is large.
What are the common mistakes in applying JTBD?
The big ones are asking for features instead of situations, interviewing people who have never switched, quoting percentages from a small qualitative sample, and stopping once the canvas is finished. Each has a simple fix: screen for real decisions, report how many interviews sit behind every statement, and require each roadmap item to cite the job and outcome it serves.
Conclusion
The first move is small. Choose one important decision your customers make, find a dozen people who made it recently, and ask them to walk you back to the moment they started looking. Write down the job, the push and pull forces, and the outcomes they wanted. Then score those outcomes, fund the highest gap, and tell your team what you decided not to build.
That single loop, repeated when the market shifts, is what turns Jobs to Be Done from theory into a product strategy your roadmap can actually be held to.
