Mapping the Job: Ulwick's Eight Universal Steps of Getting Anything Done

Every functional job — cleaning a house, onboarding a new hire, hedging a currency position — breaks into the same eight universal steps: define, locate, prepare, confirm, execute, monitor, modify, and conclude. Tony Ulwick's job map strips away who does the job and what tool they use, leaving a solution-free skeleton you can attach outcome statements to, then score for opportunity.

Quick answer: Ulwick's eight universal steps — define, locate, prepare, confirm, execute, monitor, modify, conclude — describe the process any functional job follows, independent of industry, era, or solution. Map a job against them, attach outcome statements to each step, and you'll usually find the biggest unmet opportunities clustered around the steps nobody designs for: monitor and modify.

What a Job Map Actually Is (and Isn't)

A job map is a solution-free breakdown of the process someone follows to get a functional job done — not a persona, not a user flow, not a customer journey. It describes the job itself, abstracted enough to hold true across decades, industries, and whatever tool eventually gets built to help with it.

That distinction matters because teams routinely confuse the three. A job statement is the single sentence anchoring the whole exercise — an action verb, an object, and a contextual clarifier, something like "clean the house before guests arrive." If that sentence isn't tight, everything downstream drifts; our guide to the JTBD job statement format covers the verb-object-context structure a job map hangs off of.

A job map, by contrast, is the multi-step process that single sentence implies. It's not one line — it's eight, and each one is itself solution-free. "Locate cleaning supplies" is a step; "open the Swiffer app" is not — that's a solution creeping into a process that's supposed to outlive any specific product.

This apparatus comes from Tony Ulwick, who formalized it at Strategyn in the 1990s and published it in What Customers Want (2005) as the backbone of Outcome-Driven Innovation (ODI). Clayton Christensen's Competing Against Luck (2016) popularized the broader Jobs-to-Be-Done idea for a mainstream business audience, but it's Ulwick's version that comes with the harder machinery: the map, the outcome statement grammar, and the opportunity algorithm. If you're new to the theory underneath all of this, our complete guide to Jobs-to-Be-Done is the place to start before this piece.

It's also worth separating a job map from a customer journey map, which is a different tool solving a different problem. A journey map traces one persona's emotional experience with your current solution across specific touchpoints — it's solution-full and time-bound. A job map is solution-free and timeless; the steps to "onboard a new hire" were roughly the same in 1975 as they are today, even though the tools changed completely. Our customer journey mapping guide is the better tool when you need to diagnose friction in an existing experience rather than decompose the underlying job.

The Eight Universal Steps, Defined

Ulwick's eight steps are define, locate, prepare, confirm, execute, monitor, modify, and conclude — each a distinct phase that exists whether the job is manual or automated, physical or digital, done by a person or a machine. Together they form a universal template you populate with outcome statements, never with solutions.

Three rules keep a job map honest to the methodology:

1. Stay solution-free. No tool names, no channels, no technology — "locate supplies," not "search Amazon."
2. Write steps as the job, not as tasks around the job. Emotional or social jobs (how the person wants to feel) get tracked separately, not folded into the process steps.
3. Keep the process, not the person, constant. The same eight steps apply whether a professional cleaner, a robot vacuum, or a teenager on chore duty does the work.

It helps to think of the eight steps in three natural clusters: getting ready (define, locate, prepare, confirm), getting it done (execute), and seeing it through (monitor, modify, conclude). Most roadmaps overinvest in the middle cluster and underinvest in the last one — which is exactly where this gets interesting.

Mapping a Real Job: Onboarding a New Hire

Applying the eight steps to "onboard a new hire" turns a fuzzy HR ritual into eight discrete moments, each with its own success criteria and its own candidate outcome statements. The job statement itself might read: "integrate a new employee into the organization so they can contribute independently."

Notice the grammar: direction + metric + object of control + clarifier. "Minimize the time it takes to provision hardware, credentials, and workspace" is measurable, solution-free, and testable years from now regardless of what HRIS the company uses. That's the point — outcome statements, unlike feature requests, don't expire.

Where the Opportunities Hide: Monitor and Modify Are Chronically Underserved

Underserved outcomes cluster overwhelmingly around monitor and modify — the two steps most roadmaps quietly skip because they're unglamorous and hard to demo. Teams build beautifully for execute (the visible, satisfying middle of the job) and leave the "is this working, and what do we do if it isn't" steps to spreadsheets, gut feel, and Slack pings.

You can see the pattern by scoring outcome statements with Ulwick's own formula:

Opportunity Score = Importance + max(Importance − Satisfaction, 0)

Scores above roughly 10-12 (on a 1-10 importance/satisfaction scale) flag outcomes worth building for. The table below is an illustrative pass at the onboarding job — hypothetical numbers to show the shape of the pattern, not survey results:

*Illustrative scores calculated with Ulwick's formula — treat as an example of the pattern, not a benchmark. Real scores come from surveying actual job-doers.

Why does this pattern show up so consistently? A few real, converging reasons:

• Execute is where the demo lives. It's the step stakeholders can see and screenshot, so it absorbs disproportionate design attention.
• Monitor and modify are feedback loops, not linear tasks — and feedback loops are exactly what systems thinking is built to reason about. A job map's monitor/modify pair is, structurally, a small balancing loop: sense a gap, adjust, re-sense. Teams that only think in linear process steps miss that these steps need instrumentation, not just UI.
• Bob Moesta's work at the Rewired Group on "struggling moments" points at the same territory from a different angle — the moments people actually remember and get frustrated by are rarely the core task, but the detours and course-corrections around it.
• Strategyn's own ODI case studies, across categories as different as software and medical devices, repeatedly surface monitor- and modify-stage outcomes as among the least satisfied, most important — directionally consistent with what Ulwick describes in his outcome-scoring work.

That's genuinely useful for a discovery PM: before you brainstorm a single feature, score every outcome statement on every step. The steps with the widest importance-satisfaction gap are where competitors are least likely to have already built something good — which is precisely why they're worth your first bet, not your last. Our breakdown of the Opportunity Score formula walks through gathering real importance and satisfaction ratings instead of the illustrative numbers above.

From Map to Roadmap: Turning Steps Into Something Engineering Can Build

A job map only pays off once its highest-opportunity outcome statements get translated into specs a team can actually build against — and that handoff is where most JTBD work quietly dies. A solution-free outcome statement is deliberately vague about implementation; someone still has to turn "increase the likelihood of detecting disengagement before day 30" into a concrete feature bet.

That translation step benefits from a second, more familiar prioritization pass. RICE (reach, impact, confidence, effort) and Kano (basic, performance, delighter) both work well after opportunity scoring narrows the field — opportunity scoring tells you which outcomes matter most to underserved job-doers; RICE/Kano help you sequence the resulting bets against team capacity and delight potential.

Just as important is preserving the outcome statement's precision as it moves toward a ticket. "Detect disengagement earlier" is a fine outcome statement and a terrible acceptance criterion — it needs a measurable trigger, a data source, and an owner before an engineer can spec it. Our piece on making job statements survive the handoff to engineering covers the rewriting discipline that keeps intent intact once a JTBD artifact crosses into a sprint.

Mapping Jobs Inside Prodinja

If you're doing this exercise for real rather than on a whiteboard, Prodinja's Customer Jobs tool is built around exactly this workflow: break a main job into its steps, attach outcome statements to each one, and let the map feed directly into Opportunity Score and Forces of Progress scoring rather than living in a disconnected spreadsheet. It's designed as a prototype experience for discovery PMs who want the map and the scoring to stay connected as the job evolves — not a claim that it has already run studies for you, but a place to do the work described in this article without losing the thread between step, outcome, and score.

Key Takeaways

• Ulwick's eight universal steps — define, locate, prepare, confirm, execute, monitor, modify, conclude — describe the process behind any functional job, regardless of industry or solution.
• A job map is solution-free and timeless; a customer journey map is solution-specific and emotional. They answer different questions and shouldn't be used interchangeably.
• Each step gets its own outcome statements, written as direction + metric + object + clarifier, so they stay measurable and testable for years.
• Underserved opportunities cluster disproportionately around monitor and modify — the feedback-loop steps most roadmaps neglect in favor of the more visible execute step.
• Use Opportunity Score (importance + the gap versus satisfaction) to find the highest-leverage outcomes before brainstorming features, then sequence with RICE or Kano.
• The handoff from outcome statement to engineering ticket needs deliberate rewriting — vagueness that's a feature in discovery becomes a liability in a sprint.