Impact Mapping: Connecting Features to Business Goals
How to run an impact mapping session with Gojko Adzic's method: goal, actors, impacts, deliverables, and how to avoid choosing features before the problem.
What is it, and where does it come from?
Impact mapping was created by Gojko Adzic and documented in his book Impact Mapping: Making a Big Impact with Software Products and Projects, published in October 2012. Impactmapping.org presents it as a lightweight, collaborative planning technique for teams that want to make a big impact with software products, and says maps usually take the form of a mind map or a hierarchical outline.
Its main contribution is order. It starts with why, then who, then how behavior should change, and finally what gets built. That sequence forces the team to justify every feature with a concrete impact.
Why does this matter for a junior designer?
Because in many teams features get decided in a meeting without anyone asking why they exist. An impact map gives you a way to ask that question without it sounding like criticism: “what impact do you want this screen to have, and who has to change for that to happen?”
The map also helps you design better. If you know the key actor is an administrator and not the end user, the screen you design changes completely.
What are the levels of the map?
The map has four levels, which draft.io and TechTarget describe as four questions:
- Why (goal). The business goal, framed as a SMART goal (specific, measurable, achievable, relevant, time-bound). TechTarget insists it should focus on a problem, not a solution.
- Who (actors). The people who can influence the goal, helping or hindering it, internal or external. According to TechTarget, be as specific as possible when defining them.
- How (impacts). How each actor’s behavior should change for the goal to move forward. These are behavior changes, not features. TechTarget adds that you include both the behaviors that should change and those that should not, and both positive and negative impacts.
- What (deliverables). The product features or organizational activities needed to produce those impacts.
How do you run it, step by step?
- Write the goal in one sentence. For example, “reduce subscription cancellations in the first quarter”. If the goal is a feature, rephrase it as a problem.
- Invite the right people. According to draft.io, limit the session to five or six people, with technical experts and business owners who have real decision-making power. TechTarget adds representatives from development, testing, and UX.
- Identify the actors. Who uses the product, who administers it, who funds it, who can block it.
- Describe the impacts. For each actor, what behavior change do you need? “The administrator reviews billing every week” is an impact. “Add a dashboard” is not.
- Propose deliverables last. Only once actors and impacts are clear, ask what would be built to produce each change.
- Prioritize and review. Choose where to start, and set time aside to revisit the map when the context changes.
Draft.io warns that criticizing ideas too early can kill a normally productive discussion, and recommends leaving room for ideation in the first phase and evaluating afterward.
What makes it useful compared with a feature list?
A feature list says what will be built. An impact map says why, for whom, and what needs to change. When a feature is not connected to any impact, it is a candidate to be left out of the plan.
It also helps you see negative impacts. According to TechTarget, spotting them early leaves more time for risk mitigation, and behaviors that should not change translate into negative test cases. Feature lists almost never record this.
When is impact mapping NOT the right choice?
- Without a clear business goal. The map fills with actors and deliverables with no direction.
- As a substitute for validation with users. If the expected impact is not obvious, validate it with research.
- When the business has no decision power in the room. A map with participants who have no authority produces agreements nobody keeps.
- For goals that change every week. The map needs a reasonable horizon to be useful.
To see how a goal becomes concrete actions, the article on the opportunity solution tree offers a complementary logic, focused on the customer.
Example
Illustrative example: a team wants to reduce cancellations in a subscription app.
- Goal: reduce cancellations in the first quarter.
- Actors: the person who signs up, the one who uses the service every day, and the support team.
- Impacts: the subscriber understands what the plan includes before paying; the user easily finds the pause option; support gets fewer billing questions.
- Deliverables (last): a plan summary screen, a pause option in settings, and an advance billing notice.
The map shows that the pause deliverable is the only one that targets a direct user impact. The other two reach the goal another way, and the team decides which to build first.
To measure whether the change lands, the article on KPIs helps you choose metrics that reflect impact, not just delivery. To plan when each deliverable goes in, the design roadmap is a useful frame.
Common mistakes
- Framing the goal as a solution instead of a problem.
- Leaving actors vague or inviting people with no decision power.
- Detailing deliverables before actors and impacts are settled.
- Forgetting negative impacts and behaviors that must not change.
- Using the map as a feature list with arrows.
- Repeating the map every quarter without checking whether the impacts are still valid.
Sources
- Impactmapping.org, Impact Mapping and the book
- draft.io, Impact mapping
- TechTarget, How to apply impact mapping to software, with examples