Professional Documents
Culture Documents
Aligning work around outcomes instead of just chasing the next feature idea is
one of those things that product teams often want to nail, but rarely get right.
It’s because most of the frameworks we use prioritize tangible rock-solid
features over hard-to-measure effects.
Just look at how obsessed some Scrum teams are with the number of user
stories they can squeeze into a sprint, their velocity, or the number of pre-
de ned feature ideas they have to “re ne” through what I like to call “Alibi
Product Discovery.”
But all this talk about a mythical unicorn called “outcomes” won’t help teams
break the wheel. Instead, they need to be able to connect individual features to
behaviors worth changing and metrics that matter for the business.
But in order to change those human behaviors, you need to build “stuff.” And
this is where outputs come in. They represent the features or products you will
build, keeping the change in behavior you want to cause in mind. It’s what
product teams cycle through in their sprints and release on an ongoing basis.
Impact metrics:
Where do we want to be, expressed through a result.
Outcome metrics:
How will we know that we got there, by looking at measurable changes in
behavior.
Looking at how drastically different those three terms are, it should become
clear why jumping from high-level business impacts straight into solutions is
so dangerous.
Impact Mapping is the helpful bridge product teams need to connect the two
things executives and stakeholders care the most about: business impacts and
feature ideas.
The second scenario is when a product team needs guidance working with the
insights and evidence from their Product Discovery mission. The intent behind
every level of an Impact Map can be perfectly aligned with the continuous and
iterative set of activities a team is working through.
HY
W
WHO
HOW
WHAT
WHETHER
A lot of core ideas of his de nition of Impact Mapping still hold true up to this
day. However, based on my experience, I like to introduce a revised version of
Impact Mapping which makes it more effective for Product Teams.
The rst level intents to provide the overall strategic goal you want to
contribute to. This is why it makes sense to use an impact metric to articulate
the WHY. Essentially, this level aims to answer the question of WHY this
opportunity/mission/initiative is worth pursuing.
In order to make the WHY more tangible, articulating the ambition level about
the timing and the difference you seek to create is helpful.
Here are some examples of impact metrics to add to the WHY level of your
Impact Map:
Now it’s time to map out WHO can help you to achieve this goal. This level
helps you to create clarity in which actors play any kind of role in changing the
impact metric.
While it might be easy to list some of the very obvious actors right away,
uncovering second-degree actors is where the magic happens. By digging
deeper into a seemingly mundane interview or survey response, you might be
able to map out actors you haven’t paid attention to before e.g. relatives of
your users, administrative supporting roles, or read-only users which still
matter to your product. So, in short: You don‘t just want to look at actors from
an external perspectives like users or customers, but also including internal
roles which could matter, like stakeholders.
Here are some examples of actors being placed on the WHO level of an Impact
Map:
he marketing department
T
Power Users
Customer Success Agents
New Users
Returning Users
Churned Users
Depending on your mission, different levels of granularity make sense here.
Sometimes it can be enough to differentiate between new users and existing
users. In other cases, however, looking at more nuanced differentiations like
“power users”, “Pro Plan upgrade customers” makes sense.
This tricky thing is that there’s no place where we can just grab those
outcomes. Instead, the items listed here are the result of running and
interpreting qualitative and quantitative research. People won’t tell you how
they have to change their behavior so your company can make more money.
You need to understand their current work ows, pains, and gains, in order to
derive behaviors worth changing. However, you don’t want to focus on all the
behaviors worth changing, but only on those which have a chance of
contributing to the impact.
Here are some examples of actors being placed on the WHO level of an Impact
Map:
“How might we enable real estate agents to create a real estate exposé from
their smartphones?”
This should also serve as your litmus test if you’re talking about an actual
outcome or slipped into discussing features already.
Now it’s time to answer the questions WHAT features have the highest chance
of creating this desired change in behavior. While the HOW level can feel
incredibly tough to push through due to the uncertainty and fuzzy-ness,
entering the solution space by thinking about speci c features can feel like a
huge relief. Those features represent the actual output a team might produce
later on.
Write down any existing feature ideas (as long as they contribute to an
outcome) as well as coming up with new ones – aka outputs. For that, product
teams should run cross-functional ideation sessions with stakeholders from
across the company. By embracing re-combination and iterative group
sessions, the WHAT level probably lls up quickly.
Just as with every item on the Impact Map, it’s important that the pure
presence on the map doesn’t guarantee execution. Instead, it’s more about
creating potential paths worth pursuing. When wrapping-up an ideation
session with your team, this might be important to mention to manage
expectations the right way.
Here are some examples of actors being placed on the WHAT level of an
Impact Map:
Here comes the second addition to Impact Mapping which is part of those
main changes I made to the framework. The goal of this level is to answer the
question of WHETHER a solution is actually worth implementing.
After prioritizing those items of the WHAT level using a lightweight framework
like ICE Scoring, you should start running experiments. During that phase, it’s
important to look at the aspects of validity, usability, and feasibility of your idea.
This way of thinking forces you to be clear about how this idea came to life and
why experiment results support it.
You can also use your impact map to check new ideas against the pieces of
evidence you have in place. Does this idea help to create a change in behavior
we have prioritized? Not sure? Let’s prioritize validation around it and place it
as a bet on the WHAT level. Did a new user segment emerge from continuous
research activities? Great, time to expand the map and discuss this discovery
as a potential priority for the team.
Keep the map visible to remind yourself and your team of what you have
accomplished, and as an evidence locker to revisit and expand over time.
Because after all, that’s what product discovery is about — Gathering evidence
to support our decision-making processes.