Opening note
This summary draws only from the captured highlights from Gojko Adzic’s book on impact mapping. The highlights focus on how the framework works, how to facilitate it well, and where teams tend to misuse it in planning and delivery.
Core thesis
Impact mapping is a strategic planning technique that visualizes the dynamic relationship between delivery plans and overarching business objectives. It prevents organizations from losing focus by making assumptions explicit and visually connecting deliverables to the desired behavior changes of key actors. By doing so, impact mapping reduces waste, prevents scope creep, aligns technical and business teams, and transforms software delivery from a predefined feature factory into an adaptive, goal-oriented process.
Main ideas / framework
The impact mapping framework works as a visual map of assumptions connecting causes and effects. It is structured around four levels that answer four questions.
Level 1: Why (The Business Goal) The center of the impact map defines the core objective. This goal must focus on the problem to be solved rather than the solution. Good goals are Specific, Measurable, Action-oriented, Realistic, and Timely (SMART). The goal should ultimately translate into clear financial terms, such as saving money, earning money, or protecting money. Without a measurable goal, teams cannot evaluate alternative solutions or determine when to stop investing.
Level 2: Who (The Actors) The first branch of the map identifies the individuals or groups who can influence the outcome. These actors are defined in order of specificity: specific individuals, user personas, roles, or departments. Generic terms like “users” are avoided. Actors include primary actors who directly benefit, secondary actors who provide services, and off-stage actors who have an interest but are not directly involved. The map also identifies actors who might obstruct the goal.
Level 3: How (The Impacts) The second branch defines how the actors’ behaviors should change to help achieve the goal or how they might obstruct it. Impacts focus on changes in behavior or business activities, not software features. Drawing on Anthony Ulwick’s concept of jobs-to-be-done and Robert Brinkerhoff’s focus on desired changes in jobs, these nodes describe how a specific activity will differ from what is currently possible. For example, rather than stating that an actor will sell tickets, the impact would specify that the actor will sell tickets five times faster.
Level 4: What (The Deliverables) The outer branches of the map detail the deliverables, software features, and organizational activities that support the required impacts. Deliverables are treated as options and unproven assumptions, not commitments. Placing deliverables in the context of impacts helps teams break work down into independent chunks, avoid over-investing in low-priority impacts, and discard features that do not contribute to the central goal.
The Facilitation Process Creating an impact map involves structured phases mirroring design thinking principles:
- Preparation: Discover real goals using techniques like the 5-Whys to uncover the underlying financial driver. Define rigorous measurements using Tom Gilb’s framework: scale (what to measure), meter (how to measure it), benchmark (current situation), constraint (minimum acceptable value or break-even point), and target (desired value).
- Mapping: Draw the map skeleton based on a few key ideas. Diverge to find alternative solutions by asking what else actors could do. Converge to identify key priorities using dot-voting, virtual cash allocation, or structured frameworks like the Kano model (must-have, linear, exciters) and the purpose-alignment model (differentiating, parity, partner, who cares). Categorize deliverables into those that earn value immediately and those that fit a defined learning budget to test assumptions.
What stood out in the highlights
The idea of the map as a highway map rather than a destination map stands out. The primary purpose of the impact map is to make connections explicit and identify alternate routes, showing the assumptions that link deliverables to desired impacts. Like closed roads or roads under construction, assumptions on the map may prove to be unworkable or wrong, which means the route has to change.
Another prominent theme is the shift away from feature-centric planning to goal-oriented adaptation. Gary Klein’s research on emergency services demonstrates that people on the ground must know the overarching objective to react correctly to unforeseen problems. This applies directly to software delivery. By focusing on the underlying reason for a project, teams can adapt their scope when original plans encounter reality.
The framework also serves as an antidote to “story card hell,” a state where agile teams manage large backlogs of technical deliverables disconnected from business value. If a proposed user story cannot be traced back to an actor, an impact, and the central goal on the map, it does not belong in the current delivery cycle.
Visual facilitation matters because it externalizes memory and allows groups to compare ideas and discover patterns at the same time. The highlights argue that this creates better discussions than text-heavy requirements models.
Operating lessons
Workshop Composition Effective impact mapping requires the participation of both senior business decision-makers and senior technical experts. The initial goal-setting session should be restricted to five or six key individuals to ensure efficiency. The subsequent mapping session can expand to ten to twenty participants to benefit from divergent thinking. If the appropriate senior personnel are unavailable or uninterested, the workshop should be paused until they can participate.
Physical Space and Facilitation The physical environment dictates the quality of collaboration. Boardrooms with large tables and classroom-style setups stifle interaction. Facilitators should prioritize open spaces, whiteboards, and writable surfaces like static film. During the mapping phase, breaking a large group into smaller sub-groups prevents a single dominant stakeholder from controlling the narrative and facilitates set-based design.
Managing Existing Feature Lists When presented with a pre-existing list of requested features, facilitators should avoid reverse-engineering the entire list into the map. Instead, a few key items from the list should be used to build the map skeleton. The group should then be prompted to generate cheaper, faster, or simpler alternatives to achieve the same impacts. Using an idea-generation grid where participants build on previous suggestions without repeating them forces deeper exploration.
Measurement and Investment Adopt the Palchinsky method principles for dealing with complex real-world problems: seek variation, ensure survivability by keeping failures small, and prioritize selection through feedback loops. Project iterations should be small, ideally representing no more than two percent of the overall investment. Goals must be quantified using precise parameters. Deliverables should either be backed by validated assumptions to earn value or sized to fit within a predefined learning budget to test new assumptions.
Divergent and Convergent Thinking The mapping process must enforce strict boundaries between idea generation and criticism. During the divergent phase, participants must generate as many alternatives as possible without immediate critique. Premature criticism stifles creativity and prevents the discovery of simple, low-hanging-fruit solutions.
Risks and misreadings
A primary risk in strategic planning is adopting iterative delivery mechanics while retaining an upfront, fixed-scope mindset. In this scenario, often termed “Water-Scrum-Fall,” business stakeholders mandate a fixed list of features, defeating the purpose of adaptive planning. Impact mapping mitigates this by requiring deliverables to remain optional assumptions.
Another common pitfall is establishing vague or unmeasurable goals. A goal formulated as “acquire more users” is too loose because the solutions required for a ten percent increase differ from those required for a five hundred percent increase. Without specific targets, the team cannot evaluate feasibility or progress.
Tracking metrics for the sake of tracking, rather than to inform decisions, presents another significant risk. Drawing on James C. Scott’s observations, when metrics are imposed solely for external control rather than internal understanding, they can render a system overly complex and lead to failure. Metrics must be designed specifically to reduce uncertainty regarding the assumptions on the map.
Finally, attempting to use impact mapping for routine maintenance tasks or projects lacking strategic objectives is an operational mismatch. The framework requires strategic goals to function correctly.
Questions to reuse
- Why is this work being done?
- Who can produce the desired effect?
- Who can obstruct the desired effect?
- Who are the consumers or users of the product?
- Who will be impacted by the product?
- How should the actors’ behavior change?
- How can the actors help achieve the goal?
- How can the actors obstruct or prevent success?
- What can the organization or delivery team do to support the required impacts?
- Whose behavior will this change and in what way?
- Why is that behavior change important?
- How valuable is this?
- How much investment makes sense here?
- What delivery timing matters here?
- What is the simplest way to support this activity?
- What other options could work?
- If the assumption is uncertain, what is the simplest way to test it?
- Could the idea be tested without software?
- Could value start with a partly manual process?
- What are the crucial blockers before work even starts?
- Is there a high-value, low-hanging-fruit impact somewhere?
- What are the key assumptions to test?