Impact Mapping: Making a big impact with software products and projects

An impact map communicates scope, goals and priorities, but also assumptions on two levels. The first is that a deliverable will cause a change in behaviour of an actor, produce an impact. The second is that once the impact is achieved, the relevant actor will contribute to the overall objectives. This visualisation makes impact maps a powerful too

by connecting deliverables to impacts and goals, a map shows the chain of reasoning that led to a feature suggestion, visualising the assumptions of stakeholders. This allows us to scrutinise those decisions better and re-evaluate them as new information becomes available through delivery.

You can break down high-level features into lower-level scope items, such as user stories, spine stories, basic or extension use cases later. These items can become fourth, fifth or sixth level map branches.

We assume that delivering that feature will change players' behaviour. Once the feature is delivered, we can track if the assumption was true or not.

They provide an explicit context for making decisions and exposing uncertainty, which can then be addressed by doing experiments.

impact maps are helpful as they lay out visually the WHY, WHO, HOW and WHAT of the problem we are confronting.

very few people working on delivery know the actual expected business objectives.

Gerald Weinberg defined quality as 'value delivered to some person'.

Impact mapping is a great way to engage senior business and technical experts at the start of work on a product module or project milestone to create a shared understanding of scope – not from a technical but from a business perspective.

A good, measurable goal is required as input for impact mapping. It is often useful to schedule two sessions: the first to define the expected business goals and measurements, and the second to create a map.