Lessons from Teresa Torres

Teresa Torres is a product management coach and the author of Continuous Discovery Habits. She created the Opportunity Solution Tree, a framework to help teams map business goals directly to customer needs. This collection outlines her approach to running continuous customer interviews and testing assumptions to focus on outcomes over raw output.

Part 1: The Foundations of Continuous Discovery

1. On defining discovery: "I’ll refer to the work that you do to decide what to build as discovery and the work that you do to build and ship a product as delivery." — Source: [Continuous Discovery Habits]
2. On the nature of digital products: "Discovery isn’t a one-time activity. A digital product is never done." — Source: [Scribd]
3. On the project mindset: "Rather than thinking about discovery as something that we do at the beginning of a project, you will learn to infuse discovery continuously throughout your development process." — Source: [Bookey]
4. On continuous cadence: "The habit is more important than the number of people you talk to. I’d rather you talk to one customer every week than four customers one week and no customers the next week." — Source: [Product Talk]
5. On balancing doubt and action: "You’ll learn to balance action with doubt, so that you can get started without being blindsided by what you don’t get right." — Source: [Goodreads]
6. On daily decision making: "Continuous interviewing will help to ensure that you can get fast answers to your daily questions." — Source: [SuperSummary]
7. On mitigating business risk: "Our goal as a product team is not to seek truth but to mitigate risk. We need to do just enough research to mitigate the risk that our companies bear." — Source: [WordPress]
8. On the illusion of the killer feature: "You are never one feature away from success and you never will be." — Source: [Medium]
9. On co-creation: "Rather than just validating their ideas, teams are co-creating with customers." — Source: [Bookey]

Part 2: Outcomes vs. Outputs

1. On shifting focus: "Shifting to an outcome mindset is harder than it looks. We spend most of our time talking about outputs. So, it’s not surprising that we tend to confuse the two." — Source: [Mind the Product]
2. On starting with numbers: "A good place to start is to make sure your outcome represents a number even if you aren’t sure yet how to measure it." — Source: [Goodreads]
3. On outcome ping-pong: "When we ping-pong from outcome to outcome, we never reap the benefits of this learning curve. Instead, set an outcome for your team, and focus on it for a few quarters." — Source: [Goodreads]
4. On endless discovery: "Without a clear outcome, discovery work can be never-ending, fruitless, and frustrating." — Source: [Bookey]
5. On evaluating management: "Managing by outcomes is only as effective as the outcomes themselves." — Source: [Bookey]
6. On latitude and autonomy: "Product outcomes give product trios far more latitude to explore and will enable them to make the decisions they need to ultimately drive business outcomes." — Source: [SuperSummary]
7. On preventing feature factories: Focusing on outcomes forces teams to understand why they are building something instead of just shipping code to meet a deadline. — Source: [ProductPlan]
8. On business vs. product outcomes: Business outcomes measure the health of the company, while product outcomes measure customer behavior that drives the business outcome. — Source: [Product Talk]
9. On tracking progress: Teams must learn to measure changes in customer behavior to know if their discovery work is actually moving the needle. — Source: [Zeda.io]

Part 3: The Opportunity Solution Tree

1. On the tree's primary purpose: "The opportunity solution tree is a simple way of visually representing how you plan to reach the desired outcome." — Source: [Product Talk]
2. On making the implicit explicit: "It also helps make implicit assumptions explicit." — Source: [Product Talk]
3. On navigating opinions: "Opportunity solution trees help you to navigate opinion battles, frame your decisions as 'compare and contrast' rather than 'whether or not,' and align around a shared understanding." — Source: [Shortform]
4. On defining an opportunity: "The easiest way to distinguish between an opportunity and a solution is to ask, 'Is there more than one way to address this opportunity?'" — Source: [Mind the Product]
5. On solving big problems: "The value of breaking big opportunities into a series of smaller opportunities is twofold. First, it allows us to tackle problems that otherwise might seem unsolvable." — Source: [Mind the Product]
6. On incremental value: "And second, it allows us to deliver value over time." — Source: [Mind the Product]
7. On the four levels: The OST forces teams to align their work across four distinct levels: desired outcomes, opportunities, solutions, and assumption tests. — Source: [Mural]
8. On mapping nonlinear exploration: The framework transforms discovery from a straight line into an open map, preventing teams from locking into their first idea. — Source: [Chameleon]
9. On separating spaces: Opportunities live in the problem space as unmet needs or desires, while solutions are the specific features designed to address them. — Source: [ProductPlan]
10. On avoiding solution-first thinking: "I don't want to prioritize in the solution space; I want to ask which of these needs is most important to drive our metric." — Source: [YouTube]

Part 4: The Product Trio & Collaboration

1. On the composition of the trio: "A product trio is typically comprised of a product manager, a designer, and a software engineer. These are the three roles that are required to create good digital products." — Source: [Product Talk]
2. On joint accountability: Trios are collectively responsible for the outcome, moving away from isolated individual functional tasks. — Source: [Product Talk]
3. On the danger of one customer voice: "Designating one person as the 'voice of the customer' gives that person too much power in a team decision-making model. The goal is for all team members to be the voice of the customer." — Source: [Goodreads]
4. On breaking role boundaries: "Many organizations try to define clear boundaries between the roles in a product trio. This sounds nice in theory, but it quickly falls apart in practice." — Source: [Goodreads]
5. On team size and speed: "The trio can flex, but know that you'll trade inclusivity with speed." — Source: [Mind the Product]
6. On avoiding hand-offs: Conducting discovery together prevents the knowledge loss and misaligned expectations that happen when documents are passed between departments. — Source: [Zeda.io]
7. On shared context: When engineers and designers hear customer problems firsthand, they design better solutions than if they read a summarized brief. — Source: [Medium]
8. On communicating with stakeholders: "Instead of communicating your conclusions, you are showing the thinking and learning that got you there. This allows your stakeholders to truly evaluate your work." — Source: [Goodreads]
9. On weighing in: Showing the discovery path allows stakeholders to provide relevant information the product trio might lack. — Source: [Goodreads]

Part 5: Customer Interviews & Story Extraction

1. On the keystone habit: "I’ve often said that I believe interviewing customers frequently and consistently is a keystone habit." — Source: [Product Talk]
2. On understanding reality: "If you want to build a successful product, you need to understand your customers’ actual behavior, their reality, not the story they tell themselves." — Source: [SuperSummary]
3. On story-based interviewing: "Story-based interviewing helps us to overcome some of that bias by prompting our customers to share a specific example of a past behavior rather than a generalized explanation." — Source: [Product Talk]
4. On the golden rule: "The golden rule of interviewing is to let the participant talk about what they care about most." — Source: [Medium]
5. On research vs. interview questions: Teams must distinguish between the internal questions they need to answer and the external questions they ask the customer. — Source: [Product Talk]
6. On avoiding speculation: Never ask a customer what they would do in the future; always ask them what they did in the past. — Source: [Medium]
7. On finding opportunities through interviews: "I don't want a product team to sit in a room and just think about opportunities. Our opportunities should emerge from our generative research." — Source: [YouTube]
8. On active listening: The interviewer’s job is to follow the customer's narrative arc, asking clarifying questions about their specific sequence of events. — Source: [Zero Blockers]
9. On generating leads: A continuous interviewing habit means the team never runs out of direct customer insights to guide their next sprint. — Source: [SuperSummary]
10. On recording over note-taking: Recording the interview allows the entire product trio to focus fully on the conversation rather than acting as transcribers. — Source: [Substack]

Part 6: Synthesis & Mapping the Opportunity Space

1. On preventing insight debt: Synthesizing an interview immediately after it happens ensures the details and nuances are not lost to time. — Source: [Product Talk]
2. On the interview snapshot: The snapshot is a one-page summary designed to extract the most actionable and memorable parts of a customer conversation. — Source: [Product Talk]
3. On the memorable quote: "The purpose of the memorable quote is to help you recall the story days, weeks, or even months later." — Source: [Product Talk]
4. On the yield of a single story: "A single customer story might elicit dozens of opportunities." — Source: [SuperSummary]
5. On logging general insights: "Something that we want to capture, but we aren’t sure what to do with it yet," should still be documented for future context. — Source: [Product Talk]
6. On the experience map: Creating a visual map of the customer’s story helps the trio identify exactly where friction or failure points occurred. — Source: [Product Talk]
7. On an evolving space: "If you interview continuously, your opportunity space will always be evolving, expanding as you learn about new needs, contracting as you address known problems." — Source: [SuperSummary]
8. On sorting opportunities: Teams should frame opportunities as unmet needs or pain points rather than feature requests masked as customer problems. — Source: [Zero Blockers]
9. On mapping hierarchy: Opportunities should be grouped into parent and child nodes to organize the problem space logically. — Source: [Product Talk]

Part 7: Assumption Testing & Rapid Experimentation

1. On ideas vs. assumptions: "Don't test your ideas. Test the assumptions that have to be true to make your ideas work. This may seem like an obvious point. But it's often overlooked." — Source: [Product Talk]
2. On the value of failure: "With assumption testing, most of our learning comes from failed tests. That's when we learn that something we thought was true might not be." — Source: [SuperSummary]
3. On failing faster: "Small tests give us a chance to fail sooner. Failing faster is what allows us to quickly move on to the next assumption, idea, or opportunity." — Source: [SuperSummary]
4. On making decisions: "We'll learn more by making a decision and then seeing the consequences of having made that decision than we will from trying to think our way to the perfect decision." — Source: [SuperSummary]
5. On acting on data: "If you don't know how you will use the data, you aren't ready to run your experiment. Decide upfront how you will act on the data you collect." — Source: [Product Talk]
6. On the five categories of assumptions: Teams should deliberately check their ideas against desirability, viability, feasibility, usability, and ethics. — Source: [Sprig]
7. On comparing ideas: Using assumption testing allows a team to ask which of three ideas is the most promising, rather than agonizing over a single idea in isolation. — Source: [Product Talk]
8. On breaking down tests: The goal is to design an experiment that can be run in a matter of hours or days, not weeks. — Source: [Martin Lugton]
9. On identifying the riskiest assumption: Teams must locate the assumption that has the highest impact if it turns out to be false and the lowest current supporting evidence. — Source: [Rework]
10. On preserving engineering time: By testing assumptions early, product trios avoid committing software engineers to building features that are fundamentally flawed. — Source: [Ostly]

Part 8: Mindset & Organizational Change

1. On unlearning project habits: Adopting continuous discovery requires teams to unlearn the rigid, milestone-driven habits of traditional project management. — Source: [Medium]
2. On handling doubt: Strong product teams actively cultivate a sense of doubt about their ideas to stay open to contrary evidence. — Source: [Goodreads]
3. On whether-or-not decisions: The human brain naturally defaults to binary "whether or not" decisions, but product discovery demands comparing multiple options. — Source: [Shortform]
4. On building trust: Continuous discovery builds trust with stakeholders because the work is visible, logical, and tied directly to agreed-upon outcomes. — Source: [Product Talk]
5. On scaling discovery: Once a single product trio establishes the habit of continuous interviewing, other teams often adopt the practice after seeing the resulting clarity. — Source: [Product Talk]
6. On resisting feature factories: Organizations must measure success by the impact on the customer, forcing a structural move away from purely tracking deployment velocity. — Source: [ProductPlan]
7. On empowering teams: True empowerment happens when leaders set the destination (the outcome) and trust the product trio to map the terrain (the discovery). — Source: [Mind the Product]
8. On maintaining momentum: A continuous mindset prevents the stalled periods that usually follow the release of a major product version. — Source: [Scribd]
9. On the goal of the discipline: Ultimately, the work of discovery is to discover products that create genuine value for the customer while simultaneously creating value for the business. — Source: [Goodreads]