Impact Mapping: Goal-Driven Strategic Planning

Created by Gojko Adzic (building on InUse effect mapping) - https://www.impactmapping.org/book_credit.html

Overview

Impact mapping is a strategic planning technique that connects what a team builds to why it is building it. The community site that Gojko Adzic's consultancy runs describes it as "a lightweight, collaborative planning technique for teams that want to make a big impact with software products" (impactmapping.org). Adzic set the method out in his book Impact Mapping: Making a big impact with software products and projects, published on 1 October 2012. An impact map is a mind map with four levels: a business goal at the center, the actors who can affect that goal, the impacts, meaning the changes in those actors' behavior that would move the goal, and the deliverables that could support those changes.

Each level answers one question. In the book, an impact map is "a mind-map grown during a discussion facilitated by answering the following four questions: WHY? WHO? HOW? WHAT?" (Impact Mapping book sample). The site's Drawing impact maps page spells each one out. The goal answers "Why are we doing this?" The actors answer "Who can produce the desired effect? Who can obstruct it? Who are the consumers or users of our product? Who will be impacted by it?" The impacts answer "How should our actors' behaviour change? How can they help us to achieve the goal? How can they obstruct or prevent us from succeeding?" The deliverables answer "What can we do, as an organisation or a delivery team, to support the required impacts?"

Adzic is open that the ideas are not all his. In the book's credits section he calls impact mapping "a variant of the InUse effect mapping method, introduced by Mijo Balic and Ingrid Domingues (Ottersten)", combined with Robert O. Brinkerhoff's impact maps for training organisations, Chris Matts's feature injection, and Tom Gilb's ideas on measurability and iterative delivery (Giving credit where credit is due). He first called his version "effect mapping", then renamed it after attendees at his conference talks in Sweden complained that he was presenting effect mapping wrongly. Craig Larman suggested the name "impact maps". Adzic's own method summary on Votito traces the Swedish line back to "Goal Cards" described in 2002, which evolved into "Effect Maps" in 2006.

The map's main job is to make assumptions visible. According to the impactmapping.org overview, an impact map communicates assumptions on two levels: that a deliverable will change an actor's behavior, and that the changed behavior will contribute to the overall objective. Tom Poppendieck's foreword to the book puts it more bluntly: an impact map "is a map of assumptions connecting causes and effects" (Foreword). Once a deliverable ships, the team can measure whether the behavior actually changed and whether the goal moved, then decide whether to keep working on that branch or move to another.

That framing changes how scope is treated. Adzic's guidance in the book sample is to "Treat deliverables as options" and he calls the deliverables "the least important level of an impact map". Because every feature sits under an impact and a goal, a proposed feature with no impact above it has no justification on the map, which is how the technique pushes back on scope creep and pet features. The Drawing impact maps page describes plans without that mapping as "shopping lists of features, without any context why such things are important."

The intended users are product managers, business sponsors and senior technical leaders working with iterative delivery (impactmapping.org). The site's facilitation guide describes three uses: setting a vision for a new milestone, focusing delivery when many stakeholders have competing priorities, and reframing a problem when objectives are unclear. Each use calls for different participants and a different level of detail, which is why the skills below treat goal setting, actor discovery, impact definition, deliverables, facilitation, roadmapping and experiments as separate practices.

Core Principles

Start from the goal

The center of the map is the reason for the work, and everything else hangs from it. Adzic writes that the purpose of a goal definition "is to allow the delivery organisation and business sponsors to re-evaluate the plan as new information becomes available" (book sample). He also says goals "should present the problem to be solved, not the solution." A goal that names a product or a feature has skipped the question the map exists to answer.

Name specific actors

Actors are the people whose behavior can help or block the goal, including people who never touch the product. Adzic advises avoiding generic terms such as "users" and defining actors, in order of preference, as a specific individual, a user persona, a role or job title, or a group or department (book sample). He cites Alistair Cockburn's three types: primary actors whose goals are fulfilled, secondary actors who provide services, and off-stage actors such as regulators. Naming a specific group makes it possible to ask how that group's behavior should change.

Describe impacts as changes in behavior

An impact is a change in what an actor does, stated so that someone could observe it. The book's guidance is that "Impacts are not product features" and that an impact should "show a change in actor behaviour, not just the behaviour", with the example of "selling tickets five times faster" instead of "selling tickets" (book sample). Adzic's later Votito summary adds that impacts should ideally be "objective, externally observable and measurable quickly after the work is delivered." Hindering impacts belong on the map too.

Treat deliverables as options

The deliverable level lists things the team could do, and the team may deliver only some of them. Adzic tells teams not to make this level complete at the start and to refine it iteratively during delivery (book sample). He also points out that some impacts can be supported without building software at all. Keeping deliverables provisional lets the team drop work as soon as an impact is achieved or proves to be the wrong bet.

Make assumptions testable

Each path from deliverable to goal is a pair of assumptions that can be checked (impactmapping.org overview). Writing impacts as measurable behavior changes is what makes them checkable, because the team can look for the change after release. The overview page says the role of testing becomes "proving that deliverables support desired actor behaviours", and that a deliverable which does not support an impact is a failure even if it works technically. A map whose impacts cannot be observed cannot be tested, and the team loses the method's main feedback loop.

Build the map together

An impact map is created "collaboratively by senior technical and business people" (Drawing impact maps). The overview page credits the method's origin in an interaction design agency for making it good at engaging people from different backgrounds, including delivery experts and business users. A map drawn by one person records that person's assumptions. A map drawn in the room exposes the places where people's assumptions differ, which is the conversation the team most needs to have.

Steps

1. Discover the real goal Find out why the initiative exists before anyone talks about features. Adzic observes in the book sample that business goals often exist "only at the back of senior stakeholders' minds" and are defined vaguely when they are written down. For vision work, the facilitation guide suggests the facilitator bring a draft goal that stakeholders can refine and challenge. If the goal names a solution, ask what that solution would achieve until you reach a business problem. For commercial products, Adzic suggests goals with an obvious link to money.

2. Define how the goal will be measured Agree how everyone will know the goal has moved and by roughly how much. Adzic's book lists SMART as "Specific, Measurable, Action-oriented, Realistic and Timely" and tells readers not to worry about nailing the goal to a single number (book sample). Ranges work well: his Votito summary suggests stating an expected level of value such as a band of cost reduction when comparing several goals. How much measurement to insist on depends on the purpose; the facilitation guide says detailed goal metrics are necessary when reframing a problem but optional when setting a vision.

3. Scope one milestone Aim the map at the next milestone. The site's examples each cover a single milestone with one main business goal, such as increasing mobile advertising revenue for a music site. If stakeholders bring several goals, Adzic's Votito summary recommends a separate map for each. A single milestone keeps the map small enough to prioritize and to measure within a planning horizon people care about.

4. Map actors and impacts Branch from the goal to the actors, then from each actor to the behavior changes that would help or hinder the goal. Use the four actor questions and three impact questions from the Drawing impact maps page as prompts, and push for specific actors. When the purpose is setting a vision, the facilitation guide advises focusing the discussion on actor impacts and avoiding deliverables in the first workshop. When participants propose features, ask which behavior the feature is meant to change and record the behavior.

5. Find alternatives For the most important impacts, look for several different ways to cause the behavior change before settling on any one. Include options that are not software, such as process changes or campaigns, since the book sample notes it is sometimes cheaper to support an activity without building anything. Adzic's summary also describes slicing: a deliverable that achieves a small part of the impact for a subgroup of actors can still show the direction is right (Votito). Keep deliverables high level; detail belongs later, in user stories or other lower-level items.

6. Pick priorities from the goal down Choose the actors and impacts that matter most first, and only then the deliverables beneath them. The impactmapping.org home page says to "Prioritise from the goals down to impacts." In the site's music example, the team lists impacts for the most promising actor first, and if those impacts achieve the goal it does not need to deliver anything for the other actors (example maps). Attach a target to each chosen impact so the team will know when that branch is done.

7. Deliver, measure and re-plan Ship the smallest deliverable that could produce the chosen impact, then measure the actor's behavior and the goal. The impactmapping.org overview describes re-evaluating the strategy once a deliverable ships: keep working on that branch or shift to another part of the map. Adzic's Votito summary adds that once an impact's target metric is achieved, the team can move to another part of the map. Revisit the map at each milestone, remove branches that were disproved, and start a new map when the goal changes.

When to Use

• A delivery team receives a shopping list of features from a client or sponsor with no stated objective. The facilitation guide names this as a typical case for using a map to set a vision before scope is agreed.
• An initiative already under way has a backlog of epics nobody can rank, or the team finds it hard to stop work that did not pay off. Linking each epic to an impact gives a reason to rank it and a signal for when to stop.
• Several stakeholders with competing priorities share one team. A map built with all of them in the room shows which impacts each person cares about and forces an explicit choice among them.
• A project has stalled or its objectives are unclear, and one person holds most of the business knowledge. The facilitation guide describes collecting that knowledge in small meetings and presenting it back as maps so stakeholders can decide.
• For a product manager planning a new milestone where the behavior of users, partners or internal teams is uncertain, the map turns those uncertainties into named assumptions the team can test during delivery.

When Not to Use

• Day-to-day work tracking and backlog management. Adzic's Votito summary says impact maps intentionally carry little detail about deliverables and are not useful for that job; pair them with a story map or another backlog tool.
• Work whose outcome is fixed and whose solution is fully mandated, such as a compliance change with a prescribed implementation. With no choice among deliverables, the map has little to decide.
• Small, well-understood fixes where the link from change to goal is obvious to everyone. The time spent building a map would exceed the value of the conversation.
• Situations where leadership will not name any goal for the work. The map needs a stated reason at its center; if no one can agree on even a draft goal, the next step is the goal conversation itself, which the facilitation guide treats as a separate problem-reframing exercise.

Impact Maps and Related Tools

Impact maps sit in a family of goal-to-solution visualizations. The table compares it with its predecessor and two tools product teams often weigh against it.

Adzic's own comparison says impact maps and Opportunity Solution Trees overlap significantly, but impact maps "require strict impact descriptions that are ideally measurable through behaviour changes", which makes them more directly useful for measuring progress, while a tree is more flexible for breaking complex opportunities into sub-opportunities (Votito). The same page notes that an Opportunity Solution Tree lists assumptions and their tests explicitly, where in an impact map they are implicit in the links between levels.