Teresa Torres has been making the case that product teams should map their Opportunity Solution Trees before touching a backlog. Her framework connects desired customer outcomes to specific opportunities, then branches into potential solutions — all documented visually before any feature decision gets made. The idea is simple: stop jumping to solutions before you’ve fully explored the problem space.
I’m a convert. I’ve watched teams build elaborate features for problems that weren’t actually blocking users from their desired outcomes. The OST discipline of separating “what are users trying to do?” from “what should we build?” saves months of wasted effort. If you’re not using opportunity solution trees in your discovery process, you should be.
But after running a 20-agent AI system and managing product decisions across a platform with tens of millions of users, I think Torres’ framework is missing a critical branch: execution complexity.
The Problem with Pure Opportunity Mapping
Torres’ methodology assumes that once you’ve identified the right opportunity and mapped potential solutions, implementation is relatively straightforward — map the problem space, explore solutions, pick the best one, ship it.
That works beautifully for traditional product features. It breaks down when you’re building AI-powered products where solution complexity can vary by orders of magnitude for the same opportunity.
Here’s a real example. Users were struggling to find relevant content quickly — a clear, validated opportunity. Torres’ framework surfaced three potential solutions: improved search filters, AI-powered recommendations, or a full personalization engine. All three theoretically addressed the same opportunity. But the execution complexity was radically different:
- Search filters: 2-week sprint with existing infrastructure
- AI recommendations: 3-month project requiring ML infrastructure we didn’t have
- Personalization engine: 12-18 months, new data team, significant architectural changes
The OST pointed toward the personalization engine as the most elegant solution. The execution reality made it the wrong choice — at least for that quarter.
The Execution Complexity Branch That’s Missing from Opportunity Solution Trees
Every opportunity solution tree needs a fourth assessment alongside feasibility, viability, and usability: execution complexity. Not just “can we build this?” but a structured evaluation of three dimensions:
Technical Complexity: What infrastructure, integrations, or architectural changes does this require? Does it introduce new dependencies that create fragility? AI solutions in particular can look simple on the surface but require entire data pipelines you haven’t built yet.
Organizational Capacity: Which specific people would work on this, and what are they not working on instead? “We have engineers” isn’t capacity analysis. You need to know if your ML team is already maxed out before you commit to an AI-heavy solution path.
Market Timing: How does this solution’s build timeline map to competitive pressure and user expectation shifts? The best solution shipped six months late is often worse than a good-enough solution shipped next sprint.
How This Changed a Real Decision
Back to the content discovery problem. The pure opportunity map pointed toward an AI recommendation engine. When I added the execution complexity branch, the picture shifted completely:
The recommendation engine required user behavior tracking we hadn’t built, content taxonomy infrastructure we didn’t have, and ML capacity that was already committed elsewhere for six months. Meanwhile, our data was showing users weren’t churning because of discovery problems — they were churning because of onboarding friction. That was a completely different branch of the opportunity tree we’d underweighted.
We shipped improved search filters in two weeks. Immediate impact on discovery success rates. ML capacity freed up for onboarding optimization. Six months later, we had the infrastructure foundation to revisit the recommendation engine with real behavioral data instead of assumptions.
Pure opportunity mapping would have sent us toward the most sophisticated solution. Adding execution complexity sent us toward the most effective one.
What I’ve Changed in Our Process
Every opportunity solution tree we build now includes an implementation branch with three required assessments before any solution advances to prioritization:
- Build vs. integrate: Can we solve this with existing tools and APIs, or does it require custom development?
- Team capacity reality: Named individuals, not abstract “team bandwidth”
- Dependency mapping: What other systems, teams, or external factors does this solution require before we can ship?
We also changed how we score solutions in prioritization. Instead of just evaluating opportunity impact, we multiply by an execution confidence score — a team-assessed number from 1-5 representing how clear and achievable the implementation path is right now, with current resources. High-confidence solutions get a boost. Novel solutions requiring infrastructure we don’t have get penalized, even if the opportunity mapping scores them well.
This has made our roadmap conversations significantly more honest. Teams stop selling “what would be most impressive” and start evaluating “what can we actually ship that moves the metric.” Those are different conversations.
Teresa Torres Is Still Right — Just Incomplete
None of this is an argument against opportunity solution trees. The framework is genuinely one of the most useful tools in product discovery, and Torres’ writing on continuous discovery should be required reading for any PM team.
The gap I’m pointing to is specifically about AI-era product development, where the distance between “this is the right solution” and “we can actually build this right now” has grown dramatically. AI solutions are rarely simple integrations. They carry data requirements, infrastructure dependencies, and organizational capabilities that need to be assessed as part of the tree — not after you’ve already committed to the direction.
Add the execution complexity branch. Your opportunity solution trees will be more honest and your roadmaps more achievable. If you’re already using deep customer knowledge to validate your opportunity space, adding execution complexity assessment closes the loop between discovery and delivery.
Your Turn: Apply This Today
Before your next opportunity solution tree session, add execution complexity as a first-class branch:
- Draw your OST with four branches, not three. Add “execution complexity” alongside desirability, viability, and feasibility. For each solution, map at least two execution risks: what could make this take 3x longer than estimated?
- Run a pre-mortem on your highest-priority experiment. Before you commit, ask the team: “Assume this experiment fails. What went wrong?” Write down the top three answers. Those are your execution risks. Address them in the experiment design.
- Estimate the “integration tax” on every proposed solution. How many other teams, systems, or processes does this solution touch? Every dependency adds execution time and coordination cost. Factor it in before you put a solution in a sprint.
- Create a “complexity score” for your backlog. Add a simple 1-5 complexity rating to every item: 1 = completely self-contained, 5 = touches 5+ systems or teams. Use it to balance your sprint with high-complexity and low-complexity items.
- Separate “solution discovery” from “execution planning” in your workflow. The OST is for discovery. Before any solution moves to execution, it needs a lightweight technical scoping session. Don’t skip the bridge between the two.
- Review your last three delayed projects and name the execution complexity that caused the delay. Was it dependencies, scope creep, unclear ownership, or something else? Use that pattern to inform how you scope the next one.
The execution complexity question is tactical, but it sits inside a bigger frame: what your product decisions are actually for — which shapes which trade-offs are even worth making.
Running product discovery at scale and hitting the gap between good frameworks and messy execution reality? I consult with product teams navigating complex build decisions, AI integration strategy, and discovery-to-delivery alignment. Let’s talk.