Many teams draw product work as two boxes: discovery, then delivery. First we understand. Then we build. The arrows are clean, the verbs behave, and nobody has to explain why we learned something inconvenient three days before launch.
Real product work is less house-trained.
A team can understand a problem and still choose the wrong solution. It can validate a prototype and still discover that adoption falls apart in the actual workflow. It can ship something useful and then watch the market, regulation or customer behaviour move underneath it.
Discovery is not the phase where uncertainty disappears. It is the habit of noticing which uncertainty matters next.
What discovery is for
The practical job of discovery is to reduce risk before the organisation pays the full price of an idea. There are several kinds of risk hiding inside one confident roadmap item:
- Is the problem real and important enough?
- Does the proposed experience make sense to people?
- Can we build and operate it responsibly?
- Does it create value for the business as well as the user?
You do not answer all four with one interview, one experiment or one green dashboard. You gather enough evidence to make the next decision less fictional.
Teresa Torres describes continuous discovery as frequent, small research activities conducted by the team building the product in pursuit of an outcome. The useful word is not continuous because everyone needs another recurring meeting. It is continuous because decisions do not stop when coding starts.
The discovery theatre trap
Discovery theatre happens when a team performs the artifacts without allowing the evidence to change the plan.
There are interviews, but only after the solution has executive sponsorship. There is a prototype, but it tests whether users can click through it rather than whether the idea deserves to exist. There is a workshop with coloured notes, followed by the roadmap everybody arrived with.
The tell is simple: what could this activity cause us to do differently?
If the answer is nothing, it may be communication, research theatre or reassurance. It is not discovery.
Delivery creates new evidence
The strange corporate habit is treating delivery as the part where learning pauses. In reality, software in use generates evidence that a prototype cannot.
You see workarounds. Support discovers vocabulary nobody used in research. Engineers uncover constraints that change the economics. Sales finds the objection that was absent from the friendly beta group. Analytics shows that the “obvious” path is not obvious at all.
That information belongs in the product decision, not in a post-launch folder nobody opens.
Continuous discovery does not mean endlessly questioning every choice. It means keeping a live connection between what the team believes, what it observes and what it does next.
A less ceremonial rhythm
Try replacing the big discovery phase with three smaller questions attached to the work:
- Before commitment: what must be true for this bet to make sense?
- During delivery: what are we learning that changes scope, sequence or confidence?
- After release: what behaviour would tell us to continue, adapt or stop?
The output is not “validated.” That word is usually too grand for the evidence available. A more honest output is a decision with a confidence level and a next signal.
Start smaller than a transformation programme
Teams often reject continuous discovery because they imagine a complete operating-model migration: new roles, new ceremonies, weekly interviews, an immaculate opportunity tree and leadership behaving differently by next quarter. The scale of the imagined change protects the current system.
Teresa Torres’s practical guidance for getting started argues for progress through small habits rather than waiting for perfect organisational conditions. One team can attach a customer touchpoint to an active decision. One designer and engineer can join the PM for an interview. One assumption can be tested before a full solution is committed.
The point is not ritual compliance. It is shortening the feedback loop around a real choice.
Problem focus still needs movement
“Stay in the problem space” can become its own delay tactic. Teams produce increasingly polished maps while avoiding the exposure of trying something. Intercom’s “Start with the problem” principle is valuable because it connects problem definition to faster, better solution work rather than to endless analysis.
A healthy discovery rhythm alternates: frame, test, build, observe, revise. The team earns depth by moving between its model and reality. Discovery without delivery cannot observe sustained use. Delivery without discovery cannot distinguish progress from output.
What to record
Keep a lightweight decision log containing the current belief, supporting evidence, strongest counter-evidence, confidence and next signal. When the decision changes, record why. This creates organisational memory without pretending that every learning deserves a presentation.
Over time, the log reveals whether discovery changes decisions or merely decorates them. That is a more meaningful maturity measure than the number of interviews completed.
Questions to take back to your team
- What live decision is your current discovery activity allowed to change?
- When did someone from engineering last hear customer evidence without receiving it through a slide deck?
- Which assumption survived delivery only because nobody checked it after launch?
- Are you learning in small enough pieces to change direction while change is still affordable?
- What are you calling “validated” that is actually one promising signal with substantial uncertainty?
Pick one item already in delivery. What would you still like to learn, and which observation could alter scope, sequencing or the decision to continue?
My take
Discovery and delivery are not rival departments. They are two modes of the same product team: reducing uncertainty and creating value.
When discovery becomes a gate before delivery, teams optimise for passing the gate. When it becomes a habit, they can change their minds while changing them is still relatively cheap.
The goal is not to learn forever. It is to stop pretending the learning finished because the ticket moved columns.