Teresa Torres’s opportunity solution tree framework is one of the better discovery tools I’ve used. The structure — mapping customer opportunities to potential solutions in a visual tree — helps teams stay connected to user needs rather than defaulting to feature lists and stakeholder requests. I use a version of it. But running product for a platform at significant scale, and building AI agents to support the discovery process, has taught me where the framework needs substantial adaptation before it works in the real world.
This isn’t a critique of Torres. Her framework is sound. It’s an observation that opportunity solution trees as designed assume a pace and a data volume that most scaled products don’t operate at — and that AI changes both the opportunity and the failure mode of the entire discovery process.
The Opportunity Tree Reality Check
The OST framework looks clean in workshop settings. Customer interviews surface opportunities. Teams map solutions. Experiments get scoped. Everyone leaves feeling aligned. At scale, the process breaks down in a specific way: the rate of incoming opportunity signals overwhelms the team’s capacity to process them through a manual discovery rhythm.
When you’re monitoring support channels, usage patterns, feedback streams, and behavioral data for a large user base, the volume of potential opportunity signals is enormous. The question isn’t “how do we find the opportunities?” — AI can surface opportunity clusters from that data continuously. The question is “how do we evaluate and prioritize opportunities that are emerging faster than we can interview users about them?” Torres’s framework was designed for a world where discovery is the bottleneck. At scale with AI, discovery is no longer the bottleneck — judgment about what to do with what you’re discovering is.
Where AI Changes Everything in the OST Process
The adaptations I’ve made to the OST process at scale are all about restructuring what AI handles vs. what humans handle:
AI handles continuous opportunity sensing. Rather than quarterly or monthly discovery cycles, I’ve shifted to AI agents that monitor support channels, usage patterns, and feedback streams continuously — flagging opportunity clusters for human investigation. The tree is no longer built in workshops; it’s maintained continuously with AI surfacing new branches as they emerge from data.
Humans handle opportunity prioritization and solution imagination. Torres often combines opportunity identification and solution generation in workshops. At scale, separating these produces better results. AI excels at recognizing opportunity patterns from data. Humans excel at imagining solutions that connect to those opportunities in ways that AI wouldn’t generate without significant prompting. Keeping these steps separate — and keeping humans firmly in charge of the prioritization step — prevents the discovery process from becoming AI-driven by default.
The tree becomes a living document, not a workshop artifact. The biggest practical change: the OST is updated continuously based on incoming data rather than rebuilt quarterly. AI maintains the structural connections. Humans make the strategic decisions about which branches to pursue, which to prune, and which to flag for deeper investigation.
The Missing Piece: Solution Validation Speed
Torres’s framework handles opportunity identification well and provides a solid structure for mapping solutions. Where it provides less clarity — and where I’ve had to build my own process — is solution validation speed at scale.
When you can run experiments across a large user base, the question isn’t “how do we test this?” — it’s “how do we test this fast enough to keep up with the opportunity identification rate?” If AI is surfacing new opportunity clusters weekly but your experiment design and execution cycle takes six weeks, you’re building a backlog of validated opportunities that never get addressed before the next cycle of discovery makes them stale.
The solution I’ve found: tiered experiment design. Some solutions get full experiment design and execution. Others get fast behavioral proxies — early signals from a small user segment that don’t require full experiment infrastructure. The OST needs an explicit tier for each solution branch that determines the validation approach before the experiment is scoped. Without it, every solution competes for the same limited experiment capacity and most of them wait too long.
The Cultural Complexity Challenge
For products serving users across diverse geographies and cultural contexts, the OST needs one more adaptation Torres’s original framework doesn’t explicitly address: opportunity branches that are culturally segmented rather than universal.
The same user need can manifest in fundamentally different ways across cultural contexts — different mental models, different workflows, different relationship to the product’s value proposition. AI helps identify when an opportunity pattern is consistent across user segments and when it’s culturally specific. Without that distinction, you end up building solutions to universal-seeming opportunities that actually only solve for the segment that happens to be most vocal in your feedback channels.
The practical implication: before any significant OST branch gets resourced for solution design, ask explicitly whether the opportunity is universal or segment-specific. If it’s segment-specific, design the solution for that segment first — don’t try to generalize prematurely. Teresa Torres’s original OST documentation is the right starting point for understanding the framework’s foundations before adapting it.
What Still Requires Human Judgment
AI augments the OST process at scale in meaningful ways. It does not replace the human elements that make the framework valuable. Opportunity prioritization is still a human decision — AI can surface opportunity clusters, but the judgment about which opportunity is worth pursuing given current strategic context requires the kind of synthesized understanding that AI surfaces from data but doesn’t hold.
Solution creativity remains human. The connection between a user opportunity and an imaginative solution that users didn’t know they wanted — that’s not something AI generates reliably without creative prompting. And strategic trade-offs — the decisions about which opportunities to deprioritize in service of organizational focus — require human judgment that accounts for context AI doesn’t have.
The adapted OST is better than the original for scaled products. But “better” here means AI is doing more of the pattern recognition so humans can do more of the judgment work. The goal isn’t to automate discovery — it’s to remove the bottlenecks that keep humans from doing the discovery work that actually requires human judgment.
Your Turn: Apply This Today
Whether you’re just starting with OSTs or looking to evolve your current discovery process:
- Separate opportunity identification from solution generation in your process. If you’re currently doing both in workshops, split them into distinct phases. Use your data infrastructure (or AI tools) for continuous opportunity surfacing. Reserve workshop time exclusively for solution design and prioritization — where human creativity and judgment add the most value.
- Build a tiered validation system for your solution branches. Before any solution moves to experiment design, assign it a validation tier: full experiment, behavioral proxy, or customer interview. The tier determines the validation approach and timeline. This prevents every solution from competing for the same experiment infrastructure.
- Make your OST a living document, not a workshop artifact. If you’re rebuilding your OST quarterly, you’re losing continuity between cycles. Move it to a shared, continuously-updated document. Designate someone as the OST owner responsible for keeping the tree current between discovery cycles.
- Segment your opportunity identification by user type before prioritizing. Before deciding which opportunity to pursue, ask: is this opportunity universal across my user base, or specific to a segment? If it’s segment-specific, validate it with that segment first. Don’t let your most vocal users define the universal opportunity.
- Instrument one AI-assisted opportunity monitoring signal this quarter. Set up one automated signal that surfaces opportunity patterns from your existing data — support ticket clustering, feature usage drop-offs, search queries with no good results. Feed it into your OST review meeting as a standing input. This is the minimum viable version of continuous opportunity sensing.
- Explicitly protect human prioritization of the OST. If AI is surfacing opportunity data, establish a clear norm: AI surfaces, humans decide. Don’t let the volume and frequency of AI-surfaced opportunities shift the prioritization decision toward “whatever AI flagged most recently.” The human judgment layer is the framework’s value. Protect it deliberately.
The execution complexity challenge in OST is closely related — I’ve written about the missing branch in opportunity solution trees that most teams overlook when mapping solutions. And the continuous discovery breakdown that AI accelerates is a distinct problem worth examining separately.
Running discovery at scale and trying to adapt your product process to the pace AI enables? I consult with product teams on discovery operations, experiment design at scale, and building the systems that keep human judgment at the center of AI-augmented product development. Let’s talk.