◀ Course contents Part 2 · Module 2-02

Impact Mapping

Connect what you build to why it matters

Teams waste months shipping features nobody needs. Impact mapping is a simple visual method that prevents this: it forces every feature to trace back, through real people and real behavior changes, to a business goal.

Ready?

1

The Four Pillars

An impact map is a four-level structure that connects a business goal to the things a team might build, in a way that makes every deliverable justify itself.

The levels answer four questions in order. Why — the goal, expressed as a measurable business outcome. Who — the actors whose behaviour would have to change for that goal to be reached. How — the impact: the specific behaviour change you want from each actor. What — the deliverables that might produce that change.

Read as a sentence: to reach this goal, this actor must behave differently, and this thing we could build might cause that. Every deliverable inherits a reason from the branch above it, and that is the entire point.

The other thing it changes is the conversation. Instead of arguing about whether a feature is good — where the most confident person usually wins — you argue about whether the impact is the right one to pursue, which is a question with evidence attached.

The four pillars of an impact map A goal at the top branching into actors, each actor branching into the impact you want from them, and each impact into the deliverables that might create it. Goal · why Actor · who Impact · how their behaviour changes Deliverable · what we build Actor · who Impact · how their behaviour changes Deliverable · what we build
Each level answers one question, and the line entering a box is that box’s reason for existing. Cover the top three rows and the bottom one is just a list of things somebody wanted to build — which is what a roadmap without a map underneath it is.

Everyday example, deciding to get fit

Say your goal is "lose 5kg by summer" (the Why). Who can actually make that happen? Only you (the Who / actor). What do you need to do differently? Eat less sugar and walk daily (the How / impact, a real behavior change). And only then: what tools help you do that? A step-tracker, meal-prep boxes (the What / deliverable). Notice you'd never start by buying gadgets, that's backwards. Impact mapping keeps the same order for products: goal first, gadgets last.

Why

Goal

The business metric you need to move.

Who

Actors

The people who can make the goal succeed or fail.

How

Impact

The behavior change you want to see in those people.

What

Deliverable

The feature or tool you actually ship.

The deliverable with no reason above it

A team's roadmap listed a notification centre. Mapped backwards, nobody could name whose behaviour it was meant to change or which goal that served — it had arrived from a competitor's release notes. Impact mapping did not kill the idea because it was bad; it killed it because the branch above it was empty.

Quick check

You work at Spotify and want to drive subscription growth. What role does a "Share lyrics to Instagram" feature play in the map, and what is its impact?

2

Setting the Goal (the "Why")

Everything below the goal inherits its quality from the goal, so a vague one produces a map where nothing can be ruled out.

Compare that with “improve customer engagement”. One map opened with exactly that, and every deliverable underneath could be justified while none could be excluded — because with no number, any change can be argued to help.

A goal should also describe a business outcome rather than a product output. “Launch the mobile app” is something you do; “raise mobile-originated revenue from 8% to 15%” is something that happens as a result, and it leaves open the possibility that the app is not the best way to get there.

The test worth applying before you go further: could this goal be missed? If there is no result that would count as failure, the map underneath it will be a list of everything anybody wanted to build, arranged in a tree shape.

What a usable goal contains A four-slot template for an impact map goal: an active verb, a measurable metric, a baseline and target, and a deadline. Raise / reduce… an active verb, not "improve" [a metric you collect] measurable today from X to Y baseline and target by [date] a deadline you can miss
Four slots, and the annotation beside each one is the test it has to pass. “Improve customer engagement” fills none of them — no verb you can act on, no number, no baseline, no date — which is precisely why nothing underneath it could ever be ruled out.

Everyday example, New Year's resolutions

"Get fit this year" is the resolution everyone quits by February, it's vague, has no number, and no deadline, so you can never tell if you're winning. "Run a 5k without stopping by June 1st" is the one people actually keep: it's SMART, specific, measurable, and time-bound. Product goals fail the same way. "Improve the product" is a wish; "reduce cart abandonment from 60% to 45% by end of Q3" is a goal you can build toward and check.

How to write a good goal

Start with an active verb, target a number you can measure, and give it a deadline.

"Reduce cart abandonment from 60% to 45% by the end of Q3."

A goal that could not be missed

A map opened with the goal "improve customer engagement". Every deliverable underneath could be justified and none could be ruled out. Rewritten as "raise weekly active accounts from 22% to 30% by Q3", two of the five branches immediately stopped making sense.

Quick check

Which of these is a real goal, rather than a feature request in disguise?

3

Actors and Impacts (the "Who" and "How")

The middle two levels are where impact mapping does its real work, and where most maps go wrong.

An impact is a change in an actor’s behaviour, described in their terms. Not “they use the reporting feature”, which is about your product, but “they check numbers before the Monday meeting instead of asking their team”. Written that way, it becomes obvious that several things could produce it, only one of which is a feature.

Impacts can also be things you want to stop happening, which is easy to forget: an actor filing fewer tickets, or an admin no longer needing to contact sales to add a seat.

The discipline that keeps the level honest: if you cannot describe how you would notice the impact happening, it is not an impact — it is a hope. Behaviour change is observable by definition, and if yours is not observable, it has probably been written as a feature in disguise.

Actors and impacts, done properly Two panels contrasting vague and specific versions. A vague actor like "users" produces impacts nobody can act on; a specific role produces an observable behaviour change. Too vague produces nothing actionable Actor: "users" Impact: "they use the feature" Describes your product Cannot be observed happening Specific produces a deliverable Actor: "the admin who buys seats" Impact: "adds seats without calling sales" Describes their behaviour You can watch it happen
One team mapped a retention goal to “users” and got impacts nobody could act on. Splitting the admin from the analyst gave two different branches, and only one of them touched renewals. The right-hand panel is the test: every line of it is something you could watch happen.

Everyday example, throwing a party

Your goal: "a packed, fun party." Who makes that happen? Your friends (the actors). What do they need to do differently? RSVP yes, actually show up, and bring friends, those are the impacts (real changes in behavior). Sending a nice invite is a deliverable, not an impact, it's just a tool to trigger the RSVP. Beginners constantly mix these up: "made a beautiful invite" feels like progress, but if nobody shows up, the impact never happened. Always ask: what must people actually do, not what did we make?

Actors, the "who"

Never just "the user." Think in specific segments (first-time guest buyers) and secondary players (delivery drivers, support agents).

Impacts, the "how"

A genuine change in what people do, doing something more, less, or differently. Not a click; a habit.

Picking the actor who can actually move

A team mapped a retention goal to "users", which produced impacts nobody could act on. Splitting the actor into the admin who buys the seats and the analyst who uses them produced two different impacts and two very different deliverables — and only the admin's branch touched renewals at all.

Quick check

The actor is a delivery partner and we want food delivered faster. Which of these is a true impact (behavior change) rather than a feature?

4

Aligning Deliverables (the "What")

The finished map is not the deliverable. What it gives you is a way of handling the request that arrives mid-quarter with no reasoning attached.

Every deliverable on the map sits under an impact, which sits under an actor, which sits under the goal. So when a stakeholder asks for something, the question is not “is this a good idea?” — it is “which branch does this belong to?”

That is a much better conversation to have, and notably a less personal one. Nobody’s judgement is being questioned; a structural gap is being pointed at, and the stakeholder can either identify the branch or propose changing the goal.

The map also shows you where you are over-invested. If four deliverables cluster under one impact and another impact has none, you have a distribution of effort that nobody chose deliberately. Most roadmaps have exactly this shape and nobody notices until the branches are drawn.

A request arrives mid-quarter A chooser for handling an unplanned request: trace it up the map. It either belongs to an existing branch, needs a new branch justified against the goal, or has no branch and is not scheduled. Which branch does this request belong to? an existing one Schedule it — the reasoning is already there a new branch Justify the new impact against the goal first none Not scheduled. The goal may be wrong, but say so openly
One stakeholder asked for a chat feature; traced upward, it served an actor nobody had put on the map — the right-hand outcome. The question stopped being whether chat was any good and became which impact it was supposed to produce, which turns out to be a far easier thing to disagree about in a room.

Everyday example, the grocery list

Shopping with a list tied to the meals you're cooking, you buy only what traces back to a dinner. Shopping while hungry with no list, you grab a cart full of snacks that connect to no meal, and half of it rots. Unmapped features are those impulse snacks: they look appealing in the aisle but serve no goal. The impact map is your shopping list. When a stakeholder tosses "let's add an AI chat companion!" in the cart, you kindly trace it back: which behavior change, for which actor, toward which goal? If the line breaks, it's an impulse buy, leave it on the shelf.

The alignment guard

When a stakeholder requests an arbitrary feature ("let's add an AI chat companion!"), trace it backwards: does it trigger a behavior change that serves the goal?

If the trace breaks anywhere, the feature is probably waste, say so, kindly, with the map.

The request that had no branch

A stakeholder asked for a chat feature. Traced upward, it served an actor the team was not targeting and an impact that did not connect to the quarter's goal. The conversation moved from whether the feature was good — it might have been — to which goal it belonged under, and there was not one.

Quick check

Goal: grow active fitness-app users 20%. Actor: casual joggers. Impact: they log runs daily. Which deliverable is tightly aligned with that impact?

Drill what you learned
Scenario 1 easy

An executive asks you to lead an initiative: grow premium subscriptions by 15% this quarter. The team immediately starts pitching feature ideas.

Where should the impact map start?

Scenario 2 easy

Uber wants to cut driver churn by 10%. Your team drafts the map and needs to fill in the Impact column for the actor 'part-time commuter drivers'.

Which entry is a genuine impact?

Scenario 3 easy

Duolingo's goal is +20% daily active users. A senior stakeholder insists on building a multiplayer gaming lounge and wants your support.

How do you evaluate the request with the impact map?

Scenario 4 easy

A teammate writes the goal as: "Launch the new mobile app by Q2."

Why isn't this a valid impact-map goal?

Scenario 5 easy

Goal: reduce support ticket volume by 30%. A PM lists only "end customers" as the actor.

What's missing in the actor thinking?

Scenario 6 medium

In the Impact column, a team writes: "Users click the new 'Invite' button."

Why is this a weak impact?

Scenario 7 medium

Your map has: Goal (grow retention 15%) → Actor (power users) → Impact (they invite colleagues) → Deliverable (a company-wide rebranding project).

What's broken?

Scenario 8 medium

Leadership hands you a strategy where the map has ten actors, each with three impacts, each with several deliverables — 60+ features. Everything is "priority."

How does impact mapping help you prioritize?

Scenario 9 medium

A stakeholder is adamant: "Just trust me, the AI companion feature will be huge. We don't need to map it."

What's the diplomatic impact-mapping response?

Scenario 10 medium

Two deliverables both trace cleanly to the goal. One is a small notification tweak (2 days); the other is a full loyalty-program build (3 months). Both target the same impact.

How should the map inform your choice?

Scenario 11 hard

Three months into building the deliverables on your map, data shows the target impact isn't moving the goal at all — the behavior changed, but retention didn't budge.

What does this reveal about the map?

Scenario 12 hard

Goal: increase marketplace transactions. A junior PM maps only buyers as actors, forgetting sellers entirely.

What's the risk of this omission?

Scenario 13 hard

Someone proposes the impact: "Make users happy."

Why is this a poor impact entry?

Scenario 14 hard

Your finished impact map is beautiful, but a stakeholder asks: "How do we know these behavior changes will actually happen if we ship the deliverables?"

What's the honest answer about what a map is?

Scenario 15 hard

A PM builds the entire map alone at their desk, then presents the finished version to engineering and design as final.

What's the process flaw?

Drilled it. Now apply it to a real situation.

Put it to work
From lesson 1

A roadmap with no why attached to it

A logistics SaaS

The Q3 roadmap has eleven items on it. Each has an owner, an estimate and a ticket. Asked why the third one is on the list, three people give three different answers: because a customer asked, because the CEO mentioned it, and because it unblocks the fourth item.

Nobody can say what would be different for the business if all eleven shipped.

What does an impact map add that this roadmap does not have?

Select all that apply — there are 3 to find.

From lesson 2

Four goals, one usable

A meal-kit business

Four candidate goals for the map. Only one can anchor it.

Order them from best to worst as the goal at the centre of an impact map.

Drag the rows, or use the arrows, then check.

  1. "Cut first-month cancellations from 38% to below 25% by the end of Q3" Best. A number, a baseline, a date, and a business consequence everyone understands. It can be missed, which is what makes the branches beneath it answerable.
  2. "Improve first-month retention" Second. The right subject with nothing to aim at. Every branch will look plausible because no branch can be shown to be insufficient.
  3. "Become the most loved meal-kit brand in the country" Third. Aspiration rather than goal. Nothing beneath it can be traced to it, so the map would be decorative.
  4. "Launch the recipe personalisation engine" Worst. A deliverable wearing a goal's clothes. Put it at the centre and the map's only possible conclusion is that you should build the thing you had already decided to build.
From lesson 3

The actor nobody had on the map

A veterinary practice platform

Goal: raise the share of appointments booked online from 22% to 50% within two quarters. The team's map has one actor — the pet owner — and four deliverables under it.

Two months in, online booking has moved to 24%.

Work out what the map was missing.

  1. Step 1 of 3

    Research finds owners who try to book online are frequently told by the practice to phone instead. What does that reveal about the map?

    Receptionists are an actor. The question is what impact you need from them.

  2. Step 2 of 3

    What is the impact you want from that actor?

    The real blocker was a sync delay between the online diary and the practice management system, so the two genuinely did disagree.

  3. Step 3 of 3

    What deliverable follows from that?

    Goal, actor, impact, deliverable — and the deliverable arrived last, which is the order that stops you building the wrong thing well.

From lesson 4

Cutting the branch you were most attached to

An online bookseller

The map is finished. Goal: raise repeat purchase rate from 19% to 30%. Four branches, each with deliverables. The team has capacity for two.

The four branches, with what is known about each
BranchAssumed mechanismEvidence it worksCost
Personalised recommendationsBetter suggestions → more second ordersNone yetOne quarter
Faster delivery on repeat ordersSpeed → habitStrong: repeat buyers cite deliverySix weeks
Loyalty pointsRewards → return visitsMixed; heavy discounting riskFour weeks
Reading-list remindersPrompt at the right moment → returnSmall test moved 4 pointsThree weeks

Which two branches would you take, and on what basis?

Notification