The Mistake Everyone Makes Before Building a Job Map
When product teams discover Jobs to Be Done, they typically start in the same place: they write a job statement and then immediately ask “what do customers want?” They generate a list of needs, rank them by frequency of mention in qualitative interviews, and call the result a job map.
It is not a job map. It is a prioritized list of feature anecdotes organized under a job statement header. And it fails — consistently and predictably — because it skips the step that makes the job map actually useful: decomposing the job into its functional process steps before identifying any outcomes.
The distinction matters because a job is a process, not a state. A customer hiring your product to “prepare a patient for surgery” is not in a static condition — they are moving through a sequence of activities: assessing the patient’s current status, preparing the environment, administering pre-operative medication, confirming readiness, executing the preparation procedure, monitoring the patient’s response, adjusting as needed, and concluding the preparation phase. Each of those steps has its own set of desired outcomes — its own criteria for success and failure.
If you skip the process decomposition and go directly to “what do customers want?”, you will capture outcomes from the most salient steps — usually the execution phase in the middle of the process — and miss the outcomes at the beginning and end that are often the most underserved. Your product will optimize the phases customers are already complaining about while leaving intact the friction at the edges that they have learned to live with.
The job map prevents this. It is the structural backbone of JTBD research, and building it correctly is the first technical skill every product team needs to master.
What a Job Map Is
The Universal Job Map
Tony Ulwick’s Universal Job Map provides a template for decomposing any job into its functional stages. The map consists of eight steps that describe the sequence of activities a customer goes through to accomplish any goal:
1. Define — The customer determines their goals and plans the resources required.
2. Locate — The customer gathers the inputs, information, or materials needed to execute the job.
3. Prepare — The customer sets up the environment to perform the job.
4. Confirm — The customer verifies that everything is in order before executing.
5. Execute — The customer performs the core task of the job.
6. Monitor — The customer monitors the process and the environment while executing.
7. Modify — The customer modifies the process or environment to optimize outcomes.
8. Conclude — The customer finishes the job and evaluates the result.
The power of this template is that it applies universally. Whether the job is “perform a minimally invasive cardiac procedure,” “move a heavy prefabricated component to an elevated installation position,” or “prepare a financial close report for the board” — the eight-step structure holds. The specific activities within each step vary enormously; the sequence of functional stages does not.
Why the Process Structure Matters
The sequence is not just an organizing convenience. It reflects a fundamental truth about how humans accomplish goals: complex tasks have a beginning, middle, and end, and each phase has distinct constraints, success criteria, and failure modes.
This matters for product strategy because the distribution of unmet needs across the job process is rarely uniform. In every ODI engagement I have run, the highest-opportunity outcomes — the places where customers are most frustrated and most underserved — are disproportionately concentrated at stages other than the execution phase.
Execution is the phase that engineering teams think about most. Engineers know how to optimize execution — it is the part of the job that interacts most directly with the product’s core function. The stages that are frequently neglected are Prepare, Confirm, Monitor, and Conclude — the stages where customers are setting up, verifying, watching, and wrapping up. These are often the stages where the largest opportunity lies, precisely because no one is paying attention to them.
Building a Job Map: The Practical Process
Step 1: Confirm the Job Statement
Before mapping anything, you need a job statement that is properly formed: verb + object + contextual clarifier, with no solution or product references. The job statement defines the scope of the map.
If the job statement is wrong — too narrow, too broad, or solution-embedded — everything downstream will be wrong. Test your job statement before you begin mapping. I have seen entire job map efforts thrown out because the initial job statement was framed at the product level rather than the customer goal level.
For a pump manufacturer whose team initially defined the job as “operate the industrial pump,” the corrective work produced: “transfer fluid efficiently and reliably within a closed-process system under variable pressure conditions.” The difference in scope between those two statements is enormous — and the map it enables is correspondingly richer.
Step 2: Identify the Job Executor
Every job has someone doing it. This seems obvious, but in B2B contexts it is easy to confuse the purchasing organization with the individual performing the job. The job map is built from the perspective of the person doing the job, not the person buying the product.
In a hospital context, the job of “perform a diagnostic cardiac catheterization” is done by the interventional cardiologist — not the hospital procurement team, not the department head. The outcomes that belong on the map are the outcomes that matter to the cardiologist at each step of the procedure. The hospital administrator has related jobs (managing department throughput, controlling equipment costs) — those are separate jobs for separate maps.
Getting the job executor right is essential because the outcome statements that come from the map are only valid from a consistent perspective. Mixing outcomes from different executors produces a map that no one can validate quantitatively.
Step 3: Populate the Eight Stages
With the job statement and executor confirmed, work through each of the eight Universal Job Map stages and identify the specific activities that occur at that stage for this particular job.
This work is done through qualitative interviews — typically 15-30 interviews with experienced job executors. The interviews follow a specific protocol designed to elicit process description, not feature requests or product opinions. See our JTBD interview guide for the complete interview approach.
In the interviews, you are listening for:
- What does the customer do at the beginning of the process? What information do they gather? What decisions do they make?
- What preparation steps occur before the core execution?
- What verification steps occur before beginning?
- What does core execution look like, broken into sub-steps?
- What does the customer watch for during execution?
- What adjustments do they make when something is off?
- How do they conclude, and what do they check when finishing?
For each stage, document the activities in process terms (what is happening), not outcome terms (what the customer wants). The outcomes come later.
Step 4: Identify Desired Outcomes at Each Stage
Once the process map is populated, you work through each stage to identify the desired outcomes — the criteria customers use to judge success at that stage.
Outcome statements follow the syntax: direction of improvement + metric + object of control + contextual clarifier. The direction is almost always “minimize” or “maximize.” Examples:
At the Define stage: “Minimize the time it takes to determine the correct specifications for the job conditions.”
At the Locate stage: “Minimize the likelihood of selecting a component that is incompatible with the existing system configuration.”
At the Prepare stage: “Minimize the time required to configure the equipment for the specific operating conditions.”
At the Confirm stage: “Minimize the likelihood of beginning the procedure with an undetected calibration error.”
At the Execute stage: “Minimize the variation in output across extended operating cycles.”
At the Monitor stage: “Minimize the time it takes to detect that a critical parameter is moving outside acceptable range.”
At the Modify stage: “Minimize the disruption to ongoing operations required to adjust for changing conditions.”
At the Conclude stage: “Minimize the time required to document the completed job for compliance and audit purposes.”
A complete job map will typically produce 50–150 outcome statements across all eight stages. This is the dataset that will be measured in the quantitative survey phase.
Info
What Each Stage Reveals: A Practitioner’s Guide
The Define Stage: Where Strategy Meets Reality
The Define stage — where customers determine their goals and plan resources — is often where the most unexpected insights emerge. In most industries, nobody has ever asked customers “what makes planning for this job difficult?” because everyone assumes the planning is trivial or well-handled.
In a manufacturing context, I once found that the highest-opportunity outcomes in an entire ODI engagement were at the Define stage: customers spent enormous time trying to determine the correct operating parameters for non-standard conditions. The product worked beautifully once they figured out the parameters — but figuring out the parameters for edge cases was genuinely painful. No competitor had addressed it. The company that acted on this insight built a configuration guidance tool that became a more powerful differentiator than any product specification improvement.
The Locate Stage: The Invisible Preparation
Locate — gathering inputs, information, and materials — is frequently underappreciated because it is not “using the product.” It is what happens before using the product. In many B2B contexts, this stage includes sourcing technical documentation, verifying compatibility, identifying the right components or settings, and confirming availability.
The outcomes in this stage often reveal that the job starts much earlier than product teams think. If your product is the instrument used in execution, your lens is on execution. But the customer’s job starts when they begin gathering what they need to use the instrument — and that may be where their largest source of friction is.
The Confirm Stage: The Undervalued Checkpoint
The Confirm stage — verifying that everything is in order before executing — is often where regulatory, safety, and compliance-critical needs cluster. In MedTech contexts, Confirm stage outcomes related to ensuring calibration, verifying patient parameters, and confirming sterility are systematically high-opportunity.
Product teams that focus on Confirm stage outcomes tend to find product differentiation opportunities that are particularly defensible: the features that address Confirm stage needs are often not glamorous enough to attract feature-imitation from competitors, but are consistently valued by customers who have experienced the cost of skipping them.
The Monitor Stage: Where Crisis Prevention Lives
The Monitor stage — watching the process and environment during execution — is where outcomes related to early warning, anomaly detection, and real-time feedback cluster. In industrial and medical contexts, these outcomes are often about minimizing the time to detect that something is going wrong — before it becomes costly or dangerous.
Monitor stage outcomes are increasingly addressable by digital and IoT solutions even when the core product is physical. For companies looking for digital extension opportunities, the Monitor stage is often the highest-potential starting point.
The Conclude Stage: The Afterthought That Is Not
The Conclude stage — finishing the job and evaluating results — is where documentation, reporting, and handoff outcomes live. In B2B contexts, the Conclude stage is frequently the source of hidden frustration: jobs that are technically complete but require hours of post-execution documentation, quality recording, or compliance reporting.
I have seen Conclude stage outcomes consistently score high-opportunity across multiple industries — not because the physical job is hard to finish, but because the administrative and documentation work that follows execution is onerous and poorly addressed by any existing solution. Digital tools that address Conclude stage needs often find strong adoption precisely because they address pain that no product team previously took seriously.
Common Job Mapping Errors
Error 1: Conflating the Job Map with the Customer Journey
Customer journey maps describe how customers interact with your company across touchpoints — from awareness to purchase to onboarding to support. They are useful for service design and customer experience work.
Job maps describe how customers execute a goal, regardless of which company’s products they use. The job is done with whatever combination of products and workarounds is available. These are completely different artifacts with different purposes.
Conflating them produces a map that captures company-facing activities (calling support, reviewing an invoice, logging into the platform) alongside job-executing activities. These company-facing activities are not job steps — they are service interactions that occur around the job. Including them in the job map pollutes the outcome statement dataset.
Error 2: Mapping the Product Process, Not the Customer Process
Product teams are deeply familiar with how their product works. When asked to map the job, they often produce a map that follows the product’s workflow — the sequence of screens, functions, or operations that the product exposes.
This is the product interaction map, not the job map. The job map describes what the customer is trying to accomplish, independent of how the product is structured. In many cases, the product’s workflow maps to only a subset of the job — often the Execute and Monitor stages — while the Define, Locate, Prepare, Confirm, and Conclude stages are poorly served or completely invisible to the product.
Error 3: Too Much or Too Little Granularity
The job map should operate at a level of abstraction where each stage describes a meaningful activity category — not a single micro-action, and not an abstract theme. “Define” should contain specific activities like “determine the required operating specifications for the job conditions” and “identify the qualified personnel available to execute the job” — not a single vague entry like “planning” or a list of fifty individual micro-steps.
A practical test: can a job executor read each stage and recognize it as describing a real chunk of their work? If stages are too abstract, they will say “that doesn’t quite fit.” If stages are too granular, they will say “that’s just one tiny part of what I do at that point.”
From Job Map to Opportunity: The Connection to Quantitative Research
The job map is the input architecture for the quantitative survey. Each outcome statement goes into the survey and is rated by respondents on two dimensions: importance and satisfaction with current solutions.
The opportunity score — Ulwick’s formula: Importance + max(Importance − Satisfaction, 0) — identifies which outcomes are most underserved. Outcomes with high importance and low satisfaction score highest and represent the strongest product opportunity.
What the job map structure enables is a clear view of where in the job process the highest opportunity lies. Not just “outcome X is high-opportunity” but “outcomes in the Confirm stage are systematically underserved across our entire market.” This structural view is what turns opportunity scores into strategic direction.
It also enables segment analysis at the process level. You may find that one customer segment is primarily underserved in the Monitor stage (they need better real-time feedback during execution) while another is primarily underserved in the Conclude stage (they need better documentation and reporting tools). These are different product strategies for different segments — and the job map structure reveals them.
For a deeper understanding of how outcome statements are formulated from the job map data, that is the logical next step after mastering the mapping process. And what JTBD actually is provides the foundational framing that makes the job map make sense.
Every product team thinks they know what customers are trying to accomplish. The job map is how you find out that you knew the middle of the story but not the beginning or the end. In my experience, the most valuable insights come from the stages nobody thought to ask about — the Confirm stage, the Conclude stage, the Define stage. Engineering focuses on Execute. The market opportunity is often everywhere else.
Practical Application: A Workshop Format
For organizations running their first job mapping exercise, here is a productive workshop format that I have refined through dozens of engagements:
Participants: 8-12 people — a mix of product managers, engineers, customer-facing staff, and ideally 2-3 actual customers or recent interview subjects.
Duration: 1 full day (with pre-work).
Pre-work: Everyone reviews interview summaries or watches 2-3 edited customer interview recordings. The goal is a shared baseline of qualitative understanding before the workshop begins.
Morning (job definition and process mapping):
- 90 minutes on job statement refinement — arrive at a properly formed job statement that the team agrees represents the core customer goal
- 90 minutes on stage identification — using the Universal Job Map as a template, map the specific activities that occur at each stage for this job
Afternoon (outcome capture):
- 3 hours generating outcome statements for each stage — working in pairs, then reviewing as a group to check statement quality against the syntax rules
- 60 minutes prioritizing outcome statements for inclusion in the survey — not ranking importance, but removing duplicates and statements that are not properly formed
Output: A draft job map with 80-120 outcome statements, ready for review and refinement before survey design.
Frequently Asked Questions
Build a Job Map That Changes Your Product Strategy
Book a complimentary discovery call to explore how these ideas apply to your organization.
