Continuous Discovery — weekly, not quarterly.

The most useful reframe of product discovery in the last decade came from Teresa Torres and her 2021 book Continuous Discovery Habits. The reframe was small in concept and enormous in consequence. Discovery, she argued, is not a phase. It is a habit. The product team, not a research function, not a quarterly steering group, but the team that builds the product, talks to customers every week. Three to five customer touchpoints, every week, as a baseline rhythm. Not a quarterly off-site. Not an annual research sprint. Weekly.

If you have spent any time in a product organisation, you'll recognise the alternative — the model continuous discovery is meant to replace. It looks like this: somebody decides it's time to plan the next thing. A research sprint is scheduled: two weeks of interviews, frantic recruiting, a deck at the end. The deck lands. A roadmap is drafted from the deck. The team starts building. Eight months later, the build ships. Nobody can quite remember what was in the original research, and the market has moved. The deck was decisive in March; by November it is theatre. The cycle repeats. Discovery became a phase, the phase became stale, and the team built the wrong thing very well.

The Opportunity Solution Tree.

Torres's central artefact is the Opportunity Solution Tree, a way to hold the connection between desired outcome, customer needs, and proposed solutions in a structure that can be reasoned about, debated, and pruned. The tree has three layers. At the top sits a single business outcome, a metric the team is trying to move. Below it sit a handful of opportunities: customer needs, pains or desires that, if addressed, would move the outcome. Below each opportunity sit candidate solutions: experiments or features the team could try.

What makes the tree valuable isn't the diagram. It's the discipline it enforces. Every solution you propose has to attach to an opportunity — a customer need you've actually heard. Every opportunity has to attach to the outcome, the metric you're moving. If a stakeholder demands a feature and you can't draw a line from the feature to an opportunity to the outcome, you have a conversation to have with that stakeholder. The tree turns "we need feature X" into "which customer need does X address, and would addressing it move the outcome we agreed to?"

Why batched discovery dies.

Batched discovery, the quarterly research sprint, fails in three ways, each of them structural rather than fixable by trying harder.

• The findings stale during the build. The signal you captured in week one is six months old by the time the feature ships. The user who told you in February that their workflow was broken has either fixed it themselves, switched product, or stopped caring. The build is answering a question that was retired.
• The team doesn't internalise the insight. A deck of findings is not the same as having heard a customer say it. The PM who ran the interviews knows; the engineer who has only read the slide doesn't. When trade-offs surface during the build, the engineer trades off on intuition because the underlying need was never theirs.
• You can't course-correct. Building twelve weeks against a quarterly research deck is a one-way bet. If three weeks in you discover a flawed assumption, you have nowhere to go for new data. The recruiting pipeline has been wound down, the calendar is booked with build work, and the next research sprint is months away.

What weekly actually looks like.

The Torres prescription, three to five customer touchpoints per week attended by the product trio (PM, design, engineering), sounds impossible until you've built the recruiting infrastructure. Once the panel exists and the calendar holds a fixed Tuesday-and-Thursday research slot, the cost per session collapses. You don't write a new interview guide every week. You iterate on the same one for the month, with one open exploratory section that follows whatever opportunity the team is currently most interested in.

The trio model matters. When the engineer hears the user describe the workflow, the technical questions the engineer raises in the build are different. When the designer hears the user struggle with the navigation, the next prototype draws from memory rather than from a deck. Torres has written extensively on why the trio is the unit, and the field evidence backs it. Teams that interview together build better than teams where one role does the listening and the others read the notes.

One team, five teams, fifty teams.

What continuous looks like varies enormously with scale.

One team. The PM owns the panel, the calendar holds the slot, the trio attends every session. The Opportunity Solution Tree lives on a single Miro board. Refinement of the tree happens at the end of each interview week. Total cost: roughly four hours per person per week.

Five teams. A shared recruiting platform and a ResearchOps lead. Each team has its own tree and outcome. Cross-team interview shares happen monthly so opportunities surfaced by one team feed adjacent teams. Tools matter here: Dovetail, Marvin or Reduct for transcript repositories that can be searched across teams.

Fifty teams. A research platform team, a panel-management function, shared interview-share infrastructure, a tagging taxonomy maintained centrally so insights surface across teams. At this scale, the risk isn't doing too little research. It's doing duplicative research because team A doesn't know team B already interviewed the same customer last week. Discovery operations becomes a real function.

Decision rights: who acts on what you learn?

The hardest part of continuous discovery isn't the interviewing. It's the decision rights. When the team learns something in week three of a build that suggests the build is wrong, who has the authority to call the change? If the answer is "we'll raise it at the quarterly steering group", you don't have continuous discovery. You have continuous interviewing, which is worse than batched research because it generates findings the organisation has no machinery to act on.

Continuous discovery requires the trio to have decision rights on the solution layer of the tree. The outcome stays fixed for the quarter (and is signed off by the leader above the team). The opportunities can be revised mid-quarter with a light-touch update. The solutions are the team's to choose, swap and kill as the evidence comes in. If those decision rights aren't in place, continuous discovery becomes performance. Interviews happen, findings get archived, nothing changes.

How we use this at Product Pieces.

When a CPO Piece or PM Piece engagement uncovers that the team has drifted into batched, quarterly discovery, the fix is almost always two pieces of work — a recruiting pipeline rebuild and a decision-rights conversation with the leader above the team. The Opportunity Solution Tree is a useful artefact but it's downstream of the operating model that lets the team act on what the tree contains.

The Discovery Set Piece sets up the rhythm (panel, calendar, trio, tree, decision rights) in four to six weeks, with a handover plan for the team to keep it running. Next week's issue picks up the thread once more: A/B testing, the most-misused tool in product, and the rules that make it earn its keep.