Shifting from Feature Requests to Outcomes: Reverse Impact Mapping
A practical guide using Reverse Impact Mapping to drive conversations from Outputs toward Outcomes and Business Impact
Many Product Managers I talk to would love to get directed by problems to solve and measure their progress in Outcome metrics. However, their reality often looks completely different. They get approached by their boss, colleagues, customers, and maybe even their mom with feature requests. Everybody has ideas, hears ideas, and wants to solve problems, so they go to the responsible PM and drop their solution.
We can change this. As every experienced product person knows, building the first idea that comes to mind rarely creates value and is always more complicated than what people initially expect. Since we can’t develop and support every idea, we must make smart decisions to drive the right business results.
An Impact Map is an excellent model to capture the connection between what we build and what business impact we expect.
Again, what’s an Impact Map?
I’ve written about Impact Maps before1, so let’s keep this short.
It is a visual method to answer and connect these questions:
Why are we doing this? (Business Impact)2
Who is influencing the Impact? (Actor)
How can they influence? (Outcome)
What can we do to support this? (Output)
A regular Impact Map looks like this
As you can see on the Impact Map, the Output (aka Feature request) is the last step of the process, and the method starts with defining the Business Impact.
However, when people approach with a solution in mind, trying to shift the conversation to the Business Impact often doesn’t work. This big abstract step is just too disconnected to land well.
So, how does this method help if we must start by defining the Business Impact? – We reverse the Impact Map and start with the Output. Then, we will use the model to tease out the other factors.
Reversing the Impact Map
When somebody has a feature idea, they usually also have some reasoning. Maybe it is well thought through and based on great insights, or perhaps it’s just an unvalidated idea they find intriguing. To understand their reasoning, we must get the missing information step by step. To do that, we have to tap into their internal story.
The best way I found to get them to talk is not to ask for the Outcome customers are looking for but to start talking about what people they have in mind for this feature. We ask about the Actor.
Often, this is a specific user group or even an individual they have talked to. It might be a prospective or existing customer, an existing user who ran into a problem, a regulator prescribing new guidelines, or a cooperating business partner who should be able to integrate more easily. Many different Actors could be at the center of the idea.
By talking about the actors, the conversation naturally shifts to Outcomes. What does the actor want to achieve? What is their goal? It gives you insights into how the person with the feature idea is reasoning about why to build this feature.
And the last question is why this is good for our business. This question can be a bit trickier. The answer might be an oversimplified “to make money.“ Try to understand better how your counterpart's logic works. What business mechanic are they talking about? Do we convert more customers at a particular step? Can we save a deal worth X amount of money? Can we reduce manual work due to this proposed automation?
The goal is not to have a perfect answer but rather to understand why this should work for the business. Settle for a scenario. Don’t overstress this discussion.
With these topics explored, you will end up with a map like this.
You might use this map while talking with your colleague as a note-taking approach. It can help ensure you are on the same page and enables your discussion partner to reflect on what is being said while talking.
But mapping in the moment might feel inappropriate for your situation. You can also map after the conversation and use this visual in follow-up conversations. A simple “After our last conversation, I built a small overview to ensure I understand your reasoning. Does this look correct?“ should do the trick.
This picture helps to ensure you both are on the same page about their reasoning.
Of course, the goal is not simply to understand the reasoning behind the Output and move on. We want to drive the conversation towards Outcomes to be able to explore alternative solutions.
Switch Business Impact and Output
The trick to get back to the original format of an Impact Map — We simply have to switch the Output and Business Impact.
Now, we look at the same Output from a business perspective. The reasoning stays completely intact. You can also create a sentence like this:
“To achieve [Business Impact], [Actor] is able to [Outcome] by utilzing [Output]“
Shift the discussion on Outcomes
With this map in hand, you can now start to discuss options. If your counterpart agrees that a certain Outcome is important for a certain Actor, why not look at whether there might be a simpler Output to reach the same Outcome?
The critical step here is to show that the same Outcome can be achieved with less investment. You want to spark the idea that alternative solutions can achieve the same Business Impact by solving the Actor’s need differently.
Go further up the chain
If needed, we can also go further and open up alternative Outcomes for a given Actor, still paying into the same Business Impact.
We can traverse as far back as needed to open up alternative paths. Most of the time, it is unnecessary to trace back and open up all the options. It just complicates the discussion and might be outside of your responsibility anyway.
However, when you are in a leadership position, this model can help you explore and communicate different options, leading to an anticipated Business Impact. It moves the conversation away from a multitude of Outputs to discussing various problems to solve involving Actors, all connected to the desired Business Impact.
With an agreed-upon Outcome, you can also start to define how you measure success and open the door for Product Discovery approaches by identifying and tackling different risks. But even if your organization is not bought in on Product Discovery and wants to jump directly into delivering solutions, this way, you can start to discuss options, widen the field of possible solutions, and land on something simpler, satisfying the need your requester described without jumping into the next big project.
Example
Imagine a PM responsible for a cooking website that provides recipes.
Their boss is dropping in: “Hey, we should create a new widget for the start page suggesting an easy recipe every day. Can you please let me know when we could release this?“
The PM usually starts now to think about how to create this widget, how to select recipes, who is curating this, etc. It sounds like there are a ton of questions to answer before they even get an idea about how much effort this will be.
The headache has already started because this is another feature request they need to add to the roadmap and have to prioritize along with the other things already in the pipeline.
Instead, this time, they start a short conversation to clarify where this is coming from and what context the boss has in mind.
PM: “That sounds very interesting. Can you tell me what kind of user you have in mind who would love to use this?“
Boss: “Obviously, people new to cooking need quick meal inspiration. I hear often that they think our website is very cool, but they don’t know where to start.“
PM: “Yes, I see. Cooking newbies are hard to get engaged. When you talked to these people, did they mention what they want to achieve?“
Boss: “Yes, all sorts of things. Getting healthier, saving money, and integrating cooking into their busy day. I think they need to move from cooking once in a while to cooking several times a week.“
PM: “Interesting. When we help them to cook several times a week, what do you have in mind we gain as a business?“
Boss: “As you know, we spend a lot on ads, and they work well to get people on to the page, register, and open some recipes in the first days. But after that, they are gone. I’m pretty sure they just can’t get into regular cooking. So a widget very prominent on the start page picking them up with a recipe of the day will help them get there, and they will visit more often.“
PM: “Oh yes, I also see in our analytics that this group has the biggest churn rates. So, if I understood you correctly, this is the model you have in mind?“
Boss: “Yes, that looks about right. So when do you think we can ship this?“
PM: “Let me think about it and talk to some people.“
A couple of days later.
The PM reversed the Impact Map, explored alternatives for the Outcome, and talked to some people to find possible solutions requiring less effort.
PM: “Hey, boss, remember our conversation on the Daily Recipe Widget?“
Boss: “Of course. Did you have time to explore this and have an idea when we will ship this?“
PM: “Yes, I thought about it and looked into what we can do. Unfortunately, the team is still occupied with the video content feature, and to get the widget, we need to touch more places than we anticipated. But I explored some alternatives we could get out of the door quicker.“
Boss: “OK, hmm. Not sure, but let’s hear about it.“
PM: “Remember, to reduce our churn rate for cooking newbies, we want them to be able to cook several times a week. I found a couple of other ways which might help us get there:
90% of people signing up are getting the weekly newsletter. We can integrate the recipes there, so people don’t even have to come to the site.
Another approach is to label quick meals on the website. It’s easy to integrate a label, and I could spend a day labeling the recipes with Mike from recipe development. We would need this work anyway for the widget, and we can directly release it and start measuring.
Another thing I remember is that we created an e-mail campaign a couple of months ago to get started with cooking. It is working pretty well to engage people, but currently, they have to subscribe manually. We could just auto-subscribe new members.
While the engineering team is still busy for the next two weeks, I want to look deeper into any of these and talk to a couple of newly registered users to get a better idea of what would work. It seems these alternatives are way easier to implement. We could get something out in four weeks from now, instead of spending at least three months on the widget, and see if people are coming back to the website more often. Are you okay with that?“
Boss: “Yes, sure. The quicker we can reduce churn, the better it would be, and then the engineers can start to build the widget.“
Of course, this example is a bit streamlined and simplified. However, the key moments are when the PM starts asking curious questions to better understand their boss’ thinking and then provides possible options that save invested effort. The goal is not to have a competition for “better” ideas but to convey the concept that there are other options to consider.
Conversation Hacking
Reverse Impact Mapping is basically a hack to shift the conversation. By making the logic of your counterpart visible, you open the mental door to be able to talk about alternatives without pushing directly back and giving the impression of “I don’t want to help you / I have a better idea.“
Of course, don’t expect to change your organization's mindset and culture by doing this one time. Start by engaging in conversations with the map in your mind and map for yourself. When you feel a bit more secure, share these maps and start to shift the feature request conversations you are having.
And if you think: “This sounds great, but it will never work in my situation!” – I would be very interested to hear more about your situation and see if I have another hack in mind.
Further reading
Thanks to Gojko Adzic for coming up with the original concept of Impact Mapping and for seeding this by mentioning “reverse-engineering“ Impact Maps in the book.
And a big shout-out to Büşra Coşkuner, who expanded on Gojkos's idea and published a similar approach to Reverse Impact Maps.