Impact Mapping: Always Think About the User (Because Most Roadmaps Don't)
Goals → Actors → Impacts → Deliverables: The Framework That Stops User-Free Planning
This is one of RoadmapOne ’s articles on Objective Prioritisation frameworks .
Gojko Adzic created Impact Mapping to solve a problem he saw repeatedly: teams building features with no clear connection to business goals or user behaviour. The framework forces explicit answers to questions that roadmaps often skip: Who needs to change their behaviour? What behaviour change do we need? Only then—what could we build?
Adzic isn’t new to structured thinking about software. He’s the father of Behaviour-Driven Development and invented Given-When-Then notation. Impact Mapping brings that same rigour to product strategy—ensuring we always think about the user before thinking about the solution.
Impact Mapping structures discovery: Goal (what you’re trying to achieve) → Actors (who needs to change behaviour) → Impacts (what behaviour changes do you need) → Deliverables (what could create those changes). The “Actors” layer is what makes it unique—forcing explicit consideration of who you’re building for. Use Impact Mapping during discovery, especially for B2B products with complex stakeholder maps. Then prioritise the deliverables with RICE or BRICE and allocate capacity in RoadmapOne.
The Four Layers
Goals: The Business Outcome
Goals sit at the centre of the impact map (traditionally visualised as a mind map radiating outward). They’re measurable business objectives—what success looks like.
- “Increase trial-to-paid conversion from 5% to 10%”
- “Reduce support ticket volume by 30%”
- “Expand ARR from existing customers by 25%”
Goals should be SMART: Specific, Measurable, Achievable, Relevant, Time-bound. They’re the “why” that justifies everything that follows.
Actors: Who Needs to Change
The first branch from each goal identifies who could help or hinder achieving it. Actors aren’t just users—they’re anyone whose behaviour affects the outcome.
For “Increase trial-to-paid conversion”:
- Trial users — the obvious ones; need to convert
- Sales team — could help by timely outreach
- Champions within trial accounts — internal advocates who push for purchase
- Finance approvers — gate purchase decisions
- Existing customers — could provide referrals that bring higher-intent trials
This is where Impact Mapping earns its keep. Most roadmaps assume “users” as a monolithic category. Impact Mapping forces you to identify specific actors and their distinct roles in achieving your goal.
Impacts: What Behaviour Changes You Need
For each actor, you identify the behaviour changes that would help achieve the goal. What do you need them to do differently?
For “Trial users” helping “Increase trial-to-paid conversion”:
- Complete onboarding within 48 hours
- Reach “aha moment” by day 3
- Invite at least one teammate
- Use the product 3+ times per week
- Engage with pricing information
For “Champions within trial accounts”:
- Share success metrics with decision-makers
- Build internal business case
- Identify and address objections early
Impacts are behaviour-focused, not feature-focused. You’re not saying “use feature X”—you’re identifying the behaviour change that would move your goal metric.
Deliverables: What Could Create Those Changes
Only at the bottom layer do you brainstorm what to build. For each impact (behaviour change), what deliverables might create that change?
For “Complete onboarding within 48 hours”:
- Streamlined onboarding flow
- Interactive product tour
- Onboarding checklist with progress indicator
- Email sequence with setup guides
- Human-assisted onboarding call option
Deliverables are hypotheses about what might create the desired impact. They’re not commitments—they’re candidates for experimentation and prioritisation.
Always Think About the User
One of my recurring frustrations is diagrams that contain lots of fancy boxes but don’t include the users. It’s a classic failure mode of architects—beautiful technical diagrams showing services, databases, APIs, and integrations with no indication of who actually uses this stuff or why they care.
Impact Mapping makes that failure mode impossible. The Actors layer forces explicit consideration of who you’re building for before you discuss what you’re building.
This matters because:
Different actors need different things. Enterprise buyers care about security and compliance. End users care about ease of use. Champions care about being able to demonstrate value. A feature that delights one actor might be invisible or irrelevant to another.
Behaviour change is the mechanism. You don’t achieve business goals by building features. You achieve them by changing user behaviour. Features are just one possible input to behaviour change—and often not the most effective one.
It prevents solution-first thinking. When you have to trace every deliverable back through an actor and an impact to a goal, you can’t justify features that exist “because competitors have them” or “because stakeholders asked.”
Objectives Should Include the User
When building roadmaps, your Objectives should capture:
- The specific problem you need solved
- Who specifically needs that problem solved
- How you will measure success
Impact Mapping provides the structure to answer all three. The Goal is your success metric. The Actors tell you who. The Impacts clarify the problem (the behaviour that needs to change). Deliverables become the solutions you’ll consider.
In RoadmapOne, an Objective like “Increase trial-to-paid conversion from 5% to 10%” should include context about which actors you’re targeting and what behaviour changes you’re pursuing. The Impact Map provides that context.
Impact Mapping vs Opportunity Solution Trees
Opportunity Solution Trees (OST) have a similar structure: Outcome → Opportunities → Solutions → Experiments. How do they compare?
| Layer | Impact Mapping | OST |
|---|---|---|
| Top | Goal | Outcome |
| Second | Actors | — |
| Third | Impacts | Opportunities |
| Fourth | Deliverables | Solutions |
| Fifth | — | Experiments |
The key difference is emphasis:
Impact Mapping focuses on Actors—ensuring you know who needs to change behaviour. This is particularly valuable for B2B products with complex stakeholder maps (buyers, users, admins, integrators).
OST focuses on Opportunities—customer problems that could move the outcome. The explicit Opportunities layer prevents jumping to solutions.
They’re complementary lenses. Impact Mapping asks “what do we need actors to do differently?” OST asks “what problems are actors experiencing?” Both prevent the feature factory trap of building without understanding.
Where Impact Mapping Shines
B2B Products with Complex Stakeholder Maps
When you’re not just building for “users” but for buyers, end users, administrators, integrators, and internal champions, Impact Mapping’s Actors layer is invaluable.
“We need enterprise admins to complete SSO configuration within 2 hours” is a different impact than “We need end users to adopt SSO login.” Same feature (SSO), different actors, different behaviour changes, different success metrics.
Goal Decomposition and Alignment
When you’re translating a high-level business goal into actionable work, Impact Mapping provides structure. You don’t jump from “increase revenue” to “build feature X.” You trace through actors and impacts, ensuring every deliverable connects to behaviour change that drives the goal.
Stakeholder Conversations
When stakeholders push features, Impact Mapping gives you a framework:
- “What goal does this achieve?”
- “Which actors does it affect?”
- “What behaviour change does it create?”
- “Is that the highest-impact behaviour change for this goal?”
The map creates space for productive discussion rather than feature-request acceptance.
Where Impact Mapping Falls Down
It’s Not Prioritisation
Like OST, Impact Mapping helps you generate and structure deliverables. It doesn’t tell you which deliverable to build first.
A map with 4 actors, 12 impacts, and 30 deliverables doesn’t tell you whether to start with Deliverable A or Deliverable Q. For that, you need RICE , BRICE , or another prioritisation framework.
Impact Mapping generates candidates. Prioritisation filters them.
Maps Can Become Sprawling
The mind-map format encourages expansion. Add another actor. Branch another impact. Brainstorm more deliverables. Soon you have a sprawling diagram that’s comprehensive but not actionable.
Keep maps focused. Prune actors who can’t realistically affect the goal. Limit impacts to the 2-3 behaviour changes that matter most. Constrain deliverables to testable hypotheses.
Requires Research Investment
Good impact maps require understanding your actors—who they are, what motivates them, what behaviour changes are realistic. Without research, you’re guessing, and the map becomes a structured wishlist rather than a validated strategy.
Practical Implementation
Start with one goal. Don’t try to map your entire product. Pick the highest-priority business goal and build its impact map.
Research your actors. Who actually influences this goal? Interview stakeholders, analyse user behaviour, map the buying process. Real actors, not assumed ones.
Focus on behaviour changes, not features. The Impacts layer should describe behaviour: “Complete setup within 2 hours,” not “Use the setup wizard.” Features are deliverables, not impacts.
Brainstorm deliverables without judgment. Generate options, then prune. Not every deliverable is worth building—that’s what prioritisation is for.
Score deliverables with RICE/BRICE. For each deliverable, estimate reach (how many of that actor?), impact (how much behaviour change?), confidence (how sure are we?), and effort. Rank and fund accordingly.
Connect to RoadmapOne. Goals become Objectives. High-priority deliverables become Key Results. Actor context informs how you measure success.
The Bottom Line
Impact Mapping forces the question most roadmaps skip: who are we building for, and what behaviour change do we need from them?
The Actors layer is what makes it unique. By explicitly identifying who affects your goal—users, buyers, champions, approvers, integrators—you avoid the trap of building for a monolithic “user” who doesn’t exist.
Use Impact Mapping during discovery, especially for B2B products with complex stakeholder maps. Trace deliverables back through actors and impacts to goals. Then prioritise with RICE or BRICE and allocate capacity in RoadmapOne.
Always think about the user. Impact Mapping makes that discipline structural, not optional.
References
- Gojko Adzic, Impact Mapping (2012) — The definitive guide
- Gojko Adzic, Specification by Example (2011) — BDD and Given-When-Then origins
- Opportunity Solution Trees — Complementary discovery framework
- OKRs for Product Teams — Connecting goals to measurable results
- BRICE Prioritisation — Prioritising deliverables
- Objective Prioritisation Frameworks — Complete guide to all frameworks