Product Practice #309

How to Connect User Problems to Business Goals

READ ON

HERBIG.CO

PUBLISHED

Feb 16, 2024

READING TIME

4 min & 33 sec

Dear Reader,

Most people mistake Impact Mapping as a framework. As something they “have to” fill out. I encourage teams to treat it as a visual aid. Here’s what it can do for you but what it relies on to be useful:

It’s a structure for the Synthesis of your Discovery (and OKRs and Strategy Work).
It’s Garbage-in-Garbage-out. It either connects the dots that are there (independent of their quality) but can also help you uncover your blind spots

Here are five proven practices that improve your way of connecting business goals to user problems through Impact Mapping immediately:

Use Specific Impacts

It's easy to default to generic KPIs to set your Impact. But this will rarely help a product team with guiding their decisions. Instead, use specific Strategy Choices to define clear Impacts:

Accelerate inventory through private sellers → X% Inventory share from Private Sellers (instead of "Inventory Growth")

Connect it to other Practices

Impact Mapping should guide the decision-making of existing practices, not start a parallel universe. The various levels of the map connect to various Discovery practices like Strategy/Alignment to frame the Impact and Actors, Research to arrive at proven Outcomes, and Ideation + Testing for the Output and Experiment levels. Another loose mapping is that the Impact should link to Company KRs or Annual Team KRs, whereas the Outcomes should inform your Quarterly team-level KRs

Adapt and Bend it

Almost no way of working adds value to your work "out of the box." Modify it in whatever way possible. Like trying to reverse-engineer the gaps in your understanding by starting at the bottom (Outputs) and "mapping up." Or by adding more layers to the individual levels: One client added another overarching grouping of actors to group similar Actors by Geography.

Treat it as a Range of Options, Not Promises

Neither the Outcomes nor the Outputs items on an Impact Map should be seen as promises. Instead, they outline the options you have. For the 𝘈𝘤𝘵𝘰𝘳𝘴, that describes the possible groups of people for whom you 𝘤𝘰𝘶𝘭𝘥 solve a problem. For the 𝘖𝘶𝘵𝘤𝘰𝘮𝘦𝘴, that describes the options you have to improve the life of the various Actors. For the 𝘖𝘶𝘵p𝘶𝘵𝘴, that describes the 𝘱𝘰𝘴𝘴𝘪𝘣𝘭𝘦 solutions you could pursue to drive the identified Outcomes.

Prioritize Actor Outcomes over Business Outcomes

There's nothing wrong with aiming to improve a revenue target. But that doesn't mean a valid Outcome is to "put more items in my shopping basket." That's what the business wants. Instead, you have to understand what is in the user’s way of completing the actions that will contribute and lead to business success. "Continue shopping without having to leave the basket view first."

HOW TO PUT THIS THEORY INTO PRACTICE

Be clear on what Impact Mapping should do for you right now. Clarify strategic direction? Breaking down segments? Structure solution space experiments? Everything is possible.
Fill it iteratively. Impact Maps don’t get finished in workshops. You can assemble them in sessions, but the work to fill them happens out there in the real world.
Approach it sincerely, not seriously. This structure is just a substitutable means to a larger end. Don’t get lost in dogmatic discussions about how to do it right.

Thank you for Practicing Product,

Tim

PS.: My thinking on Impact Mapping stands on the shoulders of giants like Goijko Adzic, through whom I uncovered this approach about 10 years ago and have iterated on it ever since.

How to Dive Deeper into Product Discovery

Learn how I helped companies like Deutsche Telekom and Forto hone their Product Discovery practices. I closely work with product organizations through workshops and coaching to introduce and adapt Product Discovery.

Learn more about my Discovery Consulting

Content I found Practical This Week

Product Discovery: Pitfalls and Anti-Patterns

The main sign that a team is using Product-as-Prototype Discovery is that experiments don’t appear until after there is a prototype with working code. The other sign is a slow testing cadence. An extreme version of Product-as-Prototype is confusing Discovery with Beta testing. By the Beta phase of a delivery process, most of the decisions have been made and the team is only able to implement small tweaks in the delivered solution.

Read it here

How Netflix tests Netflix

However, the development of the new two-thumbs-up feature also shows that A/B testing alone isn’t enough. Without also talking directly to subscribers, the company would have prioritized the development of the heart icon and wouldn’t have given two thumbs up a chance to prove itself in A/B tests. “We take this multipronged approach of looking at a lot of different inputs,” Doig-Cardet said. “We're capturing insights from our customer service, from surveys, from interviews that we're doing, and using all of that to inform [what] we should be investing in and testing.”

Read it here

My Sales Team Won’t Let Me Talk To Customers. What Now?

You can start really small by asking, “Can I just sit in and observe your meeting?” When you go to that first meeting, don’t say anything. Simply observe. They should be comfortable with that. Then, in the next meeting, ask if you can ask a single question at the very end. Tell the salesperson or marketing person what the question is, tell them what you’re hoping to learn, and be sure to make it a story-based question so the customer loves it. That helps your coworkers to see that this actually isn’t scary. Your customer really enjoys participating. And then from there, iterate. So the key here is to understand the root of the concern. Most of it is the fear of the unknown. Work to remove those unknowns, start teeny tiny, and then iterate your way there to help overcome that resistance.

Read it here