Skip to main content

Extending Impact Mapping to Gain Better Product Insights

June 12, 2018

Impact Mapping is a powerful technique that helps teams understand how to link the work that they do with results that their organizations would like them to achieve. We’ve been using this technique for a while in our Scaled Professional Scrum and Professional Scrum Product Owner courses, but I have had a growing discomfort with the approach that I couldn’t well articulate until we were using it recently in an Agile Measurement (EBM) Workshop. There seemed to be something missing in the usual Goal-Actors-Impact-Deliverables chain (see Figure 1).

Figure 1: A “classic” Impact Map Example (for a ride sharing service)

 

The thing that we discovered was missing was the outcome that the “actor” is looking to achieve. The “impact” is what we would like to achieve, but in order to achieve that result, we need to help our customer achieve some outcome that they desire.

As long as we were going to tweak the Impact Map, I also wanted to better align with the User Experience (UX) modeling terminology that we’ve been using to talk about users and customers and the outcomes they are looking to achieve, so we changed the term Actor to Persona, and we changed the word Deliverable to PBIs, short for Product Backlog Items (PBIs), which is the term with which the organization’s Scrum Teams are familiar. And we added Outcomes (see Figure 2).

Figure 2: Extended Impact Map

 

In this extended Impact Map, we show the Customer Outcomes that people matching the Persona need to achieve in order for our organization to achieve the Business Impact. Furthermore, we show which PBIs we believe that, when we deliver them, will produce the Customer Outcome for the Persona.

As part of the workshop, but not shown on the Extended Impact Map, we also identified the measurements that would tell us whether the outcomes and the impacts had been achieved. This was important because it forced us to make the outcomes and impacts concrete - if we could not measure whether we had achieved them, then we really did not have enough insight to start working on the associated PBIs. Being forced to decide how we were going to measure  stimulated interesting discussions about the outcomes and impacts, and helped us to come up with better PBIs.

Business stakeholders often complain that they can’t connect work that teams are doing with the things they want to achieve. Adding Personas and Customer Outcomes also helped the Scrum Teams better understand the people who would use the product, and why. The Extended Impact Map provided a useful way to show how goals are linked to PBIs, and helped foster better discussions about those goals and how better to achieve them.

 

 


What did you think about this post?