In many teams, "discovery" is a stage on a timeline. First you do discovery, then you do delivery. Discovery is research and interviews and prototyping; delivery is building and shipping. The phase ends, the team moves on to the real work, and everyone feels good that the research box has been checked.
The problem is that the questions discovery is meant to answer do not stop when building starts. They intensify. You learn more about your users in the first week of watching them use a real feature than in a month of interviews. If discovery has ended, there is nowhere for that learning to go.
This article argues that discovery is not a phase you exit. It is a continuous loop that runs alongside delivery, and the teams that treat it that way make better decisions because the asking and the building keep informing each other.
The phase mental model
The idea that discovery is a phase is a shadow of the waterfall, even on teams that think of themselves as agile. Waterfall said requirements first, then build. Agile renamed the first part "discovery" and kept the sequence.
The sequence feels safe because it creates a clean handoff. Research finishes, a decision gets made, and building begins with the uncertainty supposedly resolved. But the uncertainty is never resolved. It is only deferred.
Treating discovery as a phase means the team stops learning at the exact moment it starts knowing enough to ask better questions.
What you only learn after you ship
Before you ship, you are working with assumptions, however well researched. You have interview quotes, prototype feedback, and a hypothesis. What you do not have is real users making real trade-offs with real data on the line.
Some things only show up in real usage. The feature that made sense in a prototype turns out to be used differently, or not at all. The edge case you dismissed as unlikely turns out to be the main path. The onboarding step you thought was trivial turns out to be where everyone stops.
If discovery has ended, these findings arrive with no place to go. They get filed in a document nobody reopens. The team ships, then moves to the next output, and the lesson is lost.
Discovery and delivery feed each other
The alternative is to see discovery and delivery as a loop, not a sequence. You build a small version of something, observe how it is used, learn, and feed that learning into the next decision.
In this model, delivery is itself a form of discovery. A shipped feature is an experiment. The result, adopted or ignored, loved or abandoned, is data. The next bet is informed by it.
This is the same shift described in the article on outputs versus outcomes: when the goal is a change in behavior rather than a shipped feature, the work never really stops asking whether the change happened.
What continuous discovery looks like
Continuous discovery is not constant research. It is research at a different cadence: small, frequent, and cheap, instead of large, occasional, and expensive.
In practice, it means talking to a user every week instead of doing a big study once a quarter. It means testing a rough prototype before investing in a polished one. It means watching real usage before planning the next iteration.
None of this requires more time than the phase model. It requires redistributing the time. A little discovery every week is cheaper and more useful than a lot of discovery every six months, because it arrives when there is a decision to make.
The objection: we don't have time
The most common objection is that there is no time to keep doing discovery once building starts. The objection is usually based on a mental image of discovery as heavy: big studies, long reports, slow synthesis.
Continuous discovery is the opposite of heavy. It is a fifteen-minute conversation, a prototype, a glance at the analytics. The cost is low because the questions are specific: they are about the thing you are about to build, not about the whole user base in the abstract.
Teams that "do not have time" for continuous discovery are usually spending that time redoing work. Building the wrong thing twice costs more than asking a question once.
Who owns discovery
In the phase model, discovery belongs to a researcher or a product manager who hands off a report. In the loop model, it belongs to everyone building the thing, because the questions arise at every step.
The product manager owns the decision, the designer owns the framing of the problem, and the engineer owns what is feasible. All three need to hear the user, and all three need to act on what they hear. Discovery that lives in a silo, even a well-run one, produces reports instead of decisions.
The takeaway
Discovery is not a gate you pass through on the way to the real work. It is the real work, running alongside the building. The teams that understand this stop asking "are we done with discovery?" and start asking "what are we learning, and what are we going to do about it?"
That question is what separates a team that ships features from a team that learns, and it is the same instinct that turns a long document into a useful one, which is the subject of the PRD as a contract nobody read.
