Framework

Opportunity Solution Tree: Visual Product Discovery

Why Visual Discovery Matters

In high-growth Indian startups, product roadmaps often resemble a chaotic wishlist generated by the loudest voices in the room—usually enterprise sales teams or the founder. When a roadmap is just a list of features (e.g., "Build a loyalty points system," "Add dark mode," "Integrate WhatsApp APIs"), the team operates as a feature factory. They ship code, but they do not necessarily solve problems or move metrics.

The Opportunity Solution Tree (OST) fixes this disconnect. Product teams frequently jump straight from a broad Outcome ("We need to increase retention") directly to a Solution ("Let's build a streak feature"). The OST forces you to map the missing middle layer: the Opportunities.

By mapping out opportunities (e.g., "Users don't know how to use the advanced reporting filters" or "Users find the checkout page untrustworthy"), you unlock dozens of potential solutions for a single problem, rather than betting your entire quarter's engineering capacity on one unvalidated idea.

The 4 Layers of the Tree (With Indian Examples)

1. The Outcome (Top Node)

The root of the tree is the Outcome. This must be a measurable business metric. Ideally, it is one of your quarterly OKR Key Results. You cannot build a tree for "Improve User Experience" because it is not measurable. You can build a tree for "Reduce Cart Abandonment from 65% to 45%."

Example (Indian EdTech): Increase the completion rate of the foundational Python module from 15% to 35%.

2. The Opportunities (Second Layer)

Opportunities are customer pain points, desires, or needs. You do not invent opportunities in a boardroom; you discover them through continuous user interviewing and by analyzing customer support tickets. Opportunities should be framed from the user's perspective.

Branching from the EdTech Outcome above:

• Opportunity A: "I get stuck on the environment setup and quit before writing any code."
• Opportunity B: "The video lectures are in English, and I struggle to understand the technical jargon quickly."
• Opportunity C: "I don't see how this abstract math applies to getting a job."

3. The Solutions (Third Layer)

Now, and only now, are you allowed to brainstorm features. Because you have constrained the brainstorming to a specific Opportunity, the ideas will be highly targeted. Let's take Opportunity B (The language barrier).

• Solution 1: Use an Indic LLM (like Sarvam AI) to generate high-quality Hindi and Tamil subtitles for all legacy videos.
• Solution 2: Hire regional instructors to re-record the top 5 most difficult lessons natively.
• Solution 3: Build an AI chatbot integrated into the video player that can explain the current timestamp's concept in the user's native language.

4. The Experiments (Leaves)

You do not immediately build Solution 3 (the AI chatbot). That is a massive engineering risk. Instead, you design rapid experiments to test the underlying assumptions of the solution.

Experiment for Solution 3: "Fake Door" test. Add a "Translate Explanation to Hindi" button below the video player. When clicked, it shows a modal saying "This feature is coming soon." Measure how many users actually click it. If only 0.5% click it, you just saved three months of AI engineering work. The solution was flawed.

Building with the Team in Miro

The OST is not a solo exercise for the Product Manager. It is a collaborative artifact that must be owned by the Product Trio: the PM, the Lead Designer, and the Tech Lead.

Using a digital whiteboard tool like Miro or FigJam is essential. Set up a weekly 1-hour "Discovery Sync." During this sync, the trio reviews the notes from the past week's user interviews. If a user mentioned a new pain point, the team collaboratively adds a new Opportunity sticky note to the tree.

When the Tech Lead is involved in mapping the Opportunities, they often suggest incredibly elegant, low-effort solutions that the PM or Designer would never have thought of. Conversely, involving the Designer ensures that solutions are human-centric rather than purely functional database operations.

Connecting to Continuous Interviewing

The Opportunity Solution Tree is a living document. It is useless if it is populated once during quarterly planning and never looked at again. To feed the tree, Indian product teams must adopt a cadence of continuous interviewing—speaking to at least one user every single week.

In India, this often means compensating users appropriately (e.g., a ₹500 Amazon voucher) and being willing to conduct calls in regional languages to get past superficial, polite answers. When you conduct these interviews, you are strictly hunting for Opportunities. You ask them to walk you through the last time they tried to accomplish a task in your app, and you listen for the friction.

Common Pitfalls to Avoid

1. Solutions Disguised as Opportunities: Writing "The user needs a dark mode" is not an opportunity; it is a solution. The actual opportunity might be "The app hurts my eyes when I use it in bed at night." This framing allows for alternative solutions, like lowering the default contrast or adding a blue-light filter, rather than strictly building a dark theme.
2. Orphaned Nodes: Every Solution must connect upward to an Opportunity. If a stakeholder demands a feature and you cannot find an Opportunity it solves, it should not be built. It is a distraction from the Outcome.
3. Focusing on Only One Branch: The power of the tree is horizontal visualization. If you only explore solutions for the very first opportunity you write down, you might miss a much easier, higher-impact opportunity hiding in your user research.