Reverse engineering requirements to start your impact map

This is a useful tool that is perfect for product owners and business analysts within agile teams in prioritisation and working on a roadmap. Here is a pretty concise summary taken from the authors website:

An impact map is a visualisation of scope and underlying assumptions, created collaboratively by senior technical and business people. It is a mind-map grown during a discussion facilitated by answering the following four questions:

Why?
The centre of an impact map answers the most important question: Why are we doing this? This is the goal we are trying to achieve.

Who?
The first branch of an impact map provides answers to the following questions: Who can produce the desired effect? Who can obstruct it? Who are the consumers or users of our product? Who will be impacted by it? These are the actors who can influence the outcome.

How?
The second branch level of an impact map sets the actors in the perspective of our business goal. It answers the following questions: How should our actors’ behaviour change? How can they help us to achieve the goal? How can they obstruct or prevent us from succeeding? These are the impacts that we’re trying to create.

What?
Once we have the first three questions answered, we can talk about scope. The third branch level of an impact map answers the following question: What can we do, as an organisation or a delivery team, to support the required impacts? These are the deliverables, software features and organisational activities.

For a business analyst or product owner new to a project sometimes stakeholders start communicating with the what e.g. I want Facebook for our organisation. This is common and nothing new, nor is reverse engineering these requests, however it  can be a good starting point for your impact map.

Once we have the what then we can move on to the how, essentially what impact is this going to have and for who. From there hopefully it will lead you on to why are we doing this with a means (objective) to measure whether this has been met written near by (or if it is really simply have that as your why e.g. 1 million new players.

This is basic stuff, however it asks the essential questions in an easy to digest visual format and immediately highlights where some gaps are for instance why are we doing this.

Impact mapping allows you to focus on the impacts and not the technologies, reminiscent of the design free intentions of user stories. Part of it is a brainstorming tool to allow you to think of alternatives, which is why the author encourages you to involve reps from the business (senior) and technical to get things moving.

Sadly not all ideas are good ideas and Agile doesn’t answer what you should prioritise. What you do have with Agile is a framework that allows for constant inspection and adaptation with the ability to respond to change if something isn’t working. Once you have your impacts mapped you want to highlight where your assumptions are and put them to the test.

Its simplicity leads to its efficiency by representing the business and product strategy (potentially in the form of the Product Vision) and linking them to the what’s. If this isn’t in place, impact mapping can still be a useful tool for highlighting that no matter how many what’s, you need to answer why. You can get the book on Amazon, however the following Youtube video has everything you need to know to get going: