Continuous Discovery

Continuous discovery is weekly touchpoints with customers, run by the team building the product, in pursuit of a desired outcome. It is a subtype of product discovery, the broader practice of learning what to build before you build it.

The term is commonly attributed to Teresa Torres, whose book Continuous Discovery Habits and Product Talk site define it precisely: "[w]eekly touch points with customers by the team building the product, where they conduct small research activities in pursuit of a desired outcome." Product Talk stresses that the cadence alone is not enough. The product team has to talk to customers directly rather than through a report handed over by a separate research function. The research activities have to stay small enough to fit alongside the regular work of building the product. And the whole effort has to stay pointed at a specific, measurable outcome instead of drifting into an open-ended chat.

Torres also describes the opportunity solution tree, a visual map that branches a desired outcome into customer opportunities, then into candidate solutions and the assumption tests for each one. It is the artifact that turns a week of interviews into a decision, updated as new opportunities surface and old ones get ruled out.

Why it matters for product-market fit

Produck's loop runs Listen, Diagnose, Decide, Ship, and continuous discovery is the operating rhythm behind the first two stages. Listen is the weekly touchpoint itself, the user interview plus whatever feedback is already flowing into your feedback loop. Diagnose is where that raw material gets sorted into opportunities worth pursuing versus noise worth ignoring.

Most teams do not fail at discovery because they refuse to talk to customers. They fail because the talking and the deciding live in different systems that never sync up. A founder does a round of interviews and writes up notes somewhere; three weeks later, when the roadmap debate happens, nobody can find the thread that connects it back to what customers actually said. As we wrote in the pmf stack is broken, the tools people already own for talking to users and the tools they use for deciding what to build are almost never the same tool, so the connective tissue between a customer's words and a shipped decision gets lost every single week.

Produck exists to hold that connective tissue. Interview notes and support messages land in one place and stay attached to the decision they eventually inform, tagged to whatever theme connects them. When a PM opens the Diagnose view six weeks later, the opportunity is still linked to the exact quotes that surfaced it, not a vague memory of someone having mentioned it once.

When it works, and when it doesn't

It works when:

• A cross-functional team owns a real product outcome and controls its own calendar, so the weekly interview slot survives a busy sprint instead of getting cancelled first.
• The team has a lightweight way to capture and revisit what they learn, so opportunity threads survive past the week they were discovered in.

It falls short when:

• Customer contact is outsourced entirely to a research function that reports back on a quarterly cadence, which breaks the direct-contact condition Torres builds the whole framework on.
• Nobody owns turning interview notes into a decision, so the touchpoints happen but nothing downstream changes.
• The product has no clear outcome to pursue yet, so every interview turns into an open-ended chat instead of a test of a specific opportunity.
• The team is pre-revenue and still searching for who its customer even is, in which case broader exploratory discovery has to come first.

How to apply it

1. Pick one product outcome you're trying to move, stated as a customer behavior change, not a feature you want shipped.
2. Book a recurring weekly interview slot for whoever owns the product, even before you have anyone to fill it. Start with three willing users if that's all you have.
3. Bring the full product team to every session instead of sending a single delegate to summarize afterward.
4. Route what you hear into one place that both your interview notes and your existing feedback channels feed, so nothing gets orphaned in a doc nobody reopens.
5. Sketch or update an opportunity map after each session, connecting new opportunities back to the outcome you picked in step one.
6. Revisit the map before every roadmap decision, and require that any feature going into Decide can be traced back to an opportunity on it.