In a world where digital products evolve at breakneck speed, one of the most critical questions for any product team is simple to state, yet difficult to answer: how do you make sure you're building the right thing, at the right time, for the right reasons? That's exactly what product discovery addresses, and more specifically the methodology developed by Teresa Torres.
What is Product Discovery?
Product discovery is the process that precedes development. It aims to answer three fundamental questions before writing a single line of code:
- What problem are we trying to solve? (understanding users' real needs)
- Is this problem actually worth solving? (prioritization by business impact)
- Does our proposed solution actually solve this problem? (validation before development)
Without this phase, teams risk building features that nobody uses, a reality the industry knows well: according to various studies, over 60% of developed features generate little or no value for users.
Teresa Torres and "Continuous Discovery Habits"
Teresa Torres is an American product coach whose work has profoundly influenced how modern product teams approach discovery. In her book Continuous Discovery Habits (2021), she argues for a central idea: discovery shouldn't be a one-time project, but a continuous, weekly practice.
Her three fundamental pillars are:
- Regular interviews: Meeting at least one user per week to understand their real needs, not to validate preconceived ideas.
- Opportunity mapping: Structuring what you learn as a visual tree: the Opportunity Solution Tree.
- Rapid experiments: Testing solutions with minimum effort before committing to full development.
The Opportunity Solution Tree (OST)
The OST is the central tool of Torres' methodology. It's a visual tree that structures all product thinking around a clear business objective. It comprises four levels:
- The root, the Outcome: The measurable business goal the team is trying to achieve. E.g., "Reduce chargeback rate by 20% this quarter" or "Increase conversion rate by 10%". This is the destination, not the solution.
- Level 1, Opportunities: Pain points, unmet needs or user desires that, if addressed, would contribute to reaching the outcome. E.g., "Current detection rules generate too many false positives" or "Analysts lack real-time visibility on suspicious transactions".
- Level 2, Solutions: Feature ideas or improvements to address each opportunity. E.g., "Refine rules with an ML model" or "Build a real-time monitoring dashboard".
- Level 3, Experiments: Quick tests to validate (or invalidate) solutions before fully building them.
What makes the OST powerful is that it forces the team to start from the problem, not the solution, a counter-intuitive reflex for many tech teams who tend to jump straight to feature ideas.
User Interviews: The Heart of the Method
At the core of Torres' method is a strong conviction: you cannot understand user needs without talking to them regularly. But these aren't classic validation interviews. You're not trying to find out if users would like a given feature (they'll always say yes). You're trying to understand their real behaviors, daily frustrations and workarounds.
A typical Torres interview question: "Tell me about the last time you did X", a question that anchors the conversation in concrete lived experience, not in the hypothetical.
From Discovery to Delivery: Connecting the OST to User Stories
The OST isn't disconnected from development, it feeds directly into it. Every user story developed by the team should be traceable back to an opportunity in the tree, which itself links to the outcome. This traceability ensures that every development effort contributes to a measurable goal and that priorities are aligned with real value rather than gut feelings.
In practice, tools like MIRO are often used to build and share the OST visually with the whole team, while JIRA manages the resulting user stories.
My Takeaway
Having had the opportunity to participate in a discovery phase under the supervision of a Lead Product Manager gave me a concrete sense of how the OST structures decision-making in a real-world context. In a domain like payment fraud, where every product decision has a direct, measurable financial impact, having such a rigorous framework for prioritizing opportunities proved especially valuable. Discovery isn't an optional step: it's what makes the difference between building what the data shows and building what actually generates value.