Continuous Discovery Habits

What Continuous Discovery Habits is

Continuous Discovery Habits is a book by Teresa Torres, published in 2021. It lays out a structured approach to product discovery — the work product teams do to understand customer needs before deciding what to build.

The core argument is simple: most product teams do discovery wrong, or not at all. They treat it as a one-off research phase that happens before a big planning cycle. Torres argues that discovery should be continuous — a weekly habit, not a quarterly event.

The book gives teams the specific practices to make that happen: weekly customer interviews, a structured way to capture what you learn (the Opportunity Solution Tree), and a disciplined approach to testing assumptions before building solutions.

The three core habits

The product trio

Torres is specific about who should be doing discovery. She recommends a product trio: a product manager, a designer, and a software engineer working together as a unit. Not just the PM going off to do research and reporting back.

The reasoning is practical: when engineers and designers are part of the discovery process, they bring domain knowledge that PMs don't have. Engineers often see technical constraints and opportunities that change the solution space. Designers ask different questions in interviews than PMs do. And shared exposure to customers builds a shared understanding that makes collaboration faster.

In practice, the whole trio doesn't always need to attend every interview. What matters is that all three are regularly exposed to customer conversations and actively involved in making sense of what they learn.

Outcome-focused, not output-focused

One of the framework's central tensions is with how most companies actually operate. Most product teams work from a roadmap of features — outputs. Torres argues this is backwards. The right starting point is the outcome: a change in customer behaviour or a business metric that the team is responsible for moving.

When you start from an outcome, everything else follows: you do discovery to find the opportunities that would move that outcome, you generate solutions to address those opportunities, and you test assumptions about those solutions before building. The roadmap becomes a byproduct of discovery, not the thing you discover toward.

Why teams find it hard to adopt

• "We don't have time." The most common objection. Torres's response: you don't have time not to. The cost of building the wrong thing — which output-focused teams regularly do — is far higher than the time investment of weekly interviews.

• "We already do user research." Quarterly research sprints, usability studies on finished designs, or customer advisory boards are not the same as continuous discovery. The word "continuous" is doing a lot of work — it means weekly, ongoing, in small batches.

• "Our customers won't talk to us." Torres addresses this directly. The solution is an automated recruiting pipeline — a snippet in your product that invites customers to a recurring interview slot. Once set up, it runs passively and surfaces a steady stream of willing participants.

• "We don't know what to ask." The book gives a specific interview structure: ask customers to walk you through a recent experience. Don't ask about hypothetical features. Don't present mockups. Just listen to the story and probe for moments of friction and need.

How the OST fits into the workflow

After each interview, the team adds new opportunities to the tree. Over time, the opportunity layer builds up — a map of customer needs grounded in real research. The team then selects which opportunities to focus on, generates solutions for those opportunities, and designs assumption tests before building.

The OST is the connective tissue of the whole system. Without it, you end up with a pile of interview notes that nobody acts on. The tree gives the notes a structure: every opportunity lives somewhere in relation to the outcome you're pursuing, and you can see at a glance whether your current work is connected to what customers actually need.

Torres is clear that the tree is a living artifact. It should change every week as you learn from interviews and experiments. If yours hasn't changed in a month, that's a signal something is wrong — either you've stopped doing discovery, or you're not connecting what you learn back to the tree.

Getting started

If you want to adopt the framework, Torres recommends starting with just one habit: the weekly customer interview. Don't try to implement everything at once. Get the interview rhythm established first — then layer in the OST and assumption testing as you build confidence.

The minimum viable version:

1. 1

   Set up an automated recruiting pipeline in your product (a simple survey link to a Calendly slot is fine).

2. 2

   Commit to one 30-minute interview per week with a real customer.

3. 3

   After each interview, add what you learned to your OST.

4. 4

   At the end of each quarter, review the tree with your team and pick the opportunities to focus on in the next cycle.