Impact Mapping: A Complete Guide to Outcome-Driven Roadmaps

Impact mapping is a collaborative, visual planning technique that connects what you build to the outcomes you actually want by mapping four layers: the goal (Why), the actors (Who), the impacts (How their behavior must change), and the deliverables (What you build). Created by Gojko Adzic in his 2012 book Impact Mapping, it replaces feature-list roadmaps with assumption-driven outcome trees — so teams stop shipping features nobody uses and start changing user behavior in measurable ways.

If your roadmap is a list of features with dates next to them, you do not have a strategy — you have a backlog. Impact mapping fixes that by forcing every deliverable to earn its place by pointing back to a measurable goal and a specific behavior change in a real person.

Why feature-list roadmaps fail

Most roadmaps optimize for output (shipping features) instead of outcomes (changing behavior). The data on this is sobering:

• In the Standish Group's CHAOS research presented at XP 2002, 64% of software features were rarely or never used (45% never, 19% rarely).
• A later analysis by Pendo across hundreds of products found the problem had grown: 80% of features were rarely or never used.
• CB Insights reports that roughly 35% of startups fail because there was no market need for what they built.

Every one of those unused features consumed roadmap slots, engineering time, and maintenance cost. As product leader Josh Seiden puts it, an outcome is "a change in human behavior that drives business results." A feature that does not change behavior is not a result — it is just inventory.

What an impact map actually is

An impact map is a mind-map with exactly four levels, each answering one question:

1. Why? — The Goal. A single, measurable business objective. Not "launch the mobile app," but "increase weekly active users from 40% to 55% by Q3." The goal is the center of the map.
2. Who? — The Actors. The people who can produce the desired effect or get in the way: customers, user segments, internal teams, partners. Impact maps make you name them specifically instead of designing for an average user who does not exist.
3. How? — The Impacts. The behavior changes you want from each actor. How should they act differently? What should they do more, less, or for the first time? This is the heart of the method and the layer teams most often skip.
4. What? — The Deliverables. The features, content, or activities you could build to support an impact. Crucially, deliverables are the last thing you decide — and many of them will be discarded.

"Impact mapping is a strategic planning technique that prevents organisations from getting lost while building products and delivering projects." — Gojko Adzic, creator of impact mapping

The power is in the structure: because deliverables hang off impacts, which hang off actors, which hang off one goal, you can instantly see which features are "solutions looking for a problem." If a deliverable does not trace cleanly up to a behavior change and a goal, you cut it.

How to build an impact map, step by step

1. Write one measurable goal. Make it specific and time-bound. If you cannot measure it, you cannot tell whether the work succeeded.
2. Brainstorm the actors. List everyone whose behavior affects the goal — primary users, secondary users, economic buyers, even internal blockers.
3. Define the impacts per actor. For each actor, ask: what do we want them to do differently? Phrase impacts as behavior changes ("renew without contacting support," "invite a teammate in week one"), not features.
4. Map deliverables to impacts. Only now do you list things you could build. Expect several candidate deliverables per impact.
5. Prioritize a path, not the whole tree. Pick the shortest path through the map that you believe will hit the goal. Treat it as a hypothesis — the rest of the tree is your option pool for when the assumption proves wrong.
6. Annotate assumptions. Every branch is a bet: "we assume this actor matters," "we assume this behavior moves the metric." Make those bets explicit so you know what to validate.

Impact mapping vs. related frameworks

• OKRs tell you the goal and the metric, but not who must change or what to build. An impact map is the connective tissue between an objective and its key results.
• The opportunity solution tree maps opportunities (customer needs) to solutions. Impact mapping maps behavior changes to deliverables. They are complementary — many teams use impact mapping for strategic framing and an opportunity solution tree for discovery execution.
• User story mapping organizes the what into a release plan. Impact mapping decides whether those stories deserve to exist at all.

The missing ingredient: evidence about your actors

Impact maps are only as good as the assumptions inside them. The two layers that most often go wrong — who the actors really are, and which behavior changes are actually achievable — are exactly the layers you cannot fill in from a conference room. They require evidence from real people.

Traditionally that meant weeks of recruiting, scheduling, and manually moderating interviews before you could even start mapping. Most teams skip it and guess instead — which is precisely how you end up in the 64-80% unused-feature statistic above.

The modern approach: filling your impact map with AI-powered research

This is where Koji changes the economics of impact mapping. Instead of guessing at actors and impacts, you validate them with real customer conversations — at a speed that fits inside a planning cycle.

• Identify and validate actors with AI-moderated interviews. Koji runs AI-moderated interviews in voice or text, 24/7, so you can talk to dozens of customers in days instead of weeks. Patterns in who actually drives your goal emerge fast — often revealing actors you would never have listed.
• Pressure-test impacts with structured questions. Koji is the only platform that embeds structured questions — six types: open_ended, scale, single_choice, multiple_choice, ranking, and yes_no — directly inside a natural conversation. Use a ranking question to see which behavior changes customers actually care about, a scale question to size how likely a change is, and conversational follow-up to capture the "why" behind every number.
• Turn transcripts into impacts automatically. Koji's automatic thematic analysis clusters what customers say into themes, so the "How?" layer of your map is grounded in evidence rather than opinion.
• Move at planning speed. Because analysis is automated and reporting is real-time, teams using AI-assisted research routinely cut time-to-insight dramatically — turning a multi-week research dependency into a same-week input to your impact map. You do not need a PhD in research methods to do it.

In short: impact mapping tells you which assumptions matter; Koji lets you test them before you bet a quarter of engineering on them.

Common impact-mapping mistakes

• Treating the map as a feature list. If your impacts are nouns (features) instead of verbs (behavior changes), you have built a disguised backlog.
• Mapping the whole tree as committed work. The tree is an option pool. Commit to one path; keep the rest as alternatives.
• Skipping actors. Designing for "the user" produces vague impacts. Name segments specifically.
• Never validating assumptions. An unvalidated impact map is a confident guess. Pair it with real research.

A worked example

Suppose your goal is to lift 90-day retention from 60% to 75% by year end. Instead of jumping to features, the impact map forces a sequence:

• Goal (Why): raise 90-day retention from 60% to 75%.
• Actors (Who): new admins, invited team members, and the billing owner.
• Impacts (How): new admins reach their first success milestone in week one; invited members log in within 48 hours; billing owners see value before the first invoice.
• Deliverables (What): a guided setup checklist, an invite reminder sequence, an in-product value recap — plus a dozen other candidates you deliberately leave unbuilt.

The strategic conversation now changes. Rather than debating which features to build, the team debates which behavior change most moves retention, then picks the cheapest deliverable that might cause it. If the data later shows invited members are not the bottleneck, you prune that branch and follow another — without re-litigating the entire roadmap.

When to revisit your impact map

An impact map is a living hypothesis, not a one-time artifact. Revisit it whenever a key assumption is validated or invalidated, when a metric moves unexpectedly, or at the start of each planning cycle. The branches you pruned are not waste — they are your pre-vetted backlog of alternatives for when reality disagrees with your first bet. This is also where a continuous research cadence pays off: a steady stream of customer evidence keeps the actors and impacts on your map honest over time.

Frequently asked questions

Who created impact mapping? Gojko Adzic, in his 2012 book Impact Mapping: Making a Big Impact with Software Products and Projects.

What are the four levels of an impact map? Why (goal), Who (actors), How (impacts/behavior changes), and What (deliverables).

Is impact mapping the same as a roadmap? No — it is the reasoning behind a roadmap. An impact map shows why each item exists; a roadmap shows when it ships.

Related Resources

• Opportunity Solution Trees — map customer opportunities to solutions during discovery
• Structured Questions in AI Interviews — the six question types that quantify which impacts matter
• Research-Driven Roadmap Prioritization — turn validated impacts into a sequenced plan
• Outcome-Driven Innovation (ODI) — measure desired outcomes with precision
• Jobs to Be Done Framework — understand the progress customers are trying to make
• Continuous Discovery — keep your assumptions validated every week