“Impact Mapping” is only 73 pages long but quality definitely rules over quantity in the case of this book by software delivery consultant Gojko Adzic. Too often we run the risk of diving into a software project or a product backlog without taking a step back to wonder “WHY?” or “HOW?”. If this sounds even remotely familiar to you, I would strongly recommend you have a read through “Impact Mapping”.

Impact Mapping is all about collaborative strategic planning around software projects. The book provides an abundance of practical tools to help you map your product roadmap or project plan, thinking about the business goals you’re looking to achieve and the specific assumptions that you’re looking to test. You thus create a clear mapping between goals and deliverables which helps at all levels, whether you’re planning a project, making a business case or need to choose between priorities.

In “Impact Mapping” Gojko Adzic makes a convincing case for how impact maps can help solve common problems around software implementation (see Fig. 1 below) and it does so by outlining 4 straightforward elements:

• Why? – The centre of an Impact Map should answer the most important question: “Why are we doing this?” This is all about the business goal or vision which a company is trying to achieve. Gojko stresses that goals shouldn’t be about solutions or the scope of the product that you’re looking to build. Instead, the goal should be the problem that you’re looking to solve (see also my earlier blog post about design thinking and creating problem statements).
• Who? – This level of the Impact Map is all about the actors whose behaviour you’d like to impact. Who are your target audience? What kind of value are they looking to gain from your product? In the book Gojko distinguishes between primary and secondary actors. Primary actors tend to be those whose goals are fulfilled and secondary actors are those who provide services. 
• How? – The next level of the Impact Map combines the business goal (‘Why?’) with the actors (‘Who?’). The main questions here are: “How should our actors’ behaviour change?” and “How can they help us achieve our goal(s)?”
• What? – The ‘What?’ is about the deliverables or outcomes which can support the required impacts (‘How?’). These deliverables should be treated as independent chunks with each having tangible business value. When you do an Impact Map, you don’t necessarily have to describe the deliverables in great detail. Gojko explains that these deliverables can be treated as options and that only the high-level deliverables need to be listed in the Impact Map.

The result of these steps will be an Impact Map, a sample of which I’ve included in Fig. 2 below. Throughout the book I came across a lot more useful nuggets of information, some of which I’ll list here:

1. Defining quality – In the section on “defining quality” Gojko makes an interesting point about the changed purpose of testing: “The role of testing becomes to prove that deliverables support desired actor behaviours, instead of comparing software features to technical expectations.” In other words, the focus of acceptance testing is much more about testing that the desired impact has been achieved.
2. Roadmap management – I’m constantly learning about how to best think about and use product (portfolio) roadmaps. Too often I see long ‘shopping lists’ of features with a pre-determined scope – more often than not these roadmaps will evolve and so will the features on it. It was therefore interesting to read about the two prerequisites for Impact Maps to be used for roadmap management: (1) agreement that your aim is to achieve business goals, not to deliver pre-set scope and (2) frequent, iterative releases to measure progress.
3. Iterative, not incremental – It might seem like a more semantic point but Gojko points out that a common way teams fail with iterative delivery is to incrementally deliver pieces that only bring value when they come together at the end. However, the main purpose of iterative delivery is to provide value (and shippable software) on a continuous basis (you might want to have a look at a great blog post that Jeff Patton wrote on this topic). Impact Maps can help top break deliverables down into branches that contribute to individual impacts.
4. Divergent and convergent design thinking – Within Design Thinking there are roughly 2 phases: a “divergent” phase where teams will generate options to explore and a “convergent” phase where teams will decide which options are worth pursuing further. You can use Impact Maps at each stage, for instance to capture insights from product discovery activities (divergent) or to test the assumptions behind product ideas (convergent).
5. Typical mapping mistakes – Finally, I found it helpful that Gojko illustrated some typical mistakes when it comes to impact mapping. For example, there is the “jumper” who tends to jump over levels in the map, the “astronaut” who just maps goals (and fails to include good metrics) and the “shopper” who goes into much detail too early on.

Main learning point: “Impact Mapping” is a very succinct and handy guide to planning and managing projects or product roadmaps. The iterative approach which the book advocates can be easily applied to a range of products and projects. This goal-oriented and data driven approaches forces people to think more about the “WHY” and “HOW” which is something that sometimes tends to get missed out on when planning projects or making product decisions.

Fig. 1 – Common software implementation problems which impact mapping can resolve (from “Impact Mapping” by Gojko Adzic, p. 20 – 21) 

• Scope creep – Because there’s a clear mapping from deliverables to goals, we can measure when the main objective is reached and stop working on it.
• Wrong solutions – Because an impact map puts software deliverables in the context of business goals, it’s trivially easy to spot solutions looking for a problem, or those that would contribute to a different business objective.
• Pet features – Impact Maps allow us to quickly spot suggested features that don’t support any of the desired features, or do not contribute to the overall goal.
• Wrong assumptions – Impact Maps clearly show assumptions that we can track and validate them.
• Ad-hoc prioritisation – Impact Maps put features in the context of behaviour impacts, allowing stakeholders to relate better to benefits they would get from features and make much better prioritisation decisions.

Fig. 2 – Sample Impact Map (taken from: http://www.simplicityitself.com/training/impactmapping)

Related links for further learning:

1. http://strategyn.com/outcome-driven-innovation/
2. http://www.ims-productivity.com/user/custom/journal/2007/autumn/IMSaut07pg38-43.pdf
3. http://scottberkun.com/blog/
4. http://en.wikipedia.org/wiki/Goal-oriented_Requirements_Language
5. http://www.agileproductdesign.com/blog/dont_know_what_i_want.html
6. http://designingforgrowthbook.com/