Impact mapping, traced.
Also called: Impact map · Outcome-to-deliverable map · Goal-impact tree · Effect mapping
Mapping a goal to the actors who can affect it, the behaviour changes you want, and the deliverables that might cause them.
Start from the outcome, not the feature list. Name the goal, the actors who move it, the behaviour changes you want, then the deliverables that might cause those changes. Every build choice now traces back to an outcome, and the ones that don’t get cut.
What impact mapping is
An impact map is a chain of four links, read left to right. Goal: the measurable outcome you actually want. Actors: the people who can help or block that outcome. Impacts: the behaviour changes you need from those actors. Deliverables: the things you might build or do to cause those behaviour changes. The discipline is the order. You start at the goal and only reach a feature at the very end, as a candidate cause, never as a given.
That ordering is the whole point. A feature wishlist starts at the deliverable (“it should have an app”) and works backwards, hoping the outcome turns up. An impact map starts at the outcome and works forwards, so every deliverable on the page can be challenged with one question: which behaviour change does this cause, for which actor, toward which goal? If a feature can’t answer that chain, it doesn’t belong on the map, and that is usually the most useful thing the map tells you.
Why the chain matters
- It makes scope auditable. Every deliverable traces back through an impact and an actor to the goal. Break any link and the deliverable has no business being built.
- It surfaces the actors you forgot. Goals don’t move themselves; people move them. Mapping actors first stops you building for a user who was never going to change their behaviour anyway.
- It demotes features to hypotheses. A deliverable is a guess about what causes an impact. Naming it as a guess, not a commitment, makes it cheap to drop when the chain doesn’t hold.
How a goal becomes a build choice
The clearest way to see the chain is to fill it in for one real goal. Here is the proofing box’s map, the one we ran in the pilot, so you can follow each link rather than read a generic template. Notice the bottom row: naming what you won’t build is part of the map, not an afterthought.
Read any deliverable back up the chain and it has to land on the goal. The ceramic-and-wood finish causes “display-worthy” for the gift-buyer, which serves the 500-unit goal. The app fails the same test: no actor needed it to change behaviour, so it never earned a row.
The shift the map forces
The same project, framed two ways. The left is how teams usually arrive: a list of things to build. The right is what the map produces: a chain that ends at an outcome.
- “It should have an app.”
- “Add a few temperature presets.”
- “Maybe Wi-Fi, for later.”
- “Three sizes at launch.”
- Goal: 500 units at £149 in year one.
- Actor: the baker who needs to trust it unattended.
- Impact: they set it once and walk away.
- Deliverable: tight control plus a one-knob interface.
Each wishlist item is an orphan: it names a thing with no actor and no behaviour change behind it, so nobody can say whether it earns its cost. Each map item carries its justification with it. That is the difference between a backlog you defend by taste and one you defend by logic.
How it fits the bigger picture
Impact mapping is activity 03.01 in the framework, near the front of Stage 03 Innovate. It takes the value goals named back in Discover and turns them into a structured set of candidate deliverables. What it produces next is a messy pile of impacts and ideas, which is exactly what the affinity diagram (03.02) exists to cluster and make sense of.
What it can do
It gives every later stage a traceable reason for each deliverable. When Define, Design, or Engineer ask “why are we building this?”, the answer is on the map: this deliverable causes that impact, for that actor, toward that goal. It also makes cutting features painless, because an orphan with no chain behind it is obviously safe to drop.
What it can’t do
It can’t tell you whether a deliverable will actually cause its impact; that is a hypothesis the later evaluation and prototyping stages have to test. The map is a structured set of bets about cause and effect, not proof of them. It also can’t set the goal for you; that comes from the value-goals work upstream.
See the full 10-stage process →
Try it yourself
Take one value goal and write it at the top of a page. List the actors who can move it, including the ones who can block it. For each actor, name the single behaviour change you want. Only then list deliverables that might cause each change. Read every deliverable back up the chain to the goal. Anything that can’t make the trip goes in a dated backlog, not the build.
Want a guided first pass? The Free Sprint frames your goal and audience for you, which is most of the top of an impact map already. Start the Free Sprint →
Your impact-map checklist
Project notes: the app that never reached the map
▸ From the notebook · optional reading
Mapping impacts with Dan and Anna Hartley in Stockport, and watching three “obvious” features fall off the page because no actor needed them.
3 min read · click to open
Dan and Anna arrived at Innovate with a list. An app, three sizes, a couple of temperature presets, maybe Wi-Fi later. A normal feature wishlist. I drew four columns on the whiteboard instead: goal, actors, impacts, deliverables. “Let’s not list features yet. Let’s start at the top and see what survives the walk down.”
Working down the chain
The goal was already tight from Discover: sell 500 units at £149 in year one on a no-app promise. So we listed the actors. The serious home baker in a cold Stockport kitchen. The Sourdough School audience whose recommendation moves sales. The gift-buyer shopping for a baker they love.
Then the impacts. The baker had to trust the box overnight, unattended. The School had to feel comfortable recommending it. The gift-buyer needed it to look display-worthy enough to hand over wrapped.
Where the wishlist died
Now we asked of each feature: which impact does this cause, for which actor? The app was first up. Dan was fond of it. But the baker’s wanted behaviour was “set it once and walk away”, and an app asks them to pair, charge and check a phone. The School’s recommendation got harder with an account and a privacy policy attached. The gift-buyer didn’t care. Three actors, zero behaviour changes that ran through an app. It never earned a deliverable row.
We worked the same test on the rest. Wi-Fi: no actor needed it, parked. Three sizes at launch: the gift-buyer wanted one beautiful object, not a range, and the second ceramic tool wasn’t funded; parked to V2. Temperature presets: the baker proves at one temperature, so a second preset caused no behaviour change anyone wanted. Gone.
What was left mapped cleanly: tight ±0.5°C control and a one-knob interface caused the baker’s trust; the ceramic-and-wood finish caused the gift-buyer’s “display-worthy”; the clean no-account story caused the School’s comfort. Four deliverables, every one traceable to the 500-unit goal. The wishlist had been four orphans dressed as a plan.
— Innovate stage, project notes, 2026
— Next in Innovate → Affinity diagram