Note: I updated this article in December 2023. You can find the updated article on my current newsletter, Outcome Focused, here: https://outcomefocused.substack.com/p/impact-map-your-way-out-of-solution
Escaping Solution-First Development through Impact Mapping
The actual act of writing software is difficult. It requires people who are experts in several techniques and technologies to create a software product that works reliably and looks good. Designers need to know the latest trends and tools, from CSS to Photoshop. Programmers need to be experts in multiple programming languages, frameworks, infrastructural tools, testing methods, and so much more.
Because everyone realizes and acknowledges how difficult creating software is, a huge amount of effort and brain power goes into managing the process of creating this software. Ticket and issue tracking systems keep track of all the work to do on a project. Agile methodologies like Scrum and Kanban try to keep the day-to-day work going smoothly. Scrum masters, agile coaches, and managers ensure the teams developing the software work effectively and with as little distraction as possible.
With these tools, there is a straightforward process — though it’s by no means an easy one—to create working software.
But the most important thing is often missed on the path to creating this software…
The trap of solution-first development
Perhaps due to this complexity in software creation, it is incredibly easy for people in the trenches to forget the purpose of the software they are building: creating value for customers.
When you are not focused on that purpose, you end up caught in the trap of “solution-first development” — creating great solutions before understanding the problem they are supposed to solve. In the best case, software that comes out of this approach will only have some extraneous features but will still solve the underlying problem. More likely, the software will have tons of features, yet won’t solve the problem at all.
Some signs you are building software solution-first:
- Lack of value: You often discover after a feature is released no one uses it or its usage is growing too slow.
- Unreleased software: Features are built and then thrown away before being released.
- Reactive teams: The development team is purely reactive in its tasks.
- Shopping list development: You have a long list of detailed feature-level tasks on your backlog.
- Technical backlog: Your backlog is mostly technical and internally-focused tickets, not user-focused stories.
The way to avoid this trap is, of course, to start with the problem you are tying to solve, and only build the software features that lead directly to that problem’s solution. The simplest, yet most effective, way to do that that I have found is impact mapping.
Impact mapping — reclaiming the initiative
Impact mapping is an incredibly simple mind-mapping technique for visualizing and planning the path to completing a goal.
Impact map structure
Every impact map has a single goal at its root. The goal is a measurable business goal, that answers clearly “why are we doing this?” Good goals are measurable. If a goal is not measurable, how do you know when and if you have achieved it?
Off of the goal are one or more actors. Actors are people or groups that affect (or are affected by) the goal, and answer the questions “who are we doing this for?” or “who could prevent us from doing this?”
Each actor has one or more impacts. An impact answers the questions “how will the actor’s behavior change to achieve this goal?” or “how could this actor prevent the goal?”
Finally, each impact has zero or more deliverables. Each deliverable answers the question “what could we do to accomplish or mitigate the impact?” Deliverables are the actual work that will be done to ultimately achieve the goal.
Creating an impact map
Before you even begin the process of creating a map, you need a goal. An impact map without a clear goal is useless, and will likely cause frustration.
Step 1: Define the goal
The best goals usually have these attributes:
- Actual desired outcome: Describes an outcome the user and business wants to see.
- Measurable: There is a clear and quantitative way to measure if the goal is achieved.
- Time-bound: The goal clearly states the timeframe it is relevant in.
For our example, let’s assume you are building a social network, and the business has decided user growth is the goal the team should focus on. They decide on the following goal:
Goal: 100,000 monthly-active users on our site by December 2015.
Step 2: Hold an impact mapping session
Next, bring together five to eight people in your company who are interested in or affected by achieving this goal. Optimally, these should include a mixture of:
- Developers/designers from the team that will work on the goal’s implementation.
- Domain experts from among the internal stakeholders.
- Relevant managers, for example product managers or development team manager.
Introduce the goal to the group, and write it on a whiteboard.
Now, ask the group “who are we doing this for?” or “who could prevent us from doing this?” Write the answers to these questions on sticky notes and put them on the board. These are your actors.
Next, go one by one through each actor, and ask the group “how will the actor’s behavior change to achieve this goal?” and “how could this actor prevent the goal?” These answers will be the impacts.
Finally, ask which impacts are the most likely to have a positive affect on achieving the goal. Ask the group “what could we do to accomplish or mitigate the impact?” The answers will be your deliverables.
When you are done, you should have an impact map which looks similar to this:
Using your impact map
You can see that the impact map has a single, measurable goal at its root, followed by some actors, followed by impacts, and finally deliverables.
Using an impact map to plan your work is straightforward. First, identify the impact that you believe would have the greatest effect achieving the goal. Next, choose the deliverable beneath that impact that you believe would achieve that impact the fastest.
After the deliverable is completed, stop! Has the goal goal been achieved?
If the goal has not been reached, identify the next impact and repeat. If the goal has been met, then great — you have completed your goal! Time to decide on a new goal to work on.
In our example impact map, let’s imagine that you decide “activity notifications” would have the greatest effect on increasing the monthly-active users count. Since the only deliverable to achieve that impact is “email user when their page is modified,” you should work on that deliverable (see the red highlighted boxes, above). When the notification system is complete, you might have already reached the 100K monthly-active users goal. If so, there is likely no reason to keep working on other deliverables for this goal.
Short aside: impact maps as user stories
One of the interesting things about impact maps is that you can turn any deliverable into a user story pretty mechanically, like so:
As an <ACTOR>, I want <DELIVERABLE>, so that <IMPACT>.
Taking an example from our example impact map, the topmost deliverable could be represented in user story form as:
As a fraud prevention agent, I want a validation interface in the back-office system, so that I have time to validate new users.
Using this method, it is simple to represent the deliverable you are working on in a linear product backlog.
Attaining true value
This iterative process of choosing work ensures that you are not wasting time doing things which do not bring you closer to the business’s goals — and ultimately, to solving the customers’ problems.
“the process itself is a powerful facilitation tool…”
In addition, the map creation process itself is a powerful facilitation tool, bringing together people across the organization — who might not usually interact — to discuss and solve a problem. By making developers part of the discussion from the beginning, their useful insights are brought to light early, and they will be more engaged with solving the problem once they begin working on it directly.
I’ve used impact mapping to plan everything from small one-off personal projects to large multi-million dollar development efforts involving dozens of developers, and I can attest that it can work at any scale.
Impact mapping is not a panacea, but with a little work, impact mapping can be a powerful tool for planning software.
Further reading
While impact mapping is a simple technique, the implications are deep, and there’s much more to explore than what I’ve said here.
If you want to dig deeper into impact mapping, I highly recommend the book Impact Mapping by Gojko Adzic, the creator of the concept.
A great online tool for creating, hosting, and sharing impact maps is MindMup, also by Gojko and his team.
Thanks go to Josh Mauk for his help in reviewing this article.
