Want to Get the Most Bang for Your Buck? Try Impact Mapping

Work is humming along nicely when your Marketing VP stops by your desk and says, “We need to double monthly sales.”

That’s it. That their entire instruction.

After you recover from this bombshell,  you will need to decide what tool you will use and who you will grab to help you start to tackle this problem.

Do you use Story Maps? (A great tool when you have an idea of where you’re going.)
A Journey Map? (Also requires that you have an idea of where you’re going.)
A Traditional Roadmap?

I’m going to suggest that you create Impact Maps in situations like this, where you have a vague goal but haven’t yet done a good exploration of how to get there.

Impact Mapping is a strategic tool to help teams and businesses focus their work on a product feature that will give the most bang for their buck. I’ve used Impact Maps for teams seeking to figure out what/where to build next, and I’ve also used them outside of software development.

Many organizations struggle trying to use Traditional Roadmaps in an Agile environment. They don’t work because there is an implied linear flow and promised timeline for delivery. Linear plans of this nature aren’t suitable in our current world, where change can happen at a rapid pace and history often isn’t a predictable indicator (e.g. COVID, or when once-in-a-hundred-year floods occurs twice in three years). Impact Maps replace Roadmaps, making it clear that we have choices in deliverables, while still achieving the original goal.

As humans, we tend to jump from a goal to the actions that we think will help us achieve it. Impacting Mapping works by forcing us to consider who is involved in achieving our goal and how they can help us. Using this approach, we find a broader set of possible options –including some that we might not have considered– before narrowing down on which option is most likely to help achieve our goal.

How to Use Impact Maps

Identify the Goal first, then Who (Actor), How (Impact), and What (Deliverable).[1]

Why are we doing this? What are we attempting to achieve?
The map will be focused on finding options or ways of accomplishing that objective.

Actor/Who

Who are the consumers or users of our product? Who can produce the desired effect toward our Goal? Who can obstruct it?
In describing the Who or the “Actor”, the order of preferred usage is: specific individual, persona, role, job title, group/department – from most specific to least specific. Consider users of the system first, stakeholders second. By focusing on specific people or personas, it makes it more likely the deliverable will meet a real person’s need.

Impact/How

What Impact can the Actor have? How can they help achieve our Goal? How can they obstruct progress towards the Goal?
These are the Impacts that we’re trying to create or prevent. Don’t list everything an Actor might do – just the key things. List business activities, not process features. Be specific and consider negative outcomes as well as positive. When used in an Agile environment, the Impact/How can be tied back to the value statement in a User Story. Check to ensure that both are aligned.

Deliverable/What

What can we do as a team to deliver the Goal?
These become the product features. These Deliverables are the least important end of the spectrum and, on the first pass, will be unrefined. Much of software development is done when someone powerful wants a feature because they think it’s a good idea, but they haven’t really proven the idea will deliver value. By placing Deliverables after the Impact, wasted resources are avoided. So evolution here is a good thing. We don’t need to find all the Deliverables, just enough to find a deliverable that will, for lower cost, deliver the highest Impact. If an early attempt at delivering value fails, we can always return to the map with new information and try again.

Example of an Impact Map:

Figure 2 – Creative Commons 4.0 as per: https://www.impactmapping.org/drawing.html. Credit: http://impactmapping.org/

Tips for Drawing an Impact Map

Impact Maps are intended to be drawn and not just written in words. Visualizing them helps make conversations more concrete. It makes it easier to understand the relationship between a deliverable and the Actor who it is for. If you’re not yet familiar with them, creating an Impact Map from scratch can be intimidating, but it doesn’t have to be. This simple process helps move you through it, and often works well when done over two separate sessions by a collaborative group that includes Product Owner, development team, and stakeholders:

Session One: define expected business Goals and measurements
Session Two: build the map

Session One: This is the preparation session.

1. Identify the core business objective. Do this by listing possible business Goals, and discussing which one is the current priority.
Goals often tie back to money (how to save money, make money, or protect money). However,  Goals may tie back to other tangible benefits such as number of readers for a book; improvement in the team’s morale, etc. All of these are measurable in a meaningful way and, if achieved, would make a positive difference in their context. To find real Goals, ask: Why is this feature important? Or: How would it be useful? Keep iterating until you find the underlying Goal. [2]

2. Define good measurements.[3]

• • what we’ll measure (aka the ‘scale’)
  • how we’ll measure it (aka the ‘meter’)
  • what the current situation is (aka the ‘benchmark’)
  • the minimum acceptable value (e.g. the break-even point)
  • for investment (aka the ‘constraint’)
  • and the desired value (aka the ‘target’)

3. Plan the first milestone. Effectively, you’re picking a Goal/target combination.

Session Two: This is the mapping session.

1. Draw the map skeleton. Start with one Actor (Who), Impact (How), and Deliverable (What). Use tools that promotes collaboration – whiteboard, sticky notes, etc.

• • Put the milestone (Goal/target combination) in the center.
  • Find the Actors who could have a positive or negative effect on the milestone.
  • If people already have ideas or features, put them around the outside. Then ask some questions: Does the feature contribute towards the Goal? Is the Impact valid for the Actor it is ascribed to? Gojko offers a user story-like technique for testing: “<someone> can help us achieve our <objective> by doing <something differently>”

Then we ask ourselves: What “Impact” can the Actor have? Or: How can the Actor help us?

What Deliverable could we build to achieve this?

2. Find alternatives. What else could these people do for us? Who else can help? Who can obstruct?
If you find that you’re struggling, try Hohmann Innovation Games[4] or Gray Gamestorming[5]. Also try asking which of the following factors to consider: New Business, Upsell, Retainment, Operational Efficiency[6]

3. Identify key priorities. Look for obstructions. What can stop us before we start? Is there high-value, low-hanging fruit? What key assumptions should be tested?
These questions should all be focused on business activities, impacts, and outcomes, not software features.

Alternative: Prioritization. Select which Actor to satisfy first.
Consider modified dot voting (red dots for critical features, green dots for low hanging fruit). Given the limited number of options, you can use a Kano model[7] to categorize more effectively.  The Actor with the fewest red dots gets prioritized.

4. Earn or learn. Set a budget to learn whether or not a Deliverable will have the expected Impact. Use simple tools (often not software) to test the value or assumption. The sample questions will be very similar to those used in Lean Startup.

• • What is the simplest way to support this work?
  • What alternatives are there?
  • What is the simplest way to test this assumption?
  • Could we start earning money with a manual process?

If you’re struggling to find testable slices, try story mapping or Gojko’s Hamburger method.[8]

Fit the Measures to the Map

Risks

The map becomes the target and we risk missing things that matter outside the picture.

Typical mistakes

• Too many people involved in creating the map – too large a group will reduce the diversity of the opinions and ideas shared, as the quieter people are drowned out
• Wrong people (e.g. no decision makers, no technical people)
• Projector or one person doing the drawing. Impact Mapping is a collaborative technique. If you meet in person, consider using sticky notes or index cards and move items around on a table. In a virtual context, consider an electronic whiteboarding tool that invites contributions from everyone versus a tool that only one person can update.
• Early criticism (we want more ideas while still in the divergent phase[9] , not an attempt to prune)
• Leaders with outsized influence (leaders should always speak last)
• Reverse engineering of the entire shopping list. Your existing list of preferred Deliverables may not map well to Actors/Impacts.
• Drilling down to detail too early
• Skipping levels in the Goal, Actor, Impact, Deliverable layout
• Building a map without metrics to guide

Impact Mapping and User Stories

Many Agile Teams use User Stories as dumping ground for ideas, such as when someone has a technical need or a pet feature that they would like to see delivered. They express the idea in the format “As a <role>, I want <to do> so that <value>” and dump it the Product Backlog. Impact Maps can be used to keep these User Stories honest. If the User Story doesn’t map to a branch of the Impact that we’re prioritizing, then it can be dumped.

Summary

Impact Maps work well because they maintain a visual connection between the Goal, the Actor, and the Action (Impact + Deliverable). They can be used to generate a new list of features/requirements/ideas, or to prune an existing list by focusing only on the features that support the Goal.

Impact Mapping ensures that when we discuss a piece of work, it always remains in context of our overall Goal, and it can also help us see that there are many paths to it.

Never implement the whole map – instead, run experiments to see which path will get you to the Goal the soonest/with the least amount of effort.

Finally, you can use Impact Maps for more than just product development work; they also help when undertaking organizational change.

Impact Mapping – Glossary and Additional References