Impact Mapping: How to Build an Impact Map in 4 Weeks, Step by Step
8 min read ยท 2026-10-11
Impact mapping is a planning method that starts from one business goal and works down four levels. Why is the goal. Who are the people who can help or block it. How is the change in behaviour you need from them. What are the deliverables that could cause that change. The result is a tree diagram that shows why each feature exists, so features that don't connect to the goal are easy to spot and drop.
Gojko Adzic described the method in his 2012 book "Impact Mapping". Teams use it to stop building features just because someone asked for them, and to start from the outcome instead. You can sketch your first impact map in one workshop. Plan on about four weeks to set a clear goal, check your guesses with real users and turn the map into a roadmap your team will follow.
The roadmap at a glance
Goal: Build a validated impact map for one business goal and turn its best branch into a roadmap. Duration: 4 weeks
Set the goal (Days 1 to 3)
Agree on one measurable goal that the whole map will serve.
- Write the goal as a change in a number, with a deadline.
- Check that you can track the number today. If you can't, set up tracking first.
- Ask your sponsor or leadership to confirm this is the goal that matters this quarter.
- Write down what is out of scope, so the map stays focused.
Milestone: One goal sentence, approved by the decision maker, written at the top of the map.
Map the actors (Days 4 to 5)
List everyone whose behaviour can help or block the goal.
- Brainstorm actors with your team: user groups, buyers, partners, support staff, internal teams.
- Split broad groups into specific ones, for example "new trial users" instead of "users".
- Add actors who could block the goal, such as a competitor's sales team or a compliance reviewer.
- Keep the 3 to 5 actors with the most influence on the goal.
- Run the two-hour workshop described below to get a rough draft of all four levels in one session, then refine the impacts and deliverables in Weeks 2 and 3 with real evidence.
Milestone: A short list of named actors, each one specific enough to interview or observe.
Define the impacts (Week 2)
Describe how each actor's behaviour needs to change.
- For each actor, write 2 to 4 impacts as actions: "invites a teammate in the first week", not "likes the product".
- Talk to a few people from each key actor group to check the impacts are realistic.
- Note impacts that would hurt the goal, so you can reduce them.
- Mark which impacts you believe most and which are pure guesses.
Milestone: Every actor has at least two impacts written as observable behaviours.
List the deliverables (Week 3, first half)
Find the smallest pieces of work that could cause each impact.
- For each impact, brainstorm several options: features, emails, content, process changes, training.
- Include options that need no code, like a support script or an onboarding call.
- Write each deliverable as a small, testable item.
- Remove deliverables that don't connect to any impact.
Milestone: A complete four-level map where every deliverable traces back to the goal.
Pick and test a branch (Week 3, second half)
Choose the path with the best chance of moving the goal for the least effort.
- Score each branch on likely impact and effort with your team.
- Pick one or two branches to start with.
- Define how you'll know the impact happened, for example an event in your analytics.
- Run the cheapest test first, such as a prototype, a manual version or a message to a small group.
Milestone: One branch selected, with a test running and a success signal agreed.
Turn the map into a roadmap (Week 4)
Put the chosen work on a timeline and set a date to review the map.
- Move the chosen deliverables into phases on your roadmap, grouped by the impact they target.
- Label each roadmap item with the impact it serves.
- Share the map and the roadmap together so people see the "why" next to the "what".
- Book a review every few weeks to update the map with test results.
Milestone: A shared roadmap where every item links to an impact, plus a review date in the calendar.
What an impact map looks like
An impact map is a tree that reads from left to right, or from top to bottom. The goal sits at the root. Actors branch from the goal, impacts branch from each actor and deliverables branch from each impact. Each level answers one question.
The key idea is that deliverables are options, not commitments. If one doesn't cause the impact, you try another branch. You don't defend a feature just because it's on the plan.
- Why: the business goal. Example: "Raise the share of trial users who become paying customers by the end of June."
- Who: the actors. Example: new trial users, team admins, the customer support team.
- How: the impacts. Example: "Trial users import their own data in the first two days."
- What: the deliverables. Example: a one-click import from a spreadsheet, a short setup video, a support check-in on day two.
A worked example: a habit tracking app
Imagine a small team behind a habit tracking app. Many people sign up, but few come back after the first week. The team writes the goal: "More new users still active on day 30 by the end of next quarter, measured weekly in our analytics."
They list three actors: new users, users who already invited a friend, and the team's own content writer. For new users, the impacts are "sets up a first habit on day one" and "opens the app on three different days in week one". For users who invite friends, the impact is "checks in on a friend's progress". For the content writer, the impact is "publishes beginner guides that answer the questions new users ask most".
Deliverables come last. For "sets up a first habit on day one", the team writes three options: a list of starter habits to pick from, a shorter sign-up form and a welcome email with one clear action. They score the options and start with the starter habits list because it's the smallest. Only then does the item go on the roadmap, labelled with the impact it serves.
How to run an impact mapping workshop
The first draft of an impact map works best as a group session. In the 4-week plan, it takes place during "Map the actors", once the goal is approved. Invite people who see the problem from different angles: product, engineering, design, sales or support, and the person who owns the goal. Keep the group small enough that everyone talks.
Plan about two hours and use a whiteboard, sticky notes or a digital whiteboard such as Miro or FigJam. Work one level at a time and don't jump to features early.
After the workshop, one person cleans up the map and shares it. Treat it as a draft. In Weeks 2 and 3, interviews and tests show which impacts are real, and the map changes with them.
- Start with the goal only. Read out the goal approved in Days 1 to 3 and check that everyone understands the number and the deadline.
- Brainstorm actors in silence for a few minutes, then group the sticky notes.
- Write impacts as verbs. If a note says "better onboarding", ask "what will the user do differently?"
- Add deliverables last, and ask for at least two options per impact.
- End by circling the branches the group wants to test first.
How to turn an impact map into a roadmap
An impact map tells you why to build something. A roadmap tells you when. The two work best side by side. Without the map, the roadmap becomes a list of features. Without the roadmap, the map never gets delivered.
To connect them, use the impacts as roadmap themes. Each phase targets one or two impacts, and each item in that phase is a deliverable from the map. Add a milestone that checks the impact, not just the release. For example, "starter habits list shipped" is a release, while "more new users set up a habit on day one" is the milestone that counts. If you need help with the timeline itself, see our guide on how to make a roadmap.
To decide how often to hold those reviews, read how often you should update your roadmap. For mistakes that happen once the work is on a timeline, see 12 roadmap mistakes to avoid.
- Group roadmap items by impact, not by team.
- Put the cheapest tests in the earliest phase.
- Add a review point after each phase to decide: keep the branch, change it or drop it.
- Remove roadmap items whose impact didn't happen, and say why.
When impact mapping is the right tool
Impact mapping fits best when you have a clear business goal but many possible ways to reach it. It helps when stakeholders keep adding feature requests, when a team ships a lot but the main number doesn't move, or when you start a new quarter and need to choose where to focus.
It's less useful for small, obvious fixes or work with a fixed scope, like a legal requirement with a set deadline. In those cases, a simple task list or a project plan is enough. Our guide on roadmap vs project plan explains the difference. Impact mapping also pairs well with scoring methods: once your map lists the deliverables, you can rank them with RICE, ICE or MoSCoW before you put them on the roadmap.
Common mistakes to avoid
- Starting with a vague goal like "improve engagement". Write a number and a deadline you can actually measure.
- Listing actors that are too broad, such as "customers". Split them into groups whose behaviour differs.
- Writing impacts as feelings or features. Rewrite each one as an action someone can be seen doing.
- Treating every deliverable as a promise. Keep them as options and test the cheapest one first.
- Building the map once and forgetting it. Review it after each test and update the branches.
- Mapping several goals on one map. Build a separate map for each goal.
Frequently asked questions
What are the four levels of an impact map?
The four levels are why, who, how and what. Why is the business goal, who are the actors, how are the changes in their behaviour and what are the deliverables. You always build them in that order, from the goal down.
How is impact mapping different from a product roadmap?
An impact map explains why each piece of work exists and which behaviour it should change. A roadmap places the chosen work on a timeline with phases and milestones. Most teams build the impact map first, then use it to fill and justify the roadmap.
Why does a first draft take 2 hours but the full plan 4 weeks?
The workshop only captures what the team believes today. Most of the 4 weeks goes to checking those beliefs. You talk to real users to confirm the impacts, then run a cheap test on the best branch to see if behaviour actually changes. Only a map that has passed those checks is worth turning into a roadmap.
Can I use impact mapping for personal goals?
Yes. Put your personal goal at the root, then list the people who can help, such as a manager, a mentor or a study partner. Write what you need each of them to do, then list your options. It works well for career moves and learning goals that depend on other people.