Mini-Series: Outcome-focus with Impact Mapping

In one of my LinkedIn mini-series I laid down how you can find meaningful outcomes with the 5-Whys, how the outcomes cascade that you can create with this method will help you focus your Impact Map on finding good outcomes, and how to derive OKRs from the Impact Map.

Here’s the collection of the posts that build up on each other as a resource for you to look it up whenever you need this inspiration.

With each part you also get the link to the original post on LinkedIn.

 Post 1

Do you know what else the 5 Whys are good for, besides finding root causes?

𝗘𝘅𝗮𝗰𝘁𝗹𝘆: 𝗙𝗶𝗻𝗱𝗶𝗻𝗴 𝗼𝘂𝘁𝗰𝗼𝗺𝗲𝘀.

In another Impact Mapping workshop that I ran recently, my client’s team discussed heavily if Uber’s “getting from A to B is “a better outcome” than “signing up to the app”.

Look, this is the 𝘄𝗿𝗼𝗻𝗴 𝗾𝘂𝗲𝘀𝘁𝗶𝗼𝗻. It’s not about better or worse outcomes. It’s about the connections of them to each other. They build up on each other and build a metrics tree or “outcomes cascade”.

Let’s do a mental exercise and start with an output (which most people do):

User clicks on signup button on the app.
Because they want to sign up.
➡️ Outcome: user signups

Because they want to look for a free Uber.
➡️ Outcome: user finds a free Uber

Because they need a ride.
➡️ Outcome: starting a ride.

Because they want to get somewhere.
➡️ Outcome: finishing the ride (“Getting from A to B”) in a satisfactory way.

When you add metrics or outcomes that measure the overall satisfaction aspect, e.g. customer satisfaction, recommendation, retention, etc. you get a range of outcomes that you can pick from.

So, the question is not which outcome is better. The question is which improvement will have the biggest impact for your customers and your business.

Outcome Cascade

Asking “Why” brings you to a cascade of user outcomes.

Post 2

I love Impact Mapping – if done well!

Comparison of Impact Mapping Styles

Original Impact Map vs. the Adjusted Impact Map

It can help you connect business goals with user outcomes, find different other actors than only “customers” and “users”, and find deliverables that are connected to outcomes and have a high chance to improve business goals.

But something that needs practice is finding 𝗼𝘂𝘁𝗰𝗼𝗺𝗲𝘀 𝗶𝗻𝘀𝘁𝗲𝗮𝗱 𝗼𝗳 𝗼𝘂𝘁𝗽𝘂𝘁𝘀, AND finding the 𝗿𝗶𝗴𝗵𝘁 𝗹𝗲𝘃𝗲𝗹 𝗼𝗳 𝗼𝘂𝘁𝗰𝗼𝗺𝗲𝘀.

𝗢𝘂𝘁𝗰𝗼𝗺𝗲𝘀 𝗶𝗻𝘀𝘁𝗲𝗮𝗱 𝗼𝗳 𝗼𝘂𝘁𝗽𝘂𝘁𝘀
It’s difficult to find outcomes and be sure that it’s outcomes. It’s easy to confuse an interaction with the product with a behavior that this interaction implies or leads to.

In the image you can find an example on an hypothetical business goal “Increase number of first time bookings in the US by 10% by end of 2022” for AirBnB which we use in our Product Analytics Bootcamp. See the difference between the upper and lower examples:

Outcomes on an Impact Map

Most difficult part is writing good outcomes.

The upper is a mix of direct outputs (travel reports and tips) and interactions (search for xyz) which can also be considered as an output.

Outputs are deliverables, solutions. They express an interaction with the product.
User reads a travel report.
User uses the search bar.

Outcomes are end goals for an interaction. They are something that the user does or perceives.
User feels safe after reading the travel report.
User finds different places to go and interesting attractions and is convinced the US is a nice travel destination.

Here’s a link to a 2-post series that summarizes how to detect output-thinking and how to come up with a proper outcome for that output.

You see, I’ve even added another level of outcome here. User perceives the US to be a nice travel destination.

Which brings me to the other point:

𝗥𝗶𝗴𝗵𝘁 𝗹𝗲𝘃𝗲𝗹
There are different levels of outcomes and you can create entire outcome cascades or trees (see yesterday’s post). The higher on the tree the more you get in the direction of Objectives in the OKRs framework. The lower you get, the more you can relate them to Key Results.

Which level you want to get to in an Impact Map depends on your context. However, be aware that the more you’re on the lower levels, the more specific your outputs and limited your range for ideation will be.

But that’s for another post.

Post 3

What’s the right level of outcome to look at?

In yesterday’s Impact Mapping & Outcomes post, I mentioned that it needs practice to come up with the right outcomes. You need to consider a) if it’s a real outcome or rather an output (see yesterday’s post), and b) which level of outcome you’re looking at.

Today I’m going to share some practices regarding the right level of outcome.

𝗥𝗶𝗴𝗵𝘁 𝗹𝗲𝘃𝗲𝗹 𝗼𝗳 𝗼𝘂𝘁𝗰𝗼𝗺𝗲
Sorry to disappoint you folks but there is no 𝗥𝗜𝗚𝗛𝗧 level 😛


It’s good to know that there are different levels and your job is to pick the level and outcome(s) that create biggest impact for your customers and business.

And based on the level, your space for ideation is wider or more narrow.

👉 𝗟𝗲𝘁’𝘀 𝗵𝗮𝘃𝗲 𝗮 𝗹𝗼𝗼𝗸 𝗮𝘁 𝘁𝗵𝗲 𝗮𝘁𝘁𝗮𝗰𝗵𝗲𝗱 𝗶𝗺𝗮𝗴𝗲𝘀.

1️⃣ The 𝗳𝗶𝗿𝘀𝘁 𝗶𝗺𝗮𝗴𝗲 shows you an example (based on yesterday’s example) how breaking down your outcomes might look like.

There are broader outcomes that can be worth breaking down further if they feel too abstract to the team to ideate on.

On the other hand, you might end up looking at very narrow outcomes that might be worth abstracting in order to create overall goals or objectives (tomorrow’s post), or because your solution space becomes too limited.

💡 Be aware, you don’t have to break them down. You can also ideate outcomes first and then arrange them to a tree.

I’ll be very honest with you, I’m very, very good at teasing good and different outcomes out of you, but I’m not so creative myself when I get stuck in my own head. So forgive me for the uncreative outcomes in my example but I hope it’s good enough to explain the principle behind it.

2️⃣ The 𝘀𝗲𝗰𝗼𝗻𝗱 𝗶𝗺𝗮𝗴𝗲 shows you what I mean when I say you can ideate on all levels.

Let’s zoom in on the outcomes:

Take any outcome, ask the famous How Might We question, and ideate.

If you feel you’re too limited and can’t come up with a variety of ideas, go one step higher.

If you feel it’s too abstract and your ideas are all over the place, go one step down the tree.

👉 “𝗗𝗼 𝗜 𝗛𝗔𝗩𝗘 𝘁𝗼 𝗰𝗿𝗲𝗮𝘁𝗲 𝗮𝗻 𝗼𝘂𝘁𝗰𝗼𝗺𝗲 𝘁𝗿𝗲𝗲?”

👉 “𝗧𝗵𝗲𝗻 𝘄𝗵𝗮𝘁 𝗱𝗼𝗲𝘀 𝗶𝘁 𝗵𝗲𝗹𝗽 𝗺𝗲 𝘄𝗶𝘁𝗵?”
It helps you to
→ structure your thoughts and identify the reason why ideation isn’t going the way you expected.
→ build a metrics tree that helps you find metrics you want to improve that are connected to the overall business goal.
→ analyse your product down the user journey if you can cascade the outcomes along the user journey.
→ communicate why you believe the outcome you’re focusing your quarter’s work on is important.
→ derive meaningful OKRs when you already know which outcome is rather broad and which one is narrow.

𝗔𝗮𝗮𝗮𝗮𝗻𝗱 𝘁𝗵𝗮𝘁’𝘀 𝗳𝗼𝗿 𝘁𝗼𝗺𝗼𝗿𝗿𝗼𝘄: 𝗛𝗼𝘄 𝘁𝗼 𝗱𝗲𝗿𝗶𝘃𝗲 𝗢𝗞𝗥𝘀 𝗳𝗿𝗼𝗺 𝗮𝗻 𝗜𝗺𝗽𝗮𝗰𝘁 𝗠𝗮𝗽.

Follow me and ring the bell to not miss out on this piece 🔔

Post 4

How to derive OKRs from an Impact Map

Yesterday I mentioned breaking down outcomes in an Impact Map can help you in several ways. One thing it can help you with is deriving OKRs.

𝗟𝗲𝘁’𝘀 𝗵𝗮𝘃𝗲 𝗮 𝗹𝗼𝗼𝗸 𝗮𝘁 𝘁𝗵is 𝗳𝗶𝗿𝘀𝘁 𝗶𝗺𝗮𝗴𝗲.

1️⃣ The 𝘂𝗽𝗽𝗲𝗿 𝗽𝗮𝗿𝘁 𝗼𝗳 𝘁𝗵𝗲 𝗶𝗺𝗮𝗴𝗲 is the outcome tree from yesterday that shows you how to break down outcomes from broad to narrow.

Now a general rule of thumb is that the Outcome level of an Impact Map (originally it’s called “Impact” and reflects the HOW) matches more with Objectives from OKRs than with Key Results.

Unless you’re pretty narrow with the outcome that you’ve come up with.

See second image:

2️⃣ In the 𝗹𝗼𝘄𝗲𝗿 𝗽𝗮𝗿𝘁 𝗼𝗳 𝘁𝗵𝗲 𝗶𝗺𝗮𝗴𝗲 you can see the connection between outcomes of different levels and OKRs. 𝗧𝗼 𝘀𝗲𝗲 𝗺𝗼𝗿𝗲 𝗱𝗲𝘁𝗮𝗶𝗹𝘀, 𝗰𝗵𝗲𝗰𝗸 𝘁𝗵𝗲 𝘀𝗲𝗰𝗼𝗻𝗱 𝗶𝗺𝗮𝗴𝗲 that is a zoom in of the outcome tree.

Yellow boxes are Objectives.
Light yellow boxes are Key Results.
And next to the Objectives you see my evaluation.

The higher you are in your outcome tree, ie. the broader your outcome is, the more likely you can use it to formulate an Objective.

The further down the tree, ie. the more narrow your outcome, the more difficult it becomes to create meaningful Objectives. In this case you might want to see the outcome as a sort of Key Result. You want to find metrics that you can use to formulate a meaningful Key Result that focuses on this one very specific outcome.

You 𝗖𝗔𝗡𝗡𝗢𝗧 take the outcome and use it 1:1 as an Objective or Key Result. You 𝗠𝗨𝗦𝗧 change the wording in a way that it sounds more like an inspirational goals (Objective, see yellow boxes) or a very concrete SMART goal (Key Result, see grey box on the very right).


I hope this little series on using Impact Mapping in practice and how to derive OKRs and good outcomes from it was useful for you. At one point I’ll write about finding meaningful actors.

👉 If you need help to connect business goals with user outcomes, find and deliver on outcomes rather than outputs, derive meaningful OKRs with Impact Maps, ideate solutions that solve meaningful outcomes and eventually pay into the business goal, or just want to kick-off using Impact Mapping, get in touch and let’s see how I can support you.

Share the Post:

Related Posts

Agile Roadmaps in Practice

An Agile Coach approached me and asked me for reference documents or people to share with him. He wanted to gather some examples on agile roadmaps but it was difficult for him to find good examples of agile roadmaps. Most of the examples that he found were far from agile.

Here’s my answer.

Read More

“Why would you need Product Ops?!”

I was very skeptical about Product Ops.

I couldn’t grasp it. What’s Product Ops anyway? What do Prod Ops Managers do the whole day? Why do we need yet another new role and even a whole new team that does things that we’ve been doing without them the whole time? Aren’t we sick of creating new titles for old concepts?


I talked to Chris.

Chris Compston. Check him out!

Hi Chris.

Thank you Chris.

Chris is my best friend now. Sorry old best friends, you’ve been pushed aside (you are not but you know I need the dramaturgy).

Read More

Agile Roadmaps in Practice

An Agile Coach approached me and asked me for reference documents or people to share with him. He wanted to gather some examples on agile roadmaps but it was difficult for him to find good examples of agile roadmaps. Most of the examples that he found were far from agile.

Here’s my answer.

Read More