Speaking Engineering: Disambiguation Frameworks for Business Owners
Module 5 of 7 Beginner 20 min

Starting With Why — Impact Mapping for Goal-Driven Decisions

Prerequisites: When Everyone Means Something Different — Why Disambiguation Matters

What You'll Learn

  • Describe the four levels of an impact map and what question each level answers.
  • Create a simple impact map for a business goal you own.
  • Use an impact map to challenge a feature request by asking which actor's behavior it changes and which goal that serves.
  • Explain why impact mapping and user story mapping are peer tools — not one a prerequisite of the other — and when you might run them in different orders.
  • Articulate how impact mapping resolves the ambiguity of "why are we building this?" by making the goal-to-deliverable chain visible and shared.

Why This Matters

This framework resolves the ambiguity of why we are building this by making the chain from business goal to actor to behavior change to deliverable visible and shared.

If you have ever sat in a meeting where a feature was added to the plan because a senior stakeholder "just knew" it was needed, you have experienced what impact mapping is designed to prevent. Features accumulate. Backlogs grow. Timelines slip. And six months later, nobody can quite explain why the team spent three weeks building a policy comparison tool that nobody uses. The goal got lost somewhere between the boardroom and the sprint planning session.

Impact mapping gives you a structured way to keep the goal in sight at every step. It is useful not just for product teams — it works for any initiative where someone needs to make a decision about what to build, change, or stop doing. Internal process redesign, a regulatory compliance program, a marketing campaign: if you have a goal and people whose behavior needs to shift to reach it, you can draw an impact map.

Core Concept

Impact mapping (a mind-map structured around four levels — Goal, Actor, Impact, Deliverable — that traces every feature back to a business goal) was introduced by Gojko Adzic in 2012. The core insight is simple: if you cannot trace a piece of work back through a behavior change to a business goal, you should question whether it belongs in your plan at all.

The map has four levels, each answering a different question.

Goal answers: Why are we doing this? It is a specific, measurable business outcome — not a project milestone or a delivery target. "Launch the new small business insurance product" is a project milestone. "Reach 1,000 small business policyholders in 12 months" is a goal. Notice the difference: the first tells you what to ship; the second tells you what success looks like in the real world.

Actor answers: Who must change their behavior for this goal to happen? An actor (in impact mapping: any person or group whose behavior must change for the business goal to be achieved) is not just the end user. It is any person or group who can move the needle on the goal — positively or negatively. For a product launch goal, actors might include your sales team, your customers, and your underwriting analysts. Each one plays a different role, and naming them explicitly prevents blind spots.

Impact answers: How must that actor's behavior change? An impact (in impact mapping: the specific behavior change expected of an actor that will move the needle on the goal) is not a feature — it is the shift in what someone actually does. "Sales agents submit complete applications on the first attempt" is a behavior change. "Build an application wizard" is not — that is a deliverable. The distinction matters enormously: your team can build the wizard without the behavior change happening; the impact is what you actually need.

Deliverable answers: What are we building to enable that change? A deliverable (in impact mapping: the feature, activity, or change that enables an actor's behavior to shift) is what your team produces — software, a process change, a training program. It lives at the outer edge of the map, connected to a specific impact on a specific actor that serves a specific goal.

The map branches outward: the goal sits at the center, actors branch out from it, impacts branch from each actor, and deliverables branch from each impact. In practice you draw it as a mind map — concentric rings radiating outward — or as a nested tree. The structure is less important than the discipline of connecting every deliverable to an impact to an actor to the goal.

Two properties of impact maps are worth holding onto. First, scope is explicit: anything that does not connect to the goal is out of scope. You do not argue about whether a feature is in or out — you ask whether it appears on the map. This gives every scope conversation a neutral reference point. Second, the map is a living hypothesis, not a contract. You are making your best guess about which impacts will move the goal and which deliverables will produce those impacts. You will be wrong about some of them. Discovering mid-project that an assumed impact does not occur is a win — it means you can stop spending time on deliverables that would not have helped anyway. Treat the map as something to test, not something to execute against.

Concrete Example

Let's walk through how Meridian Insurance might build an impact map for their new small business property insurance product.

The product director has a goal: "Reach 1,000 small business policyholders in 12 months." That is the center of the map.

From the goal, we branch to actors. Three groups whose behavior matters most:

  • Small business owners (the primary buyers)
  • Sales agents (the people brokering the relationship)
  • Underwriting analysts (the people who assess and approve applications)

Now we ask: what behavior change do we need from each actor?

  • Small business owners: "Self-qualify by comparing policy options before talking to an agent." If they can do this, Sales spends less time on tire-kickers and more time on serious buyers.
  • Sales agents: "Submit complete applications without back-and-forth with Underwriting." This one is important: remember from Module 01 that the word "approval" means different things to Sales and to Underwriting. The real blocker for Sales is not the approval decision itself but the repeated requests for missing information that delay it. The impact makes that explicit.
  • Underwriting analysts: "Review applications that arrive with complete risk data upfront." They are currently receiving incomplete submissions and chasing information manually.

From each impact, we branch to deliverables. The key ones:

  • For "Sales agents submit complete applications": a guided application wizard that surfaces Underwriting's required fields at submission time — not after the fact.
  • For "Small business owners self-qualify": a policy comparison page on the public website.
  • For "Underwriting analysts review complete applications": automated completeness validation that flags missing fields before a submission reaches them.

Now a stakeholder suggests adding a "policy comparison feature" with rich filtering and side-by-side comparison charts. Let's walk it through the map. Which actor's behavior does it change? It might help small business owners self-qualify — but does a richer comparison chart change how many of them actually submit an application, or does it just make the existing self-selection experience nicer? The team cannot answer that confidently. The deliverable is inconclusive on its mapped impact. It goes below the scope line — not because it is a bad idea, but because the connection to the goal is not clear enough to justify prioritizing it over the application wizard.

This is impact mapping's disambiguation power in practice. The question is never "is this a good feature?" The question is "which actor's behavior does this change, and which goal does that serve?"

Analogy

Think of building a product like planning a road trip. The goal is your destination — "reach San Francisco in three days." Actors are the passengers, each with different roles: the driver, the navigator, the person managing the budget. Impacts are how each person's behavior contributes to arriving on time — the navigator plans an efficient route, the budget manager books hotels in advance. Deliverables are the tools that enable those behaviors — a GPS app, a booking website.

Without this chain, you end up adding things that feel useful but do not actually help you reach the destination. Nicer cup holders are a deliverable. But if you cannot trace them back to a behavior change that helps someone arrive in San Francisco, they are out of scope — no matter how nice they are.

The impact map is the chain connecting destination to behavior to tool. When anyone asks "why are we building this?", the answer is on the map.

Going Deeper

Impact mapping sits at the same level as user story mapping — they are peer disambiguation frameworks, not a hierarchy where one feeds into the other.

Impact mapping answers: what should we build and why — which actors, which behavior changes, which deliverables connect to our goal?

User story mapping (a visual, two-dimensional grid that organises user activities horizontally and details vertically to preserve the user journey while enabling release planning) answers: how does the user experience this, and in what order do we build it?

Neither is a hard prerequisite of the other. You do not have to do impact mapping before user story mapping. Many teams run user story mapping first when they already know their goal but need to organise the delivery journey. Others use impact mapping first when the goal itself is unclear — which is the more common situation when a project is just starting. In Module 06 you will see user story mapping in action; in Module 07 you will see when to use which.

Impact mapping also has a relationship to scope that deserves explicit attention. The map does not tell you which deliverables are worth building in which order — that is where user story mapping and release planning take over. What the map does is define the boundary of relevant work. Any deliverable that does not appear on the map — that cannot be connected to a goal through an actor and an impact — is a candidate for deferral or removal. This is the scope boundary in its clearest form: not a constraint imposed by the budget, but a logical consequence of having stated your goal.

One more nuance: the actors on an impact map are not always users. In a regulatory compliance initiative, a key actor might be an auditor whose review behavior needs to change ("auditors can verify compliance documentation without requesting additional evidence"). In a marketing campaign, an actor might be a journalist whose coverage behavior matters. Gojko Adzic's technique is agnostic to the domain — the four-level structure works anywhere you have a goal and people whose behavior stands between you and it.

Common Misconceptions

"Impact mapping is just a fancier way of writing user stories."

Impact mapping sits upstream of user stories. It answers why before you get to what. User stories describe what a user needs to do; impact mapping asks whether doing that thing will actually move a business goal. If a user story cannot be traced to an impact on an actor on your map, the honest question is whether it should exist in the backlog at all. The two tools are complementary, not equivalent.

"Once I create an impact map, it is fixed and I execute against it."

This framing makes impact mapping feel like a contract — it is not. Impact maps are explicitly designed to be revisable hypotheses. Every deliverable you add to the map is a bet: "we believe this deliverable will produce this impact on this actor." Some bets will be wrong. Discovering mid-project that a particular impact is not occurring — that Sales agents are still back-and-forthing with Underwriting despite the wizard — is valuable information. You update the map, you reprioritize, you stop building things that are not working. Treating the map as fixed defeats the purpose.

"Impact mapping is only for product teams building software."

The four-level structure works for any goal-driven initiative. Meridian's Claims team redesigning their settlement process, a finance team reducing invoice processing time, a compliance officer rolling out a new regulatory program — all of these have a goal, actors whose behavior must change, impacts those changes need to produce, and deliverables to enable them. The technique is agnostic to whether the deliverable is software, a process change, or a training program.

Check Your Understanding

  1. A colleague proposes adding a mobile app to the plan for a new internal reporting tool. How would you use an impact map to evaluate whether that proposal belongs in scope?

    Reveal answer Ask the four-level question chain: Which actor's behavior does a mobile app change? How does that behavior change connect to an impact already on the map? And which goal does that impact serve? If the mobile app enables a specific actor — say, a field operations manager — to review reports in real time rather than waiting for end-of-day emails, and that behavior change connects to a goal like "reduce decision lag in field operations by 50%," it belongs on the map. If the connection is vague or the actor and impact are not already on the map, the proposal should either be declined or sent back to the goal conversation before it enters the plan.

  2. Why does the impact level matter more than the deliverable level when a project hits trouble mid-stream?

    Reveal answer Deliverables are what you build; impacts are what you need to happen. If a project is behind or over budget, cutting deliverables is the obvious move — but cutting the wrong ones eliminates the behavior changes that the goal depends on. When you can see the impact map, you can ask: "If we cut this deliverable, does the impact still have another path to occur?" Sometimes it does. Sometimes the impact has only one deliverable supporting it, making that deliverable non-negotiable. The impact level is where you make triage decisions, not the deliverable level.

  3. Meridian's Sales team and Underwriting team both want to be listed as the primary actor on the impact map. Why does actor selection matter, and how would you decide?

    Reveal answer Actor selection determines which behavior changes go on the map and therefore which deliverables get prioritized. If Sales agents are the primary actor for the "submit complete applications" impact, deliverables focus on what Sales needs — a guided wizard. If Underwriting analysts are the primary actor for the same impact, deliverables might focus on automated validation rules on the Underwriting side. The goal decides: if the bottleneck to reaching 1,000 policyholders is Sales submission quality, Sales is the primary actor. If the bottleneck is Underwriting's review speed, Underwriting is. You resolve actor disputes by returning to the goal and asking which behavior change, if it happened, would most move the needle.

  4. A team has been running user story mapping sessions and building their backlog for three weeks before anyone draws an impact map. Is it too late to use impact mapping? What does it add at this stage?

    Reveal answer It is not too late — impact mapping is not exclusively a planning-phase tool. Running it mid-project surfaces something valuable: you can audit the existing backlog by asking, for each story, "which impact does this support, on which actor, toward which goal?" Stories that cannot be mapped reveal scope drift — work that was added because it seemed useful but was never connected to the goal. This audit often frees up significant capacity. The discomfort of a mid-project impact mapping session is usually worth it.

  5. What is the difference between an impact and a deliverable, and why does that distinction matter in practice?

    Reveal answer An impact is a behavior change — something a specific actor does differently as a result of your work. A deliverable is what your team produces to enable that behavior change. The distinction matters because you can build a deliverable without the impact occurring. A guided application wizard (deliverable) exists in the system regardless of whether Sales agents actually use it to submit complete applications (impact). When you measure progress against deliverables, you can ship everything on the plan and still miss the goal. When you measure against impacts — "are Sales agents submitting complete applications at a higher rate?" — you learn whether you are actually moving toward the goal.

Key Takeaways

  • An impact map has four levels — Goal, Actor, Impact, Deliverable — each answering a different question: why, who, how, and what. Every deliverable must trace back through all four levels.
  • The disambiguation power of impact mapping is scope: anything that cannot be connected to the goal through an actor and a behavior change is out of scope, making the boundary of relevant work explicit and shared.
  • An impact map is a living hypothesis, not a contract. Discovering that an assumed impact does not occur is a win — it means you can stop spending time on deliverables that would not have helped.
  • Impact mapping and user story mapping are peer tools. You do not have to run one before the other; the right starting point depends on what question is currently most unanswered.
  • Impact mapping works beyond software: any goal-driven initiative — internal process change, compliance program, marketing campaign — can use the four-level structure to connect decisions to outcomes.

References