Creating Job Maps to Visualize Customer Processes
This skill teaches you to decompose a customer's core functional job into eight universal process steps, producing a visual map that anchors your product manager roadmap in the actual structure of what customers are trying to accomplish.
Start by stating the customer's core functional job as a single verb-object phrase. Then decompose that job into its eight universal process steps: define, locate, prepare, confirm, execute, monitor, modify, and conclude. For each step, write a brief description of what the customer is trying to accomplish, independent of any current solution. The finished map becomes a stable backbone for generating desired outcome statements and identifying where customers are most underserved.
Outcome: You produce a validated job map that serves as a stable, solution-agnostic scaffold for generating desired outcome statements, spotting underserved steps, and making product prioritization decisions that reflect the real structure of the customer's process.
Prerequisites
- A clearly defined core functional job statement (see the sibling skill: Defining the Customer's Core Functional Job)
- Access to qualitative customer data from JTBD interviews, support logs, or observational research
- Basic familiarity with the Jobs-to-be-Done framework's distinction between functional jobs, emotional jobs, and consumption chain jobs
Overview
A job map is the structural backbone of the Jobs-to-be-Done (JTBD) Framework. It takes a customer's core functional job and decomposes it into a sequence of universal process steps that describe what the customer is trying to accomplish at each phase, not how they do it today. The output is a single-page visual artifact, typically a horizontal flow diagram or structured table, that captures the full scope of the job from the moment the customer begins to think about performing it through the moment they consider it finished. Because the map is solution-agnostic, it remains stable even as technology, competitors, and customer behaviors change. That stability is what makes it so valuable as a foundation for a product manager roadmap: instead of anchoring priorities to features or competitor moves, you anchor them to the enduring structure of the customer's process.
The eight universal steps in a job map are: define (what the customer wants to accomplish), locate (inputs and items needed), prepare (setting up the environment or inputs), confirm (verifying readiness before action), execute (performing the core action), monitor (tracking whether the action is succeeding), modify (making adjustments when something goes wrong or conditions change), and conclude (finishing the job and evaluating the result). Not every job uses all eight steps in equal weight. Some jobs have a dominant execute phase and a trivial prepare phase. Others spend most of their complexity in define and confirm. The map captures the customer's reality, not a template you force it into.
The concrete artifact you produce is a map document, typically a single visual or structured table, with one row or column per step, a brief description of what the customer is trying to accomplish at that step, and enough detail for another team member to independently generate desired outcome statements for each step. This artifact feeds directly into the sibling skills of writing desired outcome statements and identifying underserved outcome opportunities. A well-built job map also becomes a shared vocabulary across product, design, marketing, and sales teams. When everyone can point to a specific step and say "our customers struggle most at the monitor phase," strategic conversations get far more precise. The map does not replace your product manager roadmap. It creates the demand-side evidence that makes the roadmap defensible.
How It Works
The mental model behind job mapping is borrowed from process engineering, adapted for customer behavior. Every functional job, no matter how simple or complex, follows a roughly sequential flow from intention to completion. The eight steps are not arbitrary categories. They represent distinct phases of cognitive and physical effort that a customer moves through when performing any non-trivial task. The reason the framework uses universal steps rather than industry-specific ones is that universality forces you to stay above the solution layer. When you name steps after what the customer does with your product ("uploads the file," "clicks configure"), you are mapping your solution's workflow, not the customer's job. When you stay at the universal level ("prepare the input for processing"), you can see the job the way the customer sees it, which reveals needs your current solution ignores entirely.
The eight steps form a natural sequence, but the customer does not always experience them as a strict linear chain. In practice, the monitor and modify steps often loop: the customer checks results, makes an adjustment, checks again. The locate and prepare steps can interleave: you find one input, prepare it, then go find the next. The map captures the logical sequence, not the minute-by-minute timeline. Think of it as the canonical order in which concerns arise, not a rigid flowchart.
Each step in the map describes what the customer is trying to accomplish, phrased without reference to any product, technology, or workaround. This is the hardest discipline for product teams to maintain because practitioners instinctively describe behavior in terms of the tools they already know. The test is simple: if you removed every product from the market, would the step still exist? If yes, it belongs on the map. If no, you have described a solution step, not a job step. For example, "open the spreadsheet" is a solution step. "Organize the data so it can be analyzed" is a job step. The latter remains true whether the customer uses a spreadsheet, a database, a whiteboard, or a future tool that does not exist yet.
The reason this matters for building a product manager roadmap is that solution-agnostic steps expose the full competitive landscape. When you map the job at the universal level, you realize that your competitors are not just direct feature competitors. They include workarounds, manual processes, adjacent tools, and delegation to other people. A job map makes that visible. It also makes it visible where the job is poorly served today, because you can attach outcome metrics to each step and measure satisfaction independently. One step might be well-served by existing tools while another is consistently frustrating. That asymmetry is where product opportunities live.
The stability of a job map is its most underrated property. Jobs change slowly compared to solutions. "Managing personal finances" has had the same basic step structure for decades, even as the tools have shifted from ledger books to spreadsheets to mobile apps. This means a well-built job map can serve as a strategic foundation for years. You do not need to rebuild it every quarter. You update the outcome statements and satisfaction data that attach to it, but the map itself rarely changes.
Step-by-Step
Step 1: Confirm the Core Functional Job Statement
Before you can decompose a job, you need a clean, validated core functional job statement. , "manage personal finances over time"). Pull this from prior work on defining the core functional job. If you do not have a validated job statement, stop and create one first, because mapping an ambiguous or solution-contaminated job will waste every hour that follows.
Review the statement with at least one customer-facing team member (support, sales, or research) to confirm it resonates with what customers actually describe. Verify that the job is stated at the right level of abstraction: too broad ("live a better life") gives you a map with hundreds of sub-jobs, too narrow ("update a cell in the spreadsheet") gives you a map that is really a feature workflow.
Tip: Read your job statement aloud and ask: would a customer nod and say 'yes, that's what I'm trying to do' without needing to think about a specific product? If the answer is no, the statement is still contaminated by solution language.
Step 2: Gather Raw Process Data from Customer Sources
Collect the raw material you will use to populate each step. The best sources are transcripts from JTBD customer interviews, where customers described how they perform the job today. Support tickets, customer journey maps from UX research, and observational notes from ride-alongs or contextual inquiries are also strong inputs. You are looking for every action, decision, check, and adjustment the customer makes from the moment they first think about performing the job to the moment they consider it finished.
Pull direct quotes and specific behavioral descriptions into a single working document, organized chronologically. Aim for data from at least five distinct customers to ensure you capture the full range of process variation.
Tip: Highlight verbs in customer quotes. Statements like 'I check whether...', 'I look for...', 'I adjust the...' are direct signals of individual job steps. Cluster similar verbs to spot where multiple customers describe the same step in different words.
Step 3: Draft the Eight Universal Steps for Your Job
Create a table or horizontal flow with eight columns, one for each universal step: define, locate, prepare, confirm, execute, monitor, modify, conclude. For each step, write a one-to-two sentence description of what the customer is trying to accomplish at that phase of the job, using only solution-agnostic language. Start with the steps that are most obvious from your raw data (usually execute and locate are clearest) and work outward. Define describes how the customer determines what they want to achieve and plans their approach.
Locate covers gathering the inputs, information, tools, or materials needed. Prepare is about organizing and setting up those inputs so they are ready for use. Confirm is the readiness check before committing to action. Execute is the core performance of the job.
Monitor is tracking whether the execution is producing the desired result. Modify covers adjustments made when something deviates. Conclude is wrapping up and evaluating the overall outcome.
Tip: If you cannot write a meaningful description for one of the eight steps, that step may be trivial for this specific job. That is fine. Note it as a lightweight step rather than forcing content. Not all jobs weight all eight steps equally.
Step 4: Validate Steps Against Customer Data
Go back through your raw process data and assign each customer action, decision, or check to one of the eight steps. This is a coding exercise similar to qualitative data analysis. For each quote or behavioral note, ask: which universal step does this belong to? If a customer action does not fit any step, you may have discovered a sub-job or an emotional job that sits alongside the functional job.
Set those aside rather than forcing them into the map. If multiple customer actions cluster under a single step, that step is complex and may need sub-steps (which you will capture later as desired outcomes, not on the map itself). If a step has no supporting customer data at all, investigate whether it truly applies to this job or whether your interviews missed it. A step with zero data is a signal to go back to customers, not an invitation to speculate.
Tip: Keep a 'parking lot' for actions that feel important but do not fit neatly. These often turn out to be related jobs or consumption chain steps (how the customer acquires, learns, and maintains the solution) rather than steps within the core functional job.
Step 5: Write Solution-Agnostic Step Descriptions
Refine each step description so it passes the solution-agnostic test. Read each description and remove any reference to a specific product, tool, technology, channel, or workaround. Replace solution-specific verbs with functional verbs. ' The description should remain true regardless of what era, industry, or technology the customer operates in.
This is the single most important quality standard for the entire map. If your descriptions contain solution language, every downstream artifact, outcome statements, opportunity scores, product priorities, will be biased toward your current solution rather than the customer's actual need.
Tip: Have someone outside your product team read each step description and ask them to guess what product you are building. If they can guess, your language is still too solution-specific.
Step 6: Sequence and Annotate the Map
Arrange the eight steps in their natural left-to-right sequence. Between steps, add brief annotations for any loops or branches that your customer data revealed. The most common loop is between monitor and modify: customers check results, adjust, and check again. Another frequent pattern is a loop between locate and prepare when inputs arrive incrementally.
These annotations do not change the canonical eight-step structure. They indicate where the customer's experience is non-linear. Add a brief note under each step indicating its relative weight or complexity for this specific job. A step where customers spend the majority of their effort and encounter the most variability is a high-weight step and likely the richest source of product opportunities.
A step that is nearly automatic is low-weight.
Tip: Use a simple visual notation for loops: an arrow curving back from monitor to modify, or from locate to prepare. Keep the visual clean. The map's value comes from its simplicity, and adding too much detail turns it into a process diagram that nobody will reference.
Step 7: Review with Cross-Functional Stakeholders
Present the draft map to a small group that includes at least one person from product, one from customer-facing roles (support, sales, or customer success), and one from design or research. Walk through each step and ask two questions: Does this accurately describe what customers are trying to accomplish at this phase? Is anything missing? Customer-facing team members are especially good at catching missing steps because they hear about edge cases and failure modes that interviews sometimes miss.
Capture every piece of feedback as a specific edit to a specific step. Do not try to resolve disagreements in the meeting. Instead, note the disagreement and plan to validate with additional customer data. The goal of this review is not consensus but completeness.
Tip: Bring three to four direct customer quotes per step to anchor the conversation in evidence. When a stakeholder says 'I think customers also do X,' ask 'do we have a customer who described that?' If not, add it to the validation backlog rather than the map.
Step 8: Finalize and Connect to Downstream Artifacts
Incorporate feedback, resolve any open questions with targeted customer follow-ups if needed, and produce the final map document. The deliverable should be a single page, either a visual flow diagram or a structured table, with the job statement at the top, the eight steps in sequence, a description for each step, and annotations for loops and relative weight. Store this artifact where your product team can reference it easily: a shared drive, a wiki page, or a product management tool. The final and most important action is to connect the map to downstream work.
Each step becomes the anchor point for writing desired outcome statements. High-weight steps will generate more outcomes. The map also feeds into identifying underserved outcome opportunities and ultimately into applying JTBD insights to product strategy, where the job map becomes the structural foundation for your product manager roadmap.
Tip: Version the map with a date. While job maps are stable, you will occasionally discover a missing step or realize you scoped the job too broadly. A versioned map prevents confusion when team members reference it months later.
Examples
Example: B2C Financial App, Small Team
A fintech startup with a four-person product team is building a personal budgeting app. They have conducted eight JTBD interviews with target customers and defined the core functional job as 'manage personal finances over time.' They need a job map to identify where their product should focus first, given limited engineering resources and a six-month runway.
The team pulls interview transcripts into a shared doc and highlights every verb phrase customers used when describing how they manage their money. They cluster these into the eight universal steps. Define: customers determine their financial goals and decide what 'managing finances' means to them (saving for a house, reducing debt, building an emergency fund). Locate: customers gather financial information from bank accounts, credit cards, pay stubs, and bills.
Prepare: customers organize this information so it can be analyzed, often by categorizing transactions. Confirm: customers verify that the information is complete and accurate before making decisions. Execute: customers allocate money to categories, make payments, transfer to savings. Monitor: customers track spending against their plan throughout the month.
Modify: customers adjust allocations when unexpected expenses arise or income changes. Conclude: customers review their financial position at the end of a period and evaluate progress toward goals. The team annotates that monitor and modify are the highest-weight steps based on customer frustration data: seven of eight interviewees described difficulty tracking whether they were on plan mid-month. This insight directly shaped their product manager roadmap, prioritizing real-time spend tracking and smart alerts over the onboarding and setup features they had previously planned to build first.
Example: B2B SaaS, Enterprise Team
A mid-size SaaS company selling project management software has a 12-person product organization. They have 30 interview transcripts from construction project managers and have defined the core job as 'ensure a construction project is completed on time and within budget.' They want to use the job map to align three product squads around customer-centric goals rather than feature areas.
The research team codes all 30 transcripts against the eight steps, producing a dense matrix of customer actions mapped to universal phases. Define: project managers establish the project scope, timeline, milestones, and budget parameters before any physical work begins. Locate: they identify and secure the required subcontractors, materials, permits, and equipment. Prepare: they sequence work activities, stage materials on-site, and brief subcontractor teams.
Confirm: they verify permit approvals, material delivery, and subcontractor readiness before each phase begins. Execute: they oversee the performance of each construction phase. Monitor: they track progress against the schedule and budget, flag variances, and report status. Modify: they re-sequence work, negotiate change orders, and reallocate budget when delays or cost overruns occur.
Conclude: they complete punch lists, close out permits, hand over documentation, and conduct a post-project review. The map revealed that confirm and modify were the most complex and frustrating steps: permit verification and change order management consumed disproportionate time. The product leadership used this to restructure squad assignments. One squad now owns the confirm step (permit tracking and readiness workflows), one owns monitor and modify (variance detection and change order management), and one owns define and conclude (project setup and closeout).
Each squad generates outcome statements for its steps, and the combined scores form a unified product manager roadmap.
Example: B2C Healthcare, Solo Product Manager
A solo product manager at a digital health startup is building a medication adherence app. She has conducted five interviews with patients managing chronic conditions and defined the job as 'take the right medication at the right time consistently.' She needs a job map to guide her first product release with a two-person engineering team.
Working alone, the PM creates a simple spreadsheet with eight columns and starts coding interview notes. Define: patients understand their medication regimen, including which medications to take, dosages, and timing. Locate: they obtain prescriptions, refill medications, and ensure they have an adequate supply. Prepare: they organize medications by time of day, set up pill organizers, and position medications where they will see them.
Confirm: they verify they are about to take the correct medication and correct dosage (especially important when regimens change). Execute: they take the medication. Monitor: they track whether they have taken each dose and watch for side effects or interactions. Modify: they adjust timing when schedules change (travel, shift work) or when a doctor changes the regimen.
Conclude: they evaluate whether the medication is working by assessing symptoms and discussing with their doctor at follow-ups. The execute step turns out to be almost trivial, it is physically swallowing a pill, yet the PM's initial feature ideas had focused entirely on making that moment pleasant. The map shows the real complexity is in define (understanding a multi-drug regimen), confirm (avoiding errors with similar-looking pills), and modify (handling changes). She restructures her product manager roadmap to prioritize a regimen clarity feature and a change-management workflow over the reminder notification system she had originally planned.
Example: B2B Professional Services, Large Organization
A global consulting firm's internal product team is building a knowledge management platform for 5,000 consultants. They have conducted 15 interviews across four offices and defined the core job as 'find and apply relevant expertise to solve a client problem.' They need the job map to justify a significant platform investment to the executive committee.
The team assembles a cross-functional mapping group: two product managers, one UX researcher, one senior consultant, and one knowledge management librarian. They code interview data collaboratively in a two-day workshop. Define: consultants frame the client problem, identify what type of expertise is needed, and determine whether they can solve it themselves or need external knowledge. Locate: they search for relevant prior work, identify colleagues with relevant experience, and find external research or data.
Prepare: they synthesize and adapt found knowledge to the specific client context, translating general frameworks into industry-specific recommendations. Confirm: they validate that their approach is sound by checking with senior colleagues, comparing to precedent engagements, and verifying data accuracy. Execute: they develop and deliver the client solution. Monitor: they track client reactions and engagement outcomes to gauge whether the expertise was correctly applied.
Modify: they refine the solution based on client feedback and evolving project requirements. Conclude: they document lessons learned and make their new expertise available for future consultants. The map reveals that locate and prepare account for an estimated 60% of consultant frustration. Consultants described spending hours searching fragmented systems and then manually adapting what they found.
The executive committee had been skeptical of the platform investment, but seeing the job map with customer quotes attached to each step, particularly the locate and prepare pain, made the case concrete. The resulting product manager roadmap prioritized intelligent search and contextual adaptation features, with a clear line of sight from each feature to the specific job step it addresses.
Best Practices
Always map the job from the customer's perspective, never from the perspective of your product or internal workflow. The most common failure mode in job mapping is unconsciously mapping your own product's user flow. Test each step by asking: if our product disappeared tomorrow, would the customer still need to accomplish this? If yes, the step is correctly scoped.
If no, you have described a solution step that will anchor your roadmap to the present rather than the future.
Keep the map at a single level of abstraction. Each of the eight steps should be roughly the same granularity. If your execute step is one sentence but your prepare step has five sub-bullets, you have mixed levels. Detailed sub-steps belong in the desired outcome statements that attach to each step, not on the map itself.
Mixing granularity makes the map harder to use as a shared reference and biases attention toward the overly detailed steps.
Treat the eight universal steps as a diagnostic checklist, not a rigid template. Some jobs genuinely have a trivial or nonexistent confirm step. Others have an elaborate multi-phase define step. Record what the data tells you.
Forcing content into empty steps produces fiction. Noting that a step is trivial produces useful insight, because a trivial step is one where customers are already well-served, and you should probably invest elsewhere.
Use the job map as a living reference document, not a one-time deliverable. Pin it in your team's workspace. Reference it in sprint planning, roadmap reviews, and strategy discussions. The map's value compounds over time as team members internalize the customer's process and start seeing product decisions through the lens of the customer's steps.
A map that sits in a forgotten slide deck delivers zero value after the first week.
Validate the map with at least two customers who were not part of the original research sample. Show them the map (translated into plain language, not framework jargon) and ask them to walk you through their process. Where their description diverges from your map, investigate. This validation step catches blind spots that even good qualitative research can miss, especially steps that customers perform unconsciously or consider so obvious they do not mention them in interviews.
Separate the core functional job map from consumption chain steps and emotional or social jobs. Customers also have jobs related to acquiring, learning, and maintaining your product. Those are real, but they belong on a separate consumption chain map. Mixing them into the core functional job map dilutes focus and creates a sprawling artifact that is hard to use for prioritization.
The core job map should answer only: what is the customer trying to get done, functionally, independent of any solution?
When building a product manager roadmap from the job map, assign each initiative to the specific step it improves. This creates a traceable link between customer need and product investment. If you cannot assign an initiative to a step, it may be a solution-push feature rather than a customer-need feature. That does not automatically mean it is wrong, but it should trigger a conscious conversation about why you are building it.
Common Mistakes
Mapping the current product workflow instead of the customer's job
Correction
This is the most common mistake and it happens because product teams are steeped in their own solution. The symptom is step descriptions that contain product-specific nouns: 'configure the dashboard,' 'upload to the platform,' 'select a template.' The reason it happens is that interview data is often phrased in terms of the tools customers currently use, and the mapper transcribes the tool language directly. To catch it early, read each step description to someone unfamiliar with your product. If they ask 'what dashboard?' or 'what platform?', the language is solution-specific. Rewrite using functional verbs: 'organize the data for analysis,' 'transfer the input to where it can be processed,' 'choose a structure for the output.'
Creating a map that is too granular, with dozens of sub-steps under each universal step
Correction
This happens when the mapper confuses the job map with a detailed process diagram or user story map. The symptom is a multi-page document that nobody references after the initial meeting. The job map should fit on a single page or screen with one description per universal step. Detailed sub-activities belong in the desired outcome statements that attach to each step, not on the map itself.
If your map has more than 12-15 items total, you have probably gone too deep. Consolidate related activities back up to the universal step level and save the detail for outcome generation.
Skipping the define or conclude steps because they seem trivial
Correction
Many teams jump straight to locate or prepare because those feel more tangible. The define step, where the customer determines what they want to accomplish and plans their approach, is often where the most painful unmet needs live. Customers frequently struggle to articulate their goals, set realistic expectations, or choose among competing approaches. Similarly, the conclude step, where customers finish the job and evaluate whether the outcome met their expectations, is rich with emotional and functional needs.
If your map has blank or one-word entries for define or conclude, go back to your interview data and look for statements about planning, goal-setting, expectation-setting, evaluation, and reflection. Those statements map to these steps.
Building the map from assumptions without customer data
Correction
The symptom is a map that looks logical and complete but produces outcome statements that customers do not recognize as important. ' The problem is that assumption-based maps reflect the team's mental model of the job, which is biased by their own expertise and product knowledge. A map built on assumptions will miss steps that customers perform but the team does not think about, and it will over-weight steps the team finds interesting. Always build from customer data first, even if it is a small sample.
Five solid interview transcripts produce a far better map than a two-hour whiteboard session with the product team.
Treating the eight steps as equal in weight and investing equally in each
Correction
The universal steps provide structure, but the customer's reality is not evenly distributed across them. Some jobs have an elaborate, multi-phase execute step and a nearly instant confirm step. When teams treat all eight steps as equally important, they spread research, outcome generation, and product investment too thin. Annotate relative weight on the map based on customer data: where do customers spend the most time, encounter the most variability, and express the most frustration?
High-weight steps deserve more desired outcome statements and more product investment. Low-weight steps may need only a handful of outcomes. This annotation directly shapes the product manager roadmap priorities.
Creating multiple job maps for the same job performed by different customer segments
Correction
A core functional job is segment-agnostic. 'Manage personal finances over time' is the same job whether performed by a recent graduate or a retiree. What differs between segments is the importance and satisfaction scores on the desired outcomes that attach to each step, not the steps themselves. If you find yourself creating different maps for different segments, you have likely mixed solution-specific behavior into the step descriptions.
Return to solution-agnostic language and you will find the steps converge. Segment-level differences belong in customer segmentation by unmet needs, not in the job map structure.
Other Skills in This Method
Conducting JTBD Customer Interviews
How to run switch interviews and timeline interviews that uncover the real jobs, hiring criteria, and switching triggers behind customer decisions.
Identifying Underserved Outcome Opportunities
How to use opportunity scoring (importance vs. satisfaction) to quantify which desired outcomes are most underserved and represent the best innovation targets.
Applying JTBD Insights to Product Strategy and Roadmaps
How to translate job maps, outcome scores, and opportunity landscapes into actionable product roadmaps, feature priorities, and go-to-market positioning.
Defining the Customer's Core Functional Job
How to identify and articulate the fundamental job a customer is trying to accomplish, using proper job statement syntax and structure.
Writing Desired Outcome Statements
How to craft properly structured outcome statements (direction + metric + object of control + context) that capture measurable customer success criteria at each job step.
Segmenting Customers by Unmet Needs
How to create outcome-based customer segments that group people by shared underserved outcomes rather than demographics, enabling more targeted product strategies.
Related Skills from Other Methods
Frequently Asked Questions
How long does a job map stay valid before it needs updating?
Job maps are remarkably stable because they describe functional needs, not solutions or behaviors. A well-built map for a core functional job typically remains valid for 3-5 years or longer. What changes more frequently are the desired outcome statements and satisfaction scores that attach to each step. Plan to refresh outcome data annually and re-validate the map structure every 2-3 years or when a major technology shift fundamentally changes how the job is performed (e.g., the introduction of smartphones changed the locate and monitor steps for many jobs).
How many customer interviews do I need before building a job map?
Five to eight well-conducted JTBD interviews typically provide enough data to draft a complete map. You will reach diminishing returns around 12-15 interviews for the map structure itself, though you may need more interviews to generate comprehensive desired outcome statements for each step. If you have fewer than five interviews, you can draft a provisional map, but flag it clearly as unvalidated and plan targeted follow-up interviews to fill gaps. The risk of building from too little data is not that the map will be wrong, but that it will be incomplete, missing steps that a broader sample would have revealed.
Should I create a job map before or after writing desired outcome statements?
Always create the job map first. Desired outcome statements are organized by job step, so you need the map as the structural scaffold before you can generate outcomes systematically. Attempting to write outcomes without a map leads to an unstructured list that is hard to prioritize and often has gaps because you have no framework for ensuring coverage across all phases of the job. The map-first sequence also ensures that your outcomes are attached to the right step, which matters when you later score importance and satisfaction to identify underserved opportunities.
Can one customer have multiple job maps?
Yes, but be precise about what you mean. A customer typically has one core functional job in a given context, and that job gets one map. However, a customer may have several distinct functional jobs across their role or life. A marketing manager might have 'generate qualified leads,' 'measure campaign effectiveness,' and 'manage vendor relationships' as separate jobs, each with its own map. The key is to avoid combining multiple jobs into a single map. If you find yourself with a map that has 15 or more distinct activities, you likely have two or more jobs blended together. Split them.
How do I use a job map to build a product manager roadmap?
The job map becomes the demand-side structure for your roadmap. First, generate desired outcome statements for each step. Then survey customers to score each outcome on importance and satisfaction. Steps with high-importance, low-satisfaction outcomes are your biggest opportunities. Map your current and planned features against these opportunities to see where you are investing and where you have gaps. Your product manager roadmap then becomes a sequence of bets organized by which job steps you are improving, with clear evidence for why each investment matters. This approach is detailed in the sibling skill [applying JTBD insights to product strategy](/skills/applying-jtbd-to-product-strategy).
What if my team disagrees about which universal step an activity belongs to?
Disagreements about step assignment are common and usually productive. , an activity that is partly locate and partly prepare), or team members have different mental models of the customer's process. Resolve by returning to customer data. Read the original quote in context and ask which phase of the job the customer was in when they described this activity. If the activity genuinely spans two steps, note it in both with an annotation. Do not spend more than five minutes debating a single assignment. If it is ambiguous, it will not materially affect your prioritization decisions.
Why does my job map keep drifting toward our product's feature set?
This drift happens because your team's mental model of the customer's job is shaped by years of working on your product. Every day you think about features, user flows, and product metrics, so that vocabulary colonizes your descriptions. The antidote is a deliberate review pass where you read each step description and ask: would this description make sense to a customer who has never heard of our product or any competitor's product? Schedule this as a specific review step, not an afterthought. Having a team member from outside product (a customer success manager or a researcher) do this review is especially effective because they are less anchored to the product vocabulary.