Build Your First Opportunity Solution Tree

What an Opportunity Solution Tree actually is

An Opportunity Solution Tree (OST) is not a roadmap. It's not a feature list. It's a living map that connects a business outcome to the customer problems that drive it, the solutions you could build, and the experiments you're running to learn what works.

Teresa Torres created this framework and it's still one of the most useful thinking tools in product management. The structure is simple: outcome at the top, opportunities below it, solutions below those, experiments at the bottom. Each layer answers a different question. What are we trying to achieve? What customer problems could we solve to get there? What could we build? How do we know it works?

The power of the OST is that it separates three thinking modes most PMs conflate. Discovery mode: what problems do customers actually have? Solution mode: what are different ways to address each problem? Validation mode: which solution is worth the engineering time?

What's changed is how fast you can populate, test, and iterate on each layer. The structure is the same. The speed is radically different.

The old way vs. the new way

The old way to build an OST:

Week 1-2: Run 4-6 customer interviews to identify opportunities. Week 3: Synthesize interview notes into opportunity themes. Week 4: Brainstorm solutions with your trio. Week 5-6: Design and run assumption tests. Week 7-8: Analyze results, update the tree, decide what to build.

Eight weeks from "we need to learn" to "we know what to build." That was considered fast.

The new way:

Monday: Review your AI-generated opportunity brief. It synthesized signals from 500 support tickets, 30 sales calls, 200 NPS responses, and last week's usage data. Five clear opportunities emerged, each with signal strength and segment data.

Tuesday: Pick the top opportunity. Build a working prototype that addresses it. Two hours.

Wednesday: Show the prototype to three customers. Watch them use it. Get reactions.

Thursday: Iterate on the prototype based on feedback. Show the updated version to two more customers.

Friday: Decide. Build it, iterate more, or kill it. Update the tree.

One week. Same quality of learning. Fraction of the time.

Step 1: Start with your outcome (this hasn't changed)

The root of your tree is still a business outcome. Make it specific and measurable.

Not "make users happy." Not "improve the product." Something like: "Reduce monthly churn from 8% to 5% in 6 months." Or "Increase free-to-paid conversion from 3% to 6% this quarter." Or "Grow enterprise ARR by $2M this year."

This part is pure strategy and judgment. No AI helps you pick the right outcome to pursue. That's your job as a PM. Pick the outcome that matters most to your business right now and put it at the top.

At Smartcat, my outcome last quarter was "Increase freelancer activation by 50%." Getting new marketplace users from signup to first paid project. Everything below it was a hypothesis about how to get there.

Step 2: Let AI populate your opportunities

This is where the new model diverges sharply.

In the old model, you'd spend weeks interviewing customers to identify opportunities. You'd schedule calls, prepare questions, take notes, synthesize patterns. It was necessary work but incredibly slow.

Now, your opportunity layer populates from AI signal processing. If you've set up the discovery engine described in Continuous Discovery, you already have an agent synthesizing customer signals across channels every week.

That synthesis tells you things like:

"42 support tickets this month mention difficulty finding relevant projects. 8 of those are from enterprise accounts. 3 sales calls this week included objections about job discovery. NPS detractor comments mention 'search' 2x more than last quarter."

That's an opportunity: Freelancers struggle to find relevant projects because search doesn't match how they think about their skills.

You didn't need to interview 10 people to find this. The signal was already there, scattered across your support queue, sales recordings, and NPS responses. AI collected and connected it.

But, and this is important, you still need human judgment to evaluate whether the AI-identified opportunity is real. Signal strength tells you customers care about this. It doesn't tell you whether solving it moves your outcome metric. It doesn't tell you whether it's the highest-leverage opportunity compared to others. That's your job.

Here's how I evaluate AI-surfaced opportunities:

Signal strength. How many data points support this? Across how many channels? A problem that shows up in support tickets, sales calls, and NPS responses is stronger than one that only shows up in one place.

Segment relevance. Does this affect the customers who matter most for your outcome? If you're trying to reduce churn, opportunities from churned or at-risk customers matter more than feature requests from your happiest power users.

Business impact. If you solved this, would it move the outcome metric? Some problems are real and painful but don't connect to the metric you're optimizing.

Feasibility signal. Can you even imagine a solution? Sometimes AI surfaces a problem that's real but not something you can address. "Customers want us to be cheaper" is a valid signal but might not be an actionable opportunity.

Pick three to five opportunities. Not fifteen. Focus is what makes the tree useful.

Step 3: Prototype solutions (don't brainstorm them)

Here's the biggest shift from the traditional OST process.

The old model said: brainstorm 5-8 solutions per opportunity. Have a whiteboard session. Generate ideas. Then design experiments to test them over weeks.

The new model: build the solutions. Not as production features. As prototypes. Today.

For our job discovery opportunity, instead of listing "personalized recommendations, better search filters, curated digest, onboarding tutorial" on a whiteboard, I do this:

Prototype A (2 hours): Build a working search interface with skill-based matching. Freelancers enter their specialization in their own words, and the prototype shows matched projects. Clickable, functional, real data.

Prototype B (2 hours): Build a curated weekly digest. A page that shows "Top 10 projects for Python developers this week," generated from actual listings, with one-click apply.

Prototype C (1 hour): Build a simple "skills profile" flow where freelancers describe what they do, and the prototype shows how many matching projects exist. "Based on your skills, there are 47 projects that match you right now."

Three prototypes. Five hours of work. Each one is a testable solution that a customer can actually react to.

Why this is better than brainstorming: customers react to real things differently than they react to descriptions. Show someone a whiteboard sketch and they say "sure, looks good." Show them a working prototype and they say "oh, I wouldn't use it this way, I'd want to sort by deadline because I need work this week." That one sentence of honest reaction is worth more than a two-hour brainstorm session.

Step 4: Test with customers (this week, not next month)

You have three prototypes. Now show them to customers. Not in a month. This week.

The rapid prototype test:

Pick 5 customers in your target segment. Reach out: "Hey, we're exploring some ideas for helping you find relevant projects. Would you spend 15 minutes looking at something we built?"

Share the prototype. Watch them use it. Don't explain. Don't guide. Just watch.

What you're looking for:

Do they understand what it does without explanation? If not, the concept is too complicated.

Do they engage with it, or do they click around politely and stop? Engagement is signal. Politeness is noise.

Do they say something that reveals a deeper insight? "Oh, I'd use this but only on Mondays when I'm looking for new work." That tells you frequency. That tells you context. That tells you where to put it in the product.

Do they compare it to something they already do? "This is kind of like what I do manually in Slack." That validates the opportunity and tells you the current workaround.

The before/after test:

Even faster. Show customers the current experience, then the prototype. Ask: "Which one helps you more? Why?" The comparison forces specificity. They can't just say "it's nice." They have to say what's better and why.

The leave-it-with-them test:

For prototypes that are functional enough, share it and let them use it for a few days. Follow up: "Did you end up using it? What happened?" If they used it without being asked, that's the strongest signal. If they forgot about it, that tells you something too.

You're not looking for statistical significance. You're looking for strong directional signal from 5-10 people. Is this solving a real problem? Would they use this? What's missing?

Step 5: Update the tree weekly

The traditional OST was a quarterly artifact. You'd build it once, maybe update it after a big research cycle.

In the new model, the tree updates every week. Because you're running the discovery loop every week.

Every Friday, I spend 30 minutes updating my OST:

What did I learn this week? Which prototype got the strongest reaction? What surprised me? Did any opportunity get stronger or weaker?

What do I cut? If a prototype got zero engagement from 5 customers, I remove that solution branch. If an opportunity turned out to be a niche concern (1-2 customers, not a pattern), I deprioritize it.

What's next? Which opportunity or solution should I prototype next week? Which assumption is still untested?

The tree is alive. If it looks the same three weeks in a row, you're not learning fast enough.

A real OST that changed a quarter

Let me walk you through how this played out at Smartcat.

Outcome: Increase freelancer activation by 50%.

Monday: My weekly opportunity brief surfaced four patterns from signals across channels:

1. New freelancers can't find relevant projects (40+ support tickets, 3 sales call objections)
2. Profile completion is too complex (usage data showed 55% abandon at step 3)
3. First-project anxiety, freelancers self-filter out of jobs they're qualified for (8 interview mentions over 3 weeks)
4. No feedback after rejection, freelancers stop applying (CS email pattern)

Tuesday: I built two prototypes. One: a simplified profile flow that took 3 minutes instead of 15. Two: a "match score" that showed freelancers how well they fit each project, reducing self-filtering.

Wednesday: I showed both prototypes to 6 new freelancers. The simplified profile got polite nods. The match score got excitement. One freelancer said: "If I could see I'm an 85% match, I'd definitely apply. Right now I just guess and give up."

Thursday: I iterated on the match score prototype. Added a "what's missing" view that showed freelancers exactly what to add to their profile to improve their score. Showed it to 4 more freelancers. Three of them immediately started updating their profiles without being asked.

Friday: Decision. The match score prototype had strong signal. Profile simplification was nice but not the lever. I updated the OST: the match score solution moved to "validated, ready for engineering." The profile simplification moved to "park for now."

The following week: Engineering started building the production version of match score. They used the prototype as the spec. Three weeks later, it shipped. Activation improved 28% in the first month.

Total time from signal to shipped feature: 4 weeks. Old model would have been 3-4 months.

The OST wasn't a planning document. It was a learning machine that ran every week. The prototype did the job of months of research in days.

Common mistakes that still apply

Even with AI acceleration, these mistakes will tank your tree.

Too many branches. Your tree should have 3-5 opportunities, max. More than that means you haven't prioritized. AI will surface dozens of potential opportunities. Your job is to pick the ones that connect to your outcome metric. The rest get parked.

Confusing opportunities with solutions. "Improve search" is a solution. "Freelancers can't find relevant projects because search doesn't match their self-described skills" is an opportunity. The opportunity describes the customer problem. The solution is what you build. Keep them separate, even when AI is generating both.

Trusting AI signals without judgment. AI surfaces patterns. It can't tell you which patterns matter. If AI says "export issues mentioned 200 times," but 180 of those are from free-tier users and your outcome metric is enterprise retention, that signal might not be your top priority. Apply human judgment to AI output.

Skipping the prototype. Some PMs will use AI to populate the opportunity layer and then go straight to building production features. Don't. The prototype step exists because your understanding of the opportunity is always incomplete. The prototype reveals what you're missing. Skip it and you're back to building on assumptions.

Not killing solutions. The point of rapid prototyping is that it's cheap to be wrong. But you have to actually kill solutions that don't work. If 5 customers shrug at your prototype, kill it. Don't rationalize. Don't iterate endlessly hoping it clicks. Move to the next solution.

Build your first AI-powered OST this week

Monday (30 min): Pick your outcome. One metric, measurable, bounded by time.

Monday (30 min): Review your signal sources. What customer data do you already have access to? Support tickets, NPS, sales call recordings? If you have an agent running, review the opportunity brief. If not, manually scan last week's support tickets for the top 5 complaints.

Tuesday (3 hours): Pick your top opportunity. Build a prototype that addresses it. Not a mockup. A working thing.

Wednesday (1 hour): Share it with 3 customers. Watch them use it. Take notes.

Thursday (1 hour): Iterate or pivot based on feedback. Share updated version with 2 more customers.

Friday (30 min): Update your tree. What did you learn? What's next?

You just ran a full discovery cycle in one week. The tree isn't perfect. It doesn't need to be. It needs to be a learning engine that runs every week.

Next week, do it again. New opportunity, new prototype, new learning. After a month, you'll have tested more solutions than most teams test in a quarter.

That's the new speed of product discovery.