• en | es

Impact Mapping

We had the pleasure to visit a client who asked us to facilitate a workshop. The aim was to create a plan for their investors in order to release the next round of funding for a social media website. They had a product backlog that was full of of features but they were not sure how to prioritise them. They also had a release roadmap but were unclear as to why certain things needed to be done.

We decided to run the workshop using Impact Mapping. The aim of impact mapping is to create a mind-map which has the business goal at the very centre followed by the stakeholders (actors) that will help/hinder the achievement of this goal (who). The following branch then addresses the behaviours of these actors that will impact the goal (how) and finally the features that we need to deliver to help support these behaviours (what).

Goal

First of all we asked them to decide on the goal. They came up with a couple:

  1. Achieve target user base.
  2. Increase revenue.

We asked them to concentrate on one goal for now. They very quickly agreed that achieving the target user base is the key goal and that the revenues will come once they have good market penetration.

Who?

Once the goal was agreed we asked them to come up with the actors. This took a while. There were some obvious ones like the users, moderators etc. However, they also wanted to include people like advertisers - we challenged that because they were thinking of advertisers in terms of people who will advertise on their platform. This did not directly relate to the goal. However advertisers where we would advertise to gain more users did actually make it to the list. Looking at everything with the goal in mind was already helping us to focus our plan.

How?

The next step was to see what these actors could do to help or hinder us in achieving our goal. The difficult part was to get people to think about behaviours they would like to impact rather than the features in the product. Initially people kept thinking from the point-of-view of the features. We didn’t stop them but asked them to articulate exactly what behaviour they are looking to support with this feature and how that behaviour will help them towards the goal.

Initially these behaviours were quite granular but after a few passes we could collapse them into a smaller set - describing them at a level we were comfortable with. We found it quite strange that the behaviours we were looking to encourage were listed along side the behaviours we were trying to discourage. An example of the later was “Posting of inappropriate content”. This however made good sense when we got to the next phase in the exercise because they resulted in distinct features.

In some cases we found a lot of interdependencies or duplication between behaviours. Although interdependencies were discussed we did not represent them in our mind-map. As for the duplication we realised that these behaviours superficially looked the same but may actually result is very different features in context of different actors. Therefore duplication at this level was not a problem.

What?

Understanding how to support the behaviours is the final part of this exercise. This was surprisingly easy because a lot of thinking had already gone into this while we where trying to understand the how part. We had to iterate a few times to ensure that we were defining these features at the right level. Although most of the features discovered here were already in the original backlog, everyone found it very useful to be able to trace every single feature back to the original goal. This allowed us to de-prioritise all the features from the original backlog that were not directly aligned with the goal.

Conclusion

The resulting mind-map made it very easy to reason about the features and their place in the release roadmap. The client was very happy that they can now be clear about each feature and provide a strong argument if investors ask for feature which do not align to the original goal.

Impact mapping is a very useful tool to help focus on the business goal. Having a visual map of features that can be traced back to the actual goal provides a great way to reason and prioritise the backlog and plan the release roadmap.

About the author

Mash is a pragmatic software craftsman always looking to improve his software creation skills and helping others do the same. He firmly believes that a well-rounded software craftsman must have a keen interest in all aspects of software creation, including; process, people, technology, user experience, development, operation, maintenance, and social impact. He relishes the daily challenges that Codurance brings to him–stretching his existing knowledge and expertise allowing him to constantly grow as a professional.

Mash is an advisor and a leader. During his diverse career, he has succeeded in invigorating large ailing software projects as well as creating highly effective software teams and departments. His broad and deep technical knowledge, organisational skills, craft focus, and empathy to people involved have been integral to his success. He has worked in many roles for charities, investment banks, consultancies, government, media and cloud providers. He prides himself at being a hands-on software developer and believes that software development skills are very hard to learn and the best way to maintain them is to apply them.

Subscribe to newsletter