Principles of Product Management: Opportunity Solution Tree (Mapping Opportunities, Experiments, Assumptions)

Opportunity Solution Tree (Mapping Opportunities, Experiments, Assumptions)

Opportunity Solution Tree (OST) – Study Guide

What This Is

The Opportunity Solution Tree (OST) is a visual framework (created by Teresa Torres) that helps PMs systematically explore problems (opportunities) before jumping to solutions. It forces you to map user needs → testable assumptions → experiments in a structured way, reducing bias and increasing the odds of building the right thing. Example: A fintech startup noticed users abandoned their savings app after 30 days. Instead of guessing fixes (e.g., "Let’s add gamification!"), they used an OST to uncover that users struggled to set realistic goals—leading to a goal-setting workshop feature that boosted retention by 22%.

Key Terms & Frameworks

• Opportunity: A user need, pain point, or desire (not a solution). Example: "Users can’t track progress toward savings goals."
• Solution: A specific way to address an opportunity. Example: "Add a progress bar with milestone celebrations."
• Assumption: A belief about user behavior or outcomes that must be true for a solution to work. Example: "Users will engage more if they see progress visually."
• Experiment: A test to validate/invalidate an assumption (e.g., A/B test, prototype, survey). Example: "Show a progress bar to 50% of users and measure engagement vs. control."
• Outcome: The metric you’re trying to improve (e.g., retention, NPS). Example: "Increase 30-day retention from 40% to 60%."
• ICE Score: Impact × Confidence × Ease – prioritizes opportunities/solutions (1–10 scale). Impact: How much it moves the outcome. Confidence: How sure you are (data + intuition). Ease: Effort to test/implement.
• Double Diamond: A design process (Discover → Define → Develop → Deliver) that aligns with OST’s problem/solution split.
• North Star Metric (NSM): The single metric that best captures your product’s value. Example: "Weekly active users for a social app."
• Leading vs. Lagging Indicators:
• Leading: Predicts future success (e.g., "Users who set a goal in Week 1 are 2x more likely to retain").
• Lagging: Measures past success (e.g., "30-day retention rate").
• Continuous Discovery: Ongoing user research (e.g., weekly interviews) to refine opportunities, not just pre-launch.
• Solution Space vs. Problem Space:
• Problem Space: Exploring what users need (opportunities).
• Solution Space: Exploring how to meet those needs (solutions).
• ⚠️ "Solutioning": Jumping to solutions before validating opportunities (e.g., "Let’s build a chatbot!" without knowing if users want it).

Step-by-Step Process Flow

1. Define the Outcome

• Action: Start with a clear, measurable outcome (e.g., "Increase checkout conversion by 15%").
• How:
• Align with your NSM or OKRs.
• Use lagging metrics (e.g., revenue) but pair with leading indicators (e.g., "Users who save payment details convert 30% more").
• Example: Amazon’s "1-Click Ordering" was driven by the outcome: "Reduce friction in checkout to increase conversion."

2. Map Opportunities (Problem Space)

• Action: Brainstorm all possible user needs/pain points that could impact the outcome.
• How:
• Conduct user interviews (5–10 users) or analyze behavioral data (e.g., drop-off points in checkout).
• Group pain points into themes (e.g., "Users abandon cart because shipping costs are unclear").
• Use affinity mapping to cluster similar opportunities.
• Tools:
• Jobs-to-be-Done (JTBD): "When [situation], I want to [job] so I can [outcome]."
• User Journey Map: Highlight friction points.
• Example: Slack’s "huddles" feature came from the opportunity: "Users need quick, informal ways to discuss urgent topics without scheduling a meeting."

3. Prioritize Opportunities

• Action: Narrow down to the most impactful opportunities using ICE or RICE.
• How:
• Score each opportunity (1–10) on Impact (how much it moves the outcome), Confidence (data + intuition), and Ease (effort to test).
• Focus on high-impact, high-confidence opportunities first.
• Example: Airbnb prioritized "instant booking" (ICE: 9/10 impact, 8/10 confidence, 6/10 ease) over "AI-powered recommendations" (ICE: 7/10 impact, 5/10 confidence, 3/10 ease).

4. Generate Solutions (Solution Space)

• Action: Brainstorm multiple solutions for each prioritized opportunity.
• How:
• Use divergent thinking (e.g., "How might we…?" workshops).
• Avoid "solutioning" too early—stay open to wild ideas.
• Map solutions to specific assumptions (e.g., "If we add a progress bar, users will feel more motivated").
• Example: Duolingo’s "streaks" feature came from the solution: "Gamify daily practice to increase retention."

5. Test Assumptions with Experiments

• Action: Design quick, cheap experiments to validate assumptions.
• How:
• Low-effort tests: Surveys, fake door tests, prototypes (e.g., Figma mockups).
• High-effort tests: A/B tests, MVP launches.
• Use ICE to prioritize experiments (e.g., "Test a progress bar prototype with 10 users before building it").
• Example: Dropbox’s "referral program" was validated with a simple landing page offering extra storage for invites—before building the feature.

6. Iterate or Pivot

• Action: Analyze experiment results and decide:
• Double down (assumption validated → build the solution).
• Pivot (assumption invalidated → explore new solutions/opportunities).
• Kill (opportunity isn’t worth pursuing).
• How:
• Use leading indicators to predict success (e.g., "Users who engage with the prototype are 2x more likely to retain").
• Update the OST with new learnings.
• Example: Twitter’s "fleets" (ephemeral tweets) failed because users didn’t want another feed—so they killed it and pivoted to "Spaces" (audio chats).

Common Mistakes

1. Mistake: Starting with Solutions

• Why it’s wrong: You waste time building features users don’t need (e.g., "Let’s add a chatbot!" without knowing if users want it).
• Correction: Always start with opportunities (problem space). Use the OST to force this discipline.

2. Mistake: Ignoring Leading Indicators

• Why it’s wrong: Waiting for lagging metrics (e.g., revenue) to validate a solution is too slow.
• Correction: Pair lagging metrics with leading indicators (e.g., "Users who complete onboarding are 3x more likely to retain").

3. Mistake: Testing Too Late

• Why it’s wrong: Building a full MVP before testing assumptions is expensive (e.g., "Let’s ship the feature and see if it works").
• Correction: Test early and often with low-effort experiments (e.g., prototypes, surveys).

4. Mistake: Over-Prioritizing "Easy" Solutions

• Why it’s wrong: ICE’s "Ease" score can bias you toward quick wins that don’t move the needle.
• Correction: Balance impact and confidence first. Example: A "hard" solution (e.g., redesigning checkout) might have 10x the impact of an "easy" one (e.g., tweaking button colors).

5. Mistake: Not Updating the OST

• Why it’s wrong: The OST is a living document—ignoring new data leads to stale decisions.
• Correction: Revisit the OST weekly (e.g., after user interviews or experiment results).

PM Interview / Practical Insights

1. "How would you use an OST to improve [X metric]?"

• What they’re testing: Can you systematically explore problems before solutions?
• How to answer:
• Start with the outcome (e.g., "Increase 30-day retention").
• Walk through opportunities (e.g., "Users don’t see value in Week 1").
• Prioritize with ICE (e.g., "High-impact opportunity: ‘Users don’t understand core features’").
• Propose experiments (e.g., "Test a guided tour with 10 users").
• Trap: Jumping to solutions (e.g., "Let’s add a tutorial!") without mapping opportunities.

2. "How do you balance speed vs. rigor in testing?"

• What they’re testing: Can you move fast without cutting corners?
• How to answer:
• Use low-effort tests first (e.g., surveys, prototypes).
• Escalate to high-effort tests only if assumptions are validated (e.g., A/B tests).
• Example: "For a new feature, I’d start with a fake door test (low effort), then build a prototype if users show interest."
• Trap: Saying "We’d build an MVP first" (too slow for early validation).

3. "How do you handle a stakeholder who wants to build a feature you disagree with?"

• What they’re testing: Can you push back with data?
• How to answer:
• Use the OST to frame the conversation around outcomes (e.g., "Our goal is to increase retention—let’s map opportunities first").
• Propose cheap experiments to validate their idea (e.g., "Let’s test a prototype with 5 users before committing").
• Example: "A stakeholder wanted to add a ‘dark mode’ to our app. I proposed testing demand with a survey—turns out only 5% of users cared."
• Trap: Saying "I’d just say no" (shows lack of collaboration).

4. "How do you know when to kill a feature?"

• What they’re testing: Can you make data-driven decisions?
• How to answer:
• Use leading indicators to predict failure early (e.g., "Users who try the feature don’t return").
• Set clear success criteria upfront (e.g., "If <10% of users engage after 2 weeks, we kill it").
• Example: "We killed a ‘social sharing’ feature after seeing 0% of users shared in 30 days."
• Trap: Waiting for lagging metrics (e.g., "Let’s see if revenue drops").

Quick Check Questions

1. Your team wants to add a "social feed" to your productivity app to increase engagement. How do you decide?

• Answer: Map the opportunity first (e.g., "Do users want to share their work?"). Test with a fake door test (e.g., add a "Share" button that shows a "Coming Soon" message and track clicks). If <5% of users click, kill the idea.
• Why: Avoid building solutions without validating demand.

2. A stakeholder insists on adding a "live chat" feature to reduce support tickets. How do you respond?

• Answer: Propose testing the assumption that users prefer chat over self-service (e.g., survey users: "How would you prefer to get help?"). If 80% choose "FAQs," invest in improving documentation instead.
• Why: Stakeholders often push solutions—validate the opportunity first.

3. Your experiment shows a feature increases engagement but hurts NPS. What do you do?

• Answer: Dig into why NPS dropped (e.g., user interviews). If the trade-off isn’t worth it (e.g., "Users hate the feature but use it more"), kill it. If it’s a temporary dip (e.g., "Users are confused but will adapt"), iterate.
• Why: Outcomes > vanity metrics (engagement ≠ success if users are unhappy).

Last-Minute Cram Sheet

1. OST = Outcome → Opportunities → Solutions → Experiments (always start with the outcome).
2. Opportunity ≠ Solution (e.g., "Users can’t track progress" ≠ "Add a progress bar").
3. ICE Score: Impact × Confidence × Ease (prioritize high-impact, high-confidence first).
4. Leading indicators predict success (e.g., "Users who complete onboarding retain better").
5. Test early with low-effort experiments (e.g., prototypes, surveys, fake door tests).
6. ⚠️ "Solutioning" = Jumping to solutions before validating opportunities (e.g., "Let’s add a chatbot!").
7. Update the OST weekly—it’s a living document, not a one-time exercise.
8. Kill features if leading indicators show failure (e.g., <10% engagement after 2 weeks).
9. Stakeholder pushback? Use the OST to frame the conversation around outcomes.
10. ⚠️ "MVP" ≠ "First version"—it’s the smallest experiment to test an assumption.