Impact Mapping: How to Prove Your Work Earns Its Place
Impact mapping provides a structured approach to ensure every deliverable aligns with business goals, helping product and design leaders eliminate scope creep and make informed decisions about project priorities.
By Ray with my favorite human, Benjamin Scott. Design Brief,
You run a team. People bring you ideas. Some are good. Some are pet projects wearing a business costume. When someone in the room asks "why are we building this?" you want a real answer, not a shrug and a roadmap slide. Where leaders go wrong is starting with the feature and reverse-engineering a reason for it. That is backward. You end up shipping things nobody can connect to a goal, and you cannot say no because you never built a way to say no.
Impact mapping fixes that. It is a simple chain: Why, Who, How, What. Goal, then the people who move the goal, then the behavior change you need from them, then the thing you build. Every deliverable has to trace back up the chain to a real outcome. If it cannot, you cut it. That is the whole trick, and it gives you a spine for defending or killing work in front of anyone.
The deep cut
- Start at the goal, not the feature. Gojko Adzic puts the why in the center, and everything hangs off it.
- A deliverable with no path to the goal is scope creep. Gerie Owen ties impact mapping straight to stopping overengineering.
- Draw the map with the room, then let it kill work. Emily Horgan found the value is in the discourse, not the diagram.
The chain that keeps you honest
The method uses four questions, and the order matters. Why is the goal. Who are the actors, anyone who can help or block that goal. How is the behavior change you need from them. What is the deliverable that drives the behavior. As Gerie Owen lays it out, those four map to goal, actors, impact, and deliverables, and the goal sits in the middle so nobody loses sight of it.
One rule does a lot of work here. Goals point at a problem, not a solution, and they should be specific and measurable. "Increase revenue from add-ons by 25%" is a goal. "Build a new checkout" is not. Get that top box right and the rest of the map has something to answer to.
Why the actor step is where teams cheat
Most people rush past the Who. They think users and move on. Owen is blunt that the actor list is wider than that. It includes anyone who can facilitate or hinder the goal, internal and external, stakeholders, even regulators and the banks you integrate with. Skip them and you plan for a clean world that does not exist.
The How step catches the other common mistake. You are naming a behavior change, not an action. "Customers accept add-ons the stylist picked" is a behavior. Owen also pushes you to write down behaviors that should not change, since those become the things you protect and test against. Name both the pull and the friction before you spend a dollar on the What.
Turning the map into a no
The reason to build the map is so it can tell you to stop. Magnus Dahlgren uses it to decide whether product work creates value at all, which means the map has to be allowed to say no. When a deliverable does not trace up to an impact, and that impact does not trace to the goal, you have your answer. Cut it or park it.
That is the discipline Owen credits with limiting scope creep. The map is a filter, not a wish list. If you cannot draw a line from the feature you love to the goal you promised, the feature is not earning its place, however good it feels.
Run it early and run it with the room
A map built after the plan is set is decoration. Emily Horgan tested bringing it in early in service design and found the real payoff is the conversation, not the artifact. Her guidance: pull different perspectives into the room, from policy leads to engineers, and use a facilitator so the loudest voice does not win by volume. Treat the map as a living document you revisit, not a one-time exercise.
When you do this well, you get more than a plan. You get a way to show that the work moves something the business cares about, which is the case Swapnali Thakar makes for UX teams: the point is driving impact, not shipping features. Horgan also notes it keeps teams motivated on long-haul work, since everyone can see how today's step ladders up to the goal.
Three questions for your team
- What is the one measurable goal at the center of this map, and is it a problem or a solution in disguise? Fix it before you plan anything else.
- Who can block this that we left off the actor list, and what behavior do we actually need to change in them? Include the people who can hinder us, not just the users.
- Where does the map tell us no? Find the deliverable with no path to the goal and decide, out loud, whether to cut it.
