Impact Mapping: An Intro

By Chris Daily

If you're a product owner or product manager, you've probably felt this: you know what you want to build, but you're not entirely sure it's going to move the needle on the thing your business actually cares about. That gap — between "we built the feature" and "the feature did what we needed it to do" — is exactly what impact mapping is for.

I use it constantly, and not just for software.

What an Impact Map Actually Is

An impact map is a visual tool that connects a business goal to the people who can help you reach it, to the behavior changes you need from those people, to the specific features or deliverables that would drive that change.

It's structured as a branching diagram, and it forces you to answer four questions in order: Why are we doing this? Who can help us get there, or get in the way? How do we need their behavior to change? What can we actually build or do to make that happen?

The order matters. Most teams start at "what should we build" and work backward, if they ever ask why at all. Impact mapping forces you to start at why, which is uncomfortable the first time you do it, because it surfaces how many product decisions get made without a clear answer to that question.

How I Build One

Start with the actual goal — not a feature, a goal. Not "add a referral program" but "increase customer lifetime value by X." Be specific enough that you'd know if you hit it.

Then map the actors — everyone whose behavior could move that goal, in either direction. This is where teams usually undercount. It's not just your end user; it's also the people who influence your end user, the internal stakeholders who can accelerate or block you, and sometimes competitors whose behavior changes what you need to do.

Then, for each actor, ask what behavior change would actually move your goal. This is the step most teams skip entirely, and it's the one that makes the map worth building — because "get more signups" isn't a behavior, it's an outcome, and outcomes don't tell you what to build.

Only then do you get to deliverables — the actual features, campaigns, or changes that would drive that specific behavior change in that specific actor.

[YOUR EXAMPLE HERE — a real impact-mapping session you've run, even briefly: what was the goal, what surprised you about who ended up on the actor list, what got cut once the map made the priorities obvious]

When It's Actually Worth Doing

I reach for impact mapping in a few specific situations, and I'd steer you away from treating it as a default for every planning conversation — it's a tool for genuine ambiguity, not routine backlog grooming.

A genuinely new idea, where the team hasn't yet agreed on what "done" looks like or who it's actually for. Impact mapping surfaces disagreement early, when it's cheap to resolve, instead of three sprints in, when it's not.

Misalignment on roles and stakeholders. When a project has enough moving parts that people are quietly operating on different assumptions about who's accountable for what, building the map together — out loud, in the room — does more than any org chart to get everyone looking at the same picture.

A process or system that isn't working, and nobody's quite sure why. Starting from the biggest-impact actors and working down tends to surface the actual bottleneck faster than guessing.

A real decision with more than one viable path. When you're genuinely torn between options, mapping out the actor and behavior-change consequences of each path usually makes the right one obvious — not because the map decides for you, but because it forces the tradeoffs into view instead of staying implicit.

What Makes an Impact Map Actually Useful — Not Just Pretty

Get specific with your goal before you start. A vague goal produces a vague map, and a vague map doesn't help anyone make a decision.

Build it with the people who'll be affected by the outcome, not just the people planning it. The value of impact mapping isn't really the diagram — it's the conversation that happens while you're building it, and that conversation only works if the right people are in the room.

Treat it as a living document, not a one-time artifact. Revisit it as you learn things — impact maps are meant to evolve as your understanding of the problem does, not sit static after the kickoff meeting.

Impact mapping isn't complicated. What it is, is a forcing function — it makes you answer "why" before you answer "what," which is the single most commonly skipped step in product work I've seen in thirty years of doing this.

---

Build the habit of asking why first

Agile + AI for Entrepreneurs covers impact mapping as one of several tools for making sure what you build actually moves the goal you set out to hit.

See the course →