Blog

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.

I switched from leading product at SermonCentral — 14,700 subscribers, two-week ship cycles — to a product serving 23 million users at a publisher founded in 1817. The contrast hit me on Day 3 when I wanted to update a single line of copy.

At SermonCentral, I’d open VS Code, push the change, and watch it go live. At my new role, that same change required stakeholder alignment across three departments, QA testing, and a deployment window I hadn’t even learned to schedule yet.

This is what the first 100 days of product leadership looks like inside a legacy institution — and it’s nothing like what I expected.

The Codebase Carries 20 Years of Decisions You Didn’t Make

When the first line of code for a product launches in 1993, you’re inheriting two decades of product decisions baked into the architecture. Database schemas that made perfect sense in 2004. API endpoints that were cutting-edge in 2010. Frontend frameworks that were the right choice when they were implemented — and still work fine, which is exactly why they haven’t been replaced.

At SermonCentral, when something felt clunky, I knew exactly why. I’d built it, or my co-founder had. Here, I was an archaeologist. Every feature had a story I didn’t know yet.

The temptation is to immediately start proposing rewrites. What I learned: listen first. The person who built that “outdated” search feature probably solved problems I hadn’t discovered yet. I spent my first 60 days in the codebase like I was studying someone else’s sermon notes — not to critique, but to understand the thinking behind each decision.

Stakeholder Alignment Takes 3x Longer (And That’s Actually Good)

At a startup, product decisions happen fast because the stakes are binary: ship something users love, or run out of money. At a product with 23 million users, the stakes are different. Break the wrong thing and you’re not just losing customers — you’re disrupting someone’s daily devotional time, interfering with a pastor’s sermon prep on Thursday night, affecting a small group leader in rural Kenya who depends on reliable access to Scripture.

A feature that would have been a 30-minute conversation at SermonCentral became a series of meetings involving product, engineering, content, legal, and partnership teams. Not because people were slow or bureaucratic — because the impact radius was massive.

Three months ago, I would have seen this as friction. Now I see it as risk management. The process is longer, but the decisions are better. I just had to recalibrate what “move fast” means when millions of people depend on you not breaking something they rely on spiritually.

Three Things That Surprised Me in the First 100 Days of Product Leadership

The depth of the data. The behavioral signals most startups dream about were already there. Not just what people read, but how they read it — chapter-by-chapter completion rates, cross-reference click patterns, search query analysis going back years across multiple Bible translations, languages, and device types. This wasn’t a Google Analytics dashboard. It was instrumented user behavior data that would make most SaaS companies jealous.

The team was already building what I thought we needed. I came in assuming I’d need to evangelize for modern product practices — user research, A/B testing, data-driven feature prioritization. Turns out, the team was already doing all of this. They just weren’t talking about it in Silicon Valley buzzwords. I thought I was joining a legacy institution that needed digital transformation. Instead, I found a digitally sophisticated team that needed someone to help coordinate and scale what they were already building.

The urgency is real. When people hear “200-year-old publisher,” they assume slow-moving and comfortable. That’s not what I found. Digital isn’t optional when you’re competing with products that have billions of installs. The urgency here is channeled through process, not around it. At a startup, urgency means cutting corners. Here, urgency means making the process faster and more effective.

What I’d Tell Any Product Leader Joining a Legacy Institution

Listen for 60 days. I thought I knew what the product needed after my first week. I was wrong about almost everything. The problems I identified weren’t actually problems — they were features working as intended for use cases I hadn’t discovered yet. Spend two months learning the system before you start trying to change it. Talk to everyone. Read the old product specs. Understand not just what the product does, but why it was built that way.

Ship something small by Day 90. Listening is important, but you also need to prove you can execute in their environment. Find something genuinely small — a bug fix, a copy improvement, a minor UX enhancement — and ship it. My first shipped feature was a tiny improvement to a comparison tool. It took three weeks to get live (compared to three hours at SermonCentral), but I learned more about the system from that one change than from a month of meetings.

Earn trust before proposing transformation. Legacy institutions have heard transformation pitches before — many from consultants who didn’t stick around to see the results. Your credibility comes from understanding what’s already working and why. The most effective change agents I’ve seen inside legacy organizations aren’t the ones who come in with dramatic transformation roadmaps. They’re the ones who make the existing system work better, then gradually expand the definition of “better” over time.

The Long Game

Building inside legacy institutions means accepting that transformation happens in years, not quarters. Your first job is to understand what’s already working before you start changing what isn’t. This is true whether you’re joining a publisher, a denomination, a hospital system, or any organization built to outlast its founders.

But it also means you’re building on a foundation tested by millions of users over decades. When you do ship something new, it immediately inherits that scale and stability. That’s a trade-off I didn’t expect to appreciate — but four months in, I do.

The question isn’t whether legacy organizations can innovate. The question is whether product leaders can learn to innovate within systems designed to last longer than most startups exist. From what I can tell so far, the answer is yes — but only if you’re willing to measure success differently than you were trained to.

Your Turn: Apply This Today

Whether you’re in your first week or month 18, these disciplines separate product leaders who earn trust from those who burn goodwill:

• Schedule a “context download” with every key stakeholder in the first 30 days. Ask them one question: “What has every product leader before me gotten wrong?” Listen without defending. Take notes. Come back in 60 days to report what you’ve done about it.
• Map the informal power structure before you touch the org chart. Identify who the real decision-makers are — the people others defer to in meetings even when they don’t have the title. Build those relationships before you need them.
• Find one quick win in the first 45 days — and be transparent about why you chose it. Explain publicly that you picked it because it demonstrates capability and builds trust, not because it’s the most important thing. This earns more credibility than the win itself.
• Audit your predecessor’s decisions charitably. Before you change anything, write a one-paragraph explanation of why the previous decision made sense in its context. Share it with your team. It signals maturity and protects morale.
• Don’t reorganize anything in the first 90 days. No matter how obvious the fix looks. Reorgs before trust is established signal insecurity, not leadership. Earn the mandate first.
• Set explicit expectations about your decision-making rhythm. Tell your team how you make decisions, what you delegate completely, and what you always want to be consulted on. Ambiguity on this costs you more goodwill than any single wrong decision.

Navigating a product leadership transition — startup to enterprise, or joining a ministry organization with legacy tech? This is exactly the kind of work I help leaders think through. Let’s talk.