Teresa Torres on continuous discovery, the opportunity solution tree, and customer interviewing

Executive overview

Most product teams are told what to build and never develop habits for understanding customers. Teresa Torres argues that continuous, lightweight customer contact — as little as one interview per week — produces better bets than any amount of upfront planning.

The opportunity solution tree gives teams a visual scaffold to move from a business outcome through customer opportunities down to testable solutions. Interviewing is the engine that fills it, but only when done with story-based questions rather than direct opinion surveys.

The core insight: discovery and delivery are not sequential phases — they run in parallel, and the habit of weekly customer contact progressively improves every bet your team makes.

The opportunity solution tree

• Starts with a single outcome at the root; branches into an opportunity space, then solutions, then assumption tests
• Opportunities are unmet needs, pain points, or desires — not features or solutions
• Structure the opportunity space using an experience map: distinct moments in a customer journey, each containing needs that arise at that moment
• Top-level branches map to steps in the journey (3–7 is a practical limit for cognitive manageability)
• Moving down the tree produces smaller, actionable opportunities that still contribute to the larger outcome
• The same opportunity space looks similar across competitors — what differs is which opportunities you choose and how you solve them
• Most teams write opportunities as solutions; correcting this distinction is the hardest skill to develop

Why teams struggle to build the tree

• Opportunities emerge from customer stories, not from direct questions like "what do you like about this product?"
• Direct, out-of-context questions produce fast but unreliable answers that miss behavior and nuance
• Story-based questions ground answers in a specific past experience: concrete, contextual, and more likely to surface unmet needs the customer can't articulate
• Three compounding skills are required: interviewing well, recognising opportunities in what you hear, and framing them at the right level of specificity
• Vague framing ("make this easier") produces unsolvable opportunities; specific framing ("hard to enter a password using the Apple TV remote") produces solvable ones

Continuous discovery: the core idea

• Discovery is simply the work done to decide what to build; everyone does it, whether deliberately or not
• Digital products are never done — teams must continuously decide what to build, so they must continuously include the customer
• The project-based mindset (discover first, then deliver) is a mismatch for ongoing digital work
• Discovery and delivery always run in parallel; building the discovery habit gradually improves the quality of bets over time
• Everything in the backlog is a bet — discovery makes bets better, but you should keep shipping bets while building the discovery habit

Making the case for discovery

• When leaders say there's no time, they mean no time for project-based research — continuous discovery is a different, lighter thing
• One interview per week on the interviewing side is sufficient to build the habit
• Assumption testing is the start of delivery, not a separate phase before it
• Don't stop shipping while starting discovery; run both in parallel from day one
• Individual contributors can adopt this way of working personally without waiting for organisational buy-in — even consumer product users in your personal network count as accessible customers

Automating the recruiting pipeline

• The goal: an interview on the calendar every week that required zero effort to schedule
• Consumer and B2B end users: embed an opt-in prompt inside the product ("Do you have 20 minutes to talk to us?"), link to scheduling software, and let customers book directly
• B2B buyers and decision-makers: use sales, account management, or support teams as recruiters — define a weekly trigger profile and let those teams book interviews on the product team's calendar
• The product team only needs to show up and conduct the interview
• Scheduling tools: Calendly, Outlook, Google, Salesforce all support this
• In-product intercept tools: Qualaroo, Ethnio, Intercom, Usabilla, Chameleon, Hotjar

Interviewing technique

• Write fewer questions — a 50-question protocol produces an unnatural interrogation, not a conversation
• A good interview should feel like having a beer with a friend: casual and conversational
• A single opening question can drive the whole interview: "Tell me about the last time you [relevant experience]"
• Follow-up by helping the interviewee narrate a timeline: "Set the scene", "What happened next?", "How come?"
• The interviewer's job is to stay curious about the story, not to worry about the next question
• Staying shallow — moving to the next story too quickly — discards the most valuable material
• Ask about what people did, not what they would do or think they do; hypotheticals and introspection are unreliable
• A sign of a good interview: the customer asks when they can do it again

Common mistakes

• Asking direct opinion questions instead of collecting specific past stories
• Losing focus on the interviewee's story while mentally preparing the next question
• Staying at surface level rather than digging into friction moments the customer mentions
• Focusing on hypothetical future behaviour instead of recalling actual past behaviour
• Treating discovery as a phase to complete before delivery begins

How much discovery is enough

• Not every solution needs deep discovery — assess the risk level of each bet first
• Reserve robust discovery for core product experiences and differentiators
• Instrument every release so you can observe actual impact and calibrate your risk judgment over time
• Work with multiple solution options for the same opportunity: comparing and contrasting is how better decisions get made
• When facing scepticism about small sample sizes, note that the alternative is usually zero customer data; also, the goal is changing behaviour with fast feedback loops, not generating statistically significant new knowledge

Scaling discovery across company size

• The base unit — an empowered trio (PM, designer, engineer) with an outcome and a discovery habit — works the same at 3 people or 100,000
• At scale, adjacencies increase: design systems, shared patterns, and lateral collaboration with neighbouring teams become necessary to maintain a coherent product
• The trio model, where the three roles decide together rather than through role hierarchy, works when the team shares a deep common understanding of customers
• Most disagreements within a well-functioning trio disappear because they stem from differing assumptions about customers, not genuine value conflicts