A jobs-to-be-done map breaks the job your customer is trying to get done into steps that do not depend on any product, then shows which steps your product serves badly. You build it from five to ten interviews, you map the ideal order of the job rather than today's clicks, you rate each step's outcomes, and the gaps become your roadmap. For a SaaS team with a free trial, the map explains why people sign up and never reach a first result. That is the problem we work on in our trial to paid engagement.
TL;DR
- A job map lists the steps of the customer's job in solution-free language: define, locate, prepare, confirm, execute, monitor, modify, conclude.
- Define one job performer and one main job, interview 5 to 10 representative people, then map and unify their steps.
- Rate each outcome for importance and current satisfaction. Important and poorly served outcomes are your opportunities.
- Express each opportunity as a job story ("When..., I want to..., so I can..."), then place it on the roadmap by customer pain and build cost.
- Keep the map tied to real interviews. Maps invented in a workshop describe your assumptions, not your customers.
Table of Contents
- What a job map actually shows
- How to build a jobs-to-be-done map, step by step
- A worked example: mapping a trial setup job
- Mapping jobs in B2B: more than one performer
- Job stories vs. user stories
- Using the map for roadmap prioritization
- Mistakes that make job maps useless
- Where trial teams usually find the biggest gap
- Turn the map into a better trial
- Our perspective
- FAQ
- Sources
What a job map actually shows
The core idea of the framework is that customers hire a product to make progress in a particular circumstance. Christensen, Cook and Hall describe it this way, and report a case where identifying distinct jobs supported several points of sale and improved conversion.
A job map is the tool that turns that idea into something you can work from. It decomposes the customer's core functional job into process steps that are independent of any solution. It does not show your features, and it does not show the screens a customer clicks through today. It shows what the person is trying to accomplish, in the order that would make the job efficient.
The universal version of the map uses eight stages:
- Define: decide what needs to be accomplished and plan how.
- Locate: gather the inputs, information and resources needed.
- Prepare: set up the environment so the job can start.
- Confirm: check that everything is ready before committing.
- Execute: carry out the core of the job.
- Monitor: check whether the job is going as intended.
- Modify: adjust when something is off.
- Conclude: finish the job and put things away.
Not every job shows every stage visibly, according to the same source, and a typical finished map holds 10 to 20 steps, often with several planning, gathering and execution steps. Treat the eight stages as a checklist for gaps in your interview notes, not a template to fill in.
Job map vs. customer journey map
The top search results often blur the two, so it helps to separate them. A journey map follows a customer through touchpoints with your company: ad, landing page, signup, onboarding, billing. A job map follows the customer through the work they are doing, whether or not your product is involved yet. A person who wants to onboard a sales team to a new tool is defining, locating and preparing long before they see your signup form.
The two work well together. Use the job map to decide what matters, then overlay your journey on it to see which job steps your touchpoints actually support. Where a touchpoint serves no job step, it is a candidate for removal. Where a job step has no touchpoint, you have found a gap.
How to build a jobs-to-be-done map, step by step
The most practical public process comes from GitLab's JTBD Research Playbook. The steps below follow it, with notes on where each one tends to go wrong.
Step 1: Define the domain, the job performer and the main job
Pick a narrow scope. The domain is the area (for example, getting a new team set up in a project tool), the job performer is the person doing the work, and the main job is the thing they are trying to get done, written without your product in it.
Where it goes wrong: the abstraction level. A job that is too broad ("grow my business") cannot be acted on, and one that is too narrow describes a single feature. The Re-Wired Group is not needed to see the rule: a good job groups people in similar circumstances without mixing people from entirely different situations.
Step 2: Recruit and interview 5 to 10 representative people
The playbook recommends 5 to 10 one-hour interviews with representative job performers, run by a moderator with a separate note-taker. The goal is to map steps, identify outcomes, discover related jobs and understand what differentiates one performer from another.
A 2024 ACM/IEEE workshop study found that effective JTBD interviews need preparation, confidence-building and structure, and that using a timeline or job map is a practice that separates them from traditional customer interviews. In practice, that means asking people to walk through the last time they did the job, in sequence, instead of asking what features they want.
Where it goes wrong: interviewing only happy customers. Include people who tried and left, because the steps they could not complete are the most informative.
Step 3: Draft a map per interview
Take each interview's notes or recording and write out that person's steps. Then rewrite each step in consistent job-step language: a verb and an object, with no product names and no technology. "Export the CSV from the CRM" becomes "Gather the customer list." That rewrite is the point of the exercise. It strips out today's solution so you can see the underlying work.
Step 4: Unify the maps into one
Combine the individual maps into a single one organized into beginning, middle and end categories. Merge steps that say the same thing in different words, and keep steps that only some performers have, marked as variants. Strategyn's guidance is to map the ideal order for efficient execution, not just the order people follow today, so when interviewees do things in a clumsy sequence, do not copy it in.
Step 5: Define and rate the outcomes
Under each step, write the measurable outcomes the performer wants, such as minimizing the time it takes to confirm the data is complete. Then survey a larger group of job performers on two things per outcome: how important it is and how satisfied they are with how it is served now. This is the core of Outcome-Driven Innovation, and the result is an opportunity landscape that shows outcomes that are important but poorly satisfied.
Step 6: Convert the gaps into job stories
Take the top opportunities and write them as job stories. The GitLab format is: when I am at this job step and under these conditions, I want this new ability, so I can achieve these outcomes. Evidence-based job stories express concrete needs without prescribing a solution, and they generate testable MVP hypotheses and usability-testing criteria.
A worked example: mapping a trial setup job
The following is an illustration, not client data. Say a project-management SaaS wants to understand why trial users stall. The domain is getting a new team working in a tool. The job performer is a team lead. The main job is "get my team working from one shared plan."
After eight interviews, the unified map might look like this:
| Stage | Job step (solution-free) | Example outcome |
|---|---|---|
| Define | Decide which projects move first | Minimize the time to pick the first project |
| Locate | Gather the existing task lists | Minimize the chance of missing a task |
| Prepare | Organize tasks into a plan | Minimize the effort to structure the plan |
| Confirm | Check the plan matches what the team expects | Minimize the likelihood of surprising a teammate |
| Execute | Assign work and set dates | Minimize the time to assign every task |
| Monitor | See what is blocked | Minimize the delay before spotting a blocker |
| Modify | Reassign or reschedule | Minimize the effort to change a date |
| Conclude | Close out finished work | Minimize the effort to report results |
If the survey shows that gathering the existing task lists is very important and badly served, the opportunity is not a prettier dashboard. It is the import path. That is the kind of finding that changes what a trial should put in front of a new user first, and it is why we look at the path from first login to first result in every trial teardown. Our product onboarding checklist covers what a signup-to-first-result flow should include once you know the job.
Mapping jobs in B2B: more than one performer
A B2B account is rarely one person. Product Blueprint recommends mapping buyers, champions, technical evaluators, end users, procurement, security and legal separately rather than treating a complex account as a single user. Each has a different main job, and a trial that serves only the end user can still die in a security review.
The buying side can shape your roadmap as much as the product side. Teams selling into regulated sectors, for example, can read how the health system procurement process turns paperwork into a build requirement. Map those jobs too, and then keep only the top 5 to 8 per account, parking the rest, as the same source advises.
For discovery work that surrounds the map, our overview of opportunity discovery methods shows when interviews, surveys and observation each fit.
Job stories vs. user stories
Once the map names an opportunity, you have to write it down so the team can build it. This is where job stories come in.
A user story follows the pattern "As a [persona], I want to [action], so that [outcome]" and tends to describe a feature. A job story follows "When [situation], I want to [motivation], so I can [expected outcome]" and adds context without implementation detail. Salesforce's Trailhead makes the same distinction: job stories frame the challenge, while Agile user stories specify features, and one job story can produce many user stories.
| User story | Job story | |
|---|---|---|
| Template | As a [persona], I want [action], so that [outcome] | When [situation], I want [motivation], so I can [outcome] |
| Starts with | Who the user is | The situation that triggers the need |
| Risk | Assumes the proposed action is the best one | Can feel vague without a clear performer |
| Best when | Users vary a lot and who they are matters | Needs are similar across users and context matters |
The last row reflects Mountain Goat Software's view: user stories help most when users differ significantly, and job stories help when needs are not very distinct because the "when" clause adds context. The same piece points out that in its postal-code example the rest of the story is identical, so the real difference sits in the opening clause.
Teresa Torres, writing in ProductTalk, makes the practical point: whichever format you use, requirements should reflect both the role of the user and the context in which the need arises. A good habit is to write the "when" clause from your interview evidence and add the persona only when it changes the design.
A job story from the example above might read: when I move my team from spreadsheets into a new tool, I want my existing task lists to arrive in one step, so I can start assigning work the same day. Notice there is no import button, no CSV and no wizard in it. The team stays free to find the best solution.
Using the map for roadmap prioritization
The map is most valuable when it changes what you build next. There are three well-documented ways to do that.
Use the map stages as roadmap themes. A List Apart describes framing themes by locating the most underserved needs in the map and using those stages as categories, or clustering needs into themes that do not follow the map's chronology.
Map each roadmap item to a job. Planet Roadmap advises mapping each item to a specific customer job, rating how well current solutions serve it, prioritizing features that address poorly served, high-importance jobs, and testing prototypes with real customers to validate assumptions. Workshop Weaver adds a coverage check: line the current roadmap up against the job map to see where you are covering, over-serving or leaving gaps.
Plot pain against cost. One published case used a 2x2 matrix with customer pain in the current workflow on one axis and anticipated build cost on the other, which surfaces high-impact, lower-cost opportunities to prototype first.
A simple order of work follows from these:
- List the job stories from your top five to eight opportunities.
- Score each for importance and satisfaction from the survey.
- Estimate build cost with engineering.
- Prototype the high-pain, lower-cost items before committing to full delivery.
- Re-run the check after launch to see whether satisfaction moved.
For teams working on a free trial, step four has a natural home in the first session. Our guides to in-app guidance and in-app usability testing show how to test whether a change actually shortens the path to the first result.
Mistakes that make job maps useless
Several practitioners list the same pitfalls, and they overlap enough to group:
- Writing features or tasks as jobs. If the job contains your product's nouns, it is a feature request. Rewrite it in solution-free language, as Workshop Weaver and Product Blueprint both recommend, ideally as an event-based statement that starts with what happened.
- Capturing only functional jobs. The framework covers functional, emotional and social jobs. A team lead choosing a tool also wants not to look foolish in front of the team.
- Inventing the map without interviews. A workshop of internal opinions produces a polished picture of what you already believe.
- Skipping the ratings. Without importance and satisfaction scores, every step looks equally worth fixing.
- Never connecting the map to the roadmap. A map that lives in a slide deck changes nothing.
- Treating jobs as personas. A job is a circumstance, not a type of person. The same person has different jobs on different days.
- Setting it once and forgetting it. Jobs shift as tools, habits and competitors change, so revisit the map on a regular cadence.
One more check: watch the abstraction level. If a step could belong to any product in any industry, it is too broad to act on.
Where trial teams usually find the biggest gap
For self-serve SaaS, the job map tends to expose an ordering problem. Customers want to reach the execute stage, the first real result, and the product asks them to do a lot of prepare work first. Typical symptoms are a long setup before any value appears, an upgrade prompt that lands before the first win, or a total that shows up late in checkout. The map gives you the language to explain why those moments hurt: they sit between the customer and a step they care about.
Our own work follows this logic. Our case study of Supliful describes how we rebuilt the setup flow so new creators could get from sign-up to a launched brand, and the company reached $1.1M monthly GMV. For more examples, see our roundup of B2B SaaS onboarding case studies.
Turn the map into a better trial
If your trial gets signups but few paying customers, a job map is a strong starting point, and it is only half the work. The other half is going through the trial as a buyer and seeing where the job stalls. In our trial to paid engagement, we go through your trial as a real user, with a stopwatch and a screenshot of every step, find where people leave, and redesign the path from first login to paid.
If you are still deciding which opportunity deserves funding, our AI + UX discovery work maps the workflow and names the idea that pays for itself. You can see all our work on the services page.
Our perspective
Most teams we meet do not lack ideas. They lack a clear view of the job their trial users came to do, and that view is what decides what gets fixed first.
A job map is useful to us for one reason: it makes the first result concrete. When we go through a trial as a buyer, the map tells us which step the person is really trying to reach, and everything standing in front of it becomes a candidate for change. Setup that comes before the first result, an upgrade prompt before the first win, a total that appears late: each is easier to defend or to remove once you can point at the job step it interrupts.
We tie every recommendation to documented user behavior rather than a hunch, and a job map is one of the cleanest ways to document it. If you build one, keep it small, keep it tied to real interviews, and test the first change in the product itself.
Edijs
FAQ
How many interviews do I need to build a job map?
GitLab's playbook recommends 5 to 10 one-hour interviews with representative job performers. Use a moderator and a separate note-taker so the conversation stays on the last time the person did the job. If new steps keep appearing after ten, your job is probably defined too broadly.
What is the difference between a job story and a user story?
A user story starts with a persona: as a [persona], I want [action], so that [outcome]. A job story starts with a situation: when [situation], I want [motivation], so I can [outcome]. The job story keeps the context that helps a team find alternative solutions, and one job story can lead to several user stories.
How does a job map help with roadmap prioritization?
It shows which outcomes matter most to customers and which are poorly served today. You map each roadmap item to a job, favor high-importance, poorly served jobs, and then weigh them against build cost. Prototype the top candidates before committing to full delivery.
How many steps should a job map have?
A typical map has 10 to 20 steps, often with several planning, gathering and execution steps. Not every job shows all eight universal stages, so use them as a check on your notes rather than a requirement.
Sources
- Building Your Job Map: JTBD Job Mapping
- JTBD Research Playbook, The GitLab Handbook
- Unveiling Customer Needs: A Comprehensive Exploration (ACM, 2024)
- How to Apply Jobs to Be Done Using Outcome-Driven Innovation (2024)
- Know Your Customers' Jobs to Be Done (Christensen, Cook, Hall, 2016)
- JTBD for B2B: Mapping Buyers and Users Without Getting Lost
- User Stories vs. Job Stories: What's Right for You?
- Improving Job Statements and Strategies, Salesforce Trailhead
- Job Stories Offer a Viable Alternative to User Stories
- How To Write Product Requirements That Engage Everyone, ProductTalk
- Jobs To Be Done, A List Apart
- Jobs to Be Done: Steps, Timing & Tips, Workshop Weaver
- Jobs to Be Done: A Framework for Product Discovery, Planet Roadmap (2025)
- Jobs to Be Done: From Research to Minimum Valuable Product (2023)
- Common Pitfalls in the Jobs to Be Done Framework (2025)
- Why most people get Jobs to be Done wrong
- Health system procurement process