"Should I use Impact Mapping or an Opportunity Solution Tree (OST)?"

I get asked this all the time, usually followed by: "What's the difference?" or "Which one is better for discovery?"

My answer is always: “Why not use both?”

Most people frame this as an either-or decision. Like you have to pick a side, declare allegiance to one framework over the other, and defend your choice forever.

That's not how product discovery actually works.

Both frameworks exist for a reason. Impact Mapping was documented by Gojko Adzic in his 2012 book, but it had been around for a while already. The Opportunity Solution Tree was created later, in 2016, by Teresa Torres.

So yes, you could run your entire product discovery with just one of the frameworks.

But I’ve found that it’s more useful when you combine them. Each framework solves a different problem, and most teams need both solved.

Why Combine Impact Mapping and Opportunity Solution Tree?

You can absolutely try to use Impact Mapping alone.

In fact, back when I was employed, I’d structure my thoughts and discovery hypotheses through it.

The framework is strong at what it does: connecting Business Goals to product work. But it doesn’t give you much structure for deep problem exploration. It shows you the path from Business Goal, to Actor, to Outcome, to Output, but it doesn't tell you how to uncover all the opportunities hiding in that problem space, or how to prioritise them.

That's where OST shines.

The Opportunity Solution Tree gives you a systematic way to map out every opportunity you could address, and make intentional choices about which ones have the strongest potential to move your Outcome. It's built for discovery depth.

However, it’s not without its problems.

When used it alone, the work tends to stay product-centric. You pick an Outcome and do discovery work to understand opportunities and test solutions, but you don’t always tie those Outcomes back to a Business Goal in a way that matters for leadership. You end up optimising the product without proving how it pays into revenue, retention, or whatever the company is actually trying to achieve.

Impact Mapping forces that link. It forces you to ask questions like:

• What Business Goal are we trying to impact?

• Which Actor (not just “customer”) matters here?

• What Outcome for that Actor signals we’re on the right path?

• Which Outputs might deliver that Outcome?

Impact Mapping keeps strategy and execution tied together. OST helps you explore and prioritise the messy middle from Outcome to solution. Together, they give you alignment and focus.

Another weakness of both trees is that they look at opportunity and outcome in isolation.

Two different actors might mention the same problem, wish or need but are looking for achieving different outcomes. The reverse is true, too. Two different actors might want to achieve the same outcome but in their very unique context they might have different problems, wishes or needs that need to be explored and served.

Accepting actor-outcome-opportunity or actor-opportunity-outcome as a combination unlocks real chances to build something that the customers (or actors) love that will help achieving business goals.

How To Combine the Two Frameworks

Combining Impact Mapping and OST can be done in a few different ways. First, let’s see how I most commonly do it in workshops.

Start with Impact Mapping to align strategy and product. After you’ve defined the Business Goal, the Actors, and the Outcomes, pause. This is when you plug in OST.

That Outcome, the one you've identified through Impact Mapping, becomes the product Outcome that sits at the top of your Opportunity Solution Tree. If you know OST, there’s nothing surprising here. What changes is that you haven’t picked an arbitrary product Outcome, you’ve picked one that already ladders to a Business Goal and a specific Actor.

Source: Büşra Coşkuner, own illustration

Let's use an example of an app everyone knows: Uber (the ride-sharing part, not food delivery). Your Business Goal might be something like "increase ride frequency in urban markets." Actor: ride-takers. Outcome: reduce wait time for a ride.

Now you have your product Outcome for the OST: help ride-takers wait less time for rides.

From there, run typical OST interviews. Ask questions like: "What makes some rides take longer to arrive?" and "When do rides show up quickly, what's different in those cases?" Map the opportunities and identify which ones have the strongest potential to drive your Outcome.

Then, move back to Impact Mapping to think through solutions.

Answer questions like: How might we…<serve that opportunity>? What could we actually build? How would it connect to the opportunities we identified? Does it still ladder up to the Actor and Business Goal we started with?

This is how we tie it all together.

A useful variant: Put Opportunities between Actor and Outcome

Sometimes, the way insights show up makes a different order more natural.

In a recent case, I was helping a product manager on a marketplace product to structure their discovery insights, namely on bulk selling. There were two B2B seller groups: NGOs and commercial sellers. Both reported the same pain of not being able to sell in bulk because the app didn’t support it.

She could have grouped them and built one generic feature. But that wouldn’t fix the issue.

So I suggested to split them: NGOs and commercial sellers.

For NGOs, the pain was space and urgency. They don't have room to store donations, and they want help to reach people as quickly as possible. So their Outcomes were: free up space faster, and get aid where it needs to go faster.

For commercial sellers, the pain was about money. They want to move inventory quickly to maximise profit. This means their Outcome is all about optimising ROI.

This led us to different solutions:

• For commercial sellers, bulk delivery with an extra fee made sense, as they were willing to pay for efficiency.

• For NGOs, a fee was likely to block adoption, so the idea came up to create an NGO special offer to keep costs manageable.

In this variant, we inserted the opportunities-thinking between Actor and Outcome. We used Outcomes to clarify the opportunity per Actor to follow the solution path that would help the Actors without damaging the Actor-opportunity and the underlying business-opportunity. Then we continued into solution space. This approach works best when you have multiple Actors sharing a visible pain but want different Outcomes.

Sometimes, after breaking down the Business Goal to Actor and Outcome and mapping opportunities, I notice that there is an opportunity that might have two different Outcomes depending on some other context. Maybe different Job to be Dones (JTBD), maybe sub-segments of the Actor, maybe something season…or whatever I find out about the context. In that case, I add another Outcome layer or even an Actor/JTBD layer.

And if you're working on an established product with OKRs already in place, you can jump straight into this approach. Your OKRs probably already give you a Business Goal, so you just need to make sure your discovery actually aligns with it.

Play with it. See how the combination helps you best to make sense of the context.

When not to use this combined approach

If you're building something brand new (truly new, not iterating on an existing product), you probably don’t have a clear value proposition yet. You’re drowning in business model assumptions, all waiting to be tested. In this case, I suggest starting with Strategyzer tools:

• Business Model Canvas to understand how value and money might flow.

• Value Proposition Canvas to map jobs, pains, and gains.

If your thoughts about the product itself are unclear, I'd even start with the Value Proposition Canvas, then move on to Ash Maurya's Lean Canvas, and only ones I'm clearer about the product I'd use the Business Model Canvas.

In this phase, I wouldn’t use Impact Mapping or OST yet. Everything's too messy and loose. You need space to figure out how the puzzle pieces fit together without getting locked into structure too early. Only once a plausible solution emerges, something concrete enough to iterate on, would I recommend switching into Impact Mapping and/or OST.

The point of all this

The goal of product discovery is to reduce uncertainty in the fastest, clearest way possible.

Sometimes that means moving through frameworks step by step. Other times, it requires jumping straight to the strongest signal you can get. And sometimes (most of the time, honestly) it means pulling the right tool for the specific problem you're trying to solve.

Impact Mapping and Opportunity Solution Trees aren't competing methods. They're complementary. One helps you stay connected to strategy. The other helps you explore deeply. In combination they help you understand the actor-outcome-opportunity dynamic best. You need both.

So stop asking which framework to use, and start asking: “What problem am I trying to solve right now?” Then pick the tool and the combination that actually helps you solve it.

This is my most used framework combination. What's yours that connects the dots for you? Write me an email - I'm curious to know.

—

This article was edited by Diana Bernardo.