Product Discovery vs Delivery: How They Work Together

Updated on

How Product discovery and delivery work together: what each does, when discovery should be light or deep, how to carry open risk into delivery, and when production itself is the right way to learn.

Share:

Product discovery and delivery are two kinds of Product work, not two departments and not a fixed sequence of phases.

Discovery reduces uncertainty about whether a Product bet is worth pursuing and how to pursue it. Delivery builds, tests, releases and operates a production-quality change. Both produce evidence. Neither guarantees a good outcome by itself.

Strong teams connect the two continuously: they reduce the risks that are expensive or unsafe to learn through full delivery, carry the uncertainty that remains into delivery explicitly, and use what production teaches them to update the next Product decision.

That is why the useful question is rarely “what percentage of our time should go to discovery?” It is:

What do we still need to learn before this level of commitment is justified?

If you want the end-to-end learning system for running discovery as a repeatable practice, framing questions, recruiting, choosing methods, synthesizing evidence, mapping opportunities, testing assumptions, and making bets, that is the Product Discovery course. This page owns a narrower and more operational job: how learning work and production work should interact around one real Product bet.

Quick answer

  • Discovery and delivery are two kinds of work that usually run at the same time. They are not “what” versus “how”, and delivery is not the opposite of learning.
  • Every bet has a different risk profile. Some changes need almost no separate discovery; some need focused evidence before you commit expensive engineering capacity.
  • The commitment decision is not a handoff. The same cross-functional team stays responsible for the outcome and keeps the context while it builds.
  • Production is a legitimate learning environment, but only with a bounded scope, guardrails, a rollback plan, and an explicit evidence plan.
  • “Validated” is usually the wrong word. Prefer honest states: evidence currently supports, material risk reduced, remaining uncertainty explicit, production evidence needed.

Table of contents

The direct answer: two kinds of work, one team

Most teams that struggle with “discovery vs delivery” are not missing a template. They are missing a decision model.

The common failure is treating discovery as a gate: research happens, something gets called “validated”, and the work is handed to engineering. That model looks tidy on a slide and breaks in practice, because uncertainty is never fully removed before building starts. Feasibility changes once engineers get close to the system. Usability questions appear during production design. Commercial and operational constraints surface late. And released behavior routinely contradicts what a prototype suggested.

The healthier model is a loop, not a gate:

Decision → material uncertainty → cheapest credible learning → commitment → delivery → production evidence → updated decision

Discovery and delivery are both parts of that loop. A team can be doing discovery about next quarter’s bet while delivering this week’s change, and it can be doing discovery about something it already shipped. What matters is not which “track” work sits on. It is whether the team knows which uncertainty it is buying down, what it is choosing to leave open, and what evidence would change its mind.

What discovery and delivery each do

The usual shorthand, “discovery decides what to build, delivery builds it”, is a useful first approximation and a bad operating rule. Delivery produces evidence too, and discovery sometimes has to answer “how”, not just “what.”

Discovery: reduce decision-relevant uncertainty

The purpose of discovery is to make a Product decision better informed.

Discovery work can include:

  • customer evidence, interviews, observation, support themes, sales and success input;
  • behavioral and quantitative analysis, funnels, cohorts, usage, search, error and performance data;
  • prototypes and concept testing;
  • technical spikes and feasibility investigation;
  • assumption tests and experiments;
  • market, commercial and pricing validation;
  • viability checks with legal, compliance, security, finance or operations.

The output of discovery is not “a validated feature.” It is better evidence about a decision and an explicit account of the uncertainty that remains. Sometimes the honest result is that the team should stop, narrow, or reshape the bet.

Delivery: create a production-quality change

The purpose of delivery is to turn a decision into something the business can actually run.

Delivery work can include:

  • detailed design and interaction detail;
  • engineering and integration;
  • testing, including performance, reliability and security work;
  • instrumentation and analytics;
  • rollout planning, feature flags and staged exposure;
  • operational readiness, support readiness and documentation;
  • production monitoring and incident handling.

The output of delivery is a change that meets a real production standard, not a demo, not a thrown-over-the-wall prototype.

The contrast in one line

Discovery answers “what would have to be true, and what evidence do we have?” Delivery answers “can we build, release and operate this safely, and what does it actually do in the world?”

Both questions are answered by a cross-functional team. Both can run at the same time.

Use the four risks as a lens, not a checklist

The most widely used way to talk about Product risk comes from Marty Cagan and SVPG: value, usability, feasibility and viability. They are a useful lens because they separate genuinely different kinds of uncertainty.

  • Value risk, will customers buy, choose, adopt and keep using this?
  • Usability risk, can users (or admins, or operators) actually figure out how to get value?
  • Feasibility risk, can the team build it with the time, skills, data and technology available?
  • Viability risk, does it work for the business across sales, finance, legal, compliance, operations, brand and support constraints?

Treat these as an influential Product methodology and a thinking tool, not as empirical law. The important lesson is not the list. It is that not every bet has the same risk profile.

The same taxonomy, different profiles

A small, reversible copy change may carry little or no feasibility risk and a small usability risk. There is often no reason to run a separate discovery project.

A new AI workflow can carry substantial value, usability, model-quality, safety, latency and cost risk at the same time. “Will users want this?” is not the only question.

An enterprise permission architecture can carry major feasibility, security and operational risk. The expensive unknowns are likely technical and organizational, not whether a user “likes” a screen.

A compliance-sensitive financial feature can carry viability constraints that must be resolved before user testing even matters.

That is the practical value of the lens: it stops teams from applying one generic research routine to very different bets. It also forces the right people into the room. Product judgement on feasibility is weak without engineering. Usability judgement is weak without design. Viability judgement is weak without the functions that carry the constraint.

For calibration on how much risk each bet actually carries, the deciding question is not “which risks exist?” but “if we are wrong, how expensive, slow or harmful is it to correct?”

Discovery is not a phase gate

Here is the model to unlearn:

Idea → Discovery → VALIDATED → Delivery → Done

It fails for predictable reasons:

  • uncertainty is never fully removed, only reduced;
  • feasibility often changes during implementation;
  • usability details emerge while designing the real thing;
  • commercial and operational constraints can appear late;
  • released behavior can contradict prototype evidence;
  • small, reversible changes may not justify a separate discovery stage at all;
  • a formal gate can reward performing research instead of changing decisions.

A better mental model:

Decision → material uncertainty → cheapest credible learning → commitment → delivery → production evidence → updated decision

Discovery can legitimately happen:

  • before a commitment, to buy down a risk that is expensive to learn later;
  • during design or technical exploration, when the cheapest way to learn is to build something small;
  • during delivery, when implementation reveals that the bet or scope must change;
  • after a partial rollout, when only real usage can answer the question;
  • after full release, when the team checks whether the intended outcome actually moved.

The principle to keep: discovery is the work of reducing uncertainty, not a box on a project plan. If the uncertainty is already low, you do not need to manufacture discovery to satisfy a process.

The Risk-to-Commitment Control Board

This is the primary asset of the page: a reusable board for one Product bet. It replaces “is this validated?” with a set of explicit, reviewable fields.

Every field earns its place. The board works because it forces the team to separate observed facts, what still is not known, and what it is choosing to do anyway.

The board fields

Product decision, What are we actually considering committing to? Write it as a decision, not a feature name.

Desired outcome, What change in customer or business behavior are we trying to create? If you cannot state this, you are not ready to judge the bet.

Material uncertainty / risk, What could make this bet fail? Label the risk type where it helps: Value, Usability, Feasibility, Viability, or another explicit context-specific risk (for example, safety, trust, or regulatory). Do not force all four categories onto every decision.

Why this risk matters, If we ignore it, what costly mistake could occur? This is where consequence, not anxiety, should drive the amount of discovery.

Cheapest credible evidence, What is the smallest method that can materially update the decision? Examples: existing behavioral data, a few targeted interviews, a prototype, a technical spike, a policy or legal review, a concierge or manual version, or a bounded production experiment.

Evidence we have, Observed facts only. Keep interpretation out of this field.

Remaining uncertainty, What is still not known after the evidence we have?

Commitment decision, A descriptive state, not a score:

  • keep learning before committing;
  • narrow the bet;
  • commit with open risk;
  • deliver behind a guardrail or staged rollout;
  • stop or change direction.

Delivery safeguards, Only where contextually relevant: instrumentation, feature flag, staged rollout, rollback plan, support readiness, operational monitoring.

Production evidence to inspect, What will tell us whether the bet is behaving as expected?

Reopen trigger, What evidence would force the team to revisit the decision?

There is deliberately no confidence percentage and no numeric score. A board that can always be marked “80% confident” teaches nothing. A board that states the open risk in words can be challenged.

Copyable board template

# Product Bet, Discovery ↔ Delivery Board

Product decision:
[...]

Desired outcome:
[...]

Material uncertainty / risk:
- Risk: [Value / Usability / Feasibility / Viability / Other: ______]
  Why it matters:

Cheapest credible evidence for each risk:
- [...]

Evidence we already have (observed facts only):
- [...]

Remaining uncertainty (what we still do not know):
- [...]

Commitment decision:
[keep learning before committing / narrow the bet / commit with open risk /
 deliver behind a guardrail or staged rollout / stop or change direction]

Why this level of commitment is justified:
[...]

Delivery safeguards (only where relevant):
- [...]

Production evidence to inspect:
- [...]

Reopen / stop trigger:
- [...]

Decision owner and contributors:
[...]

The board is designed to be used in a real Product review, not filed away. Keep it short enough that the team will actually update it.

The Discovery Intensity Router

The board tells you what you know. The router helps you decide how much discovery this bet actually needs, and it explicitly makes doing less discovery a legitimate outcome.

This is not a score and not a maturity model. It is a sequence of judgement questions.

The router as a sequence of questions

1. Is the decision expensive or hard to reverse?

  • If no → lighter learning may be justified.
  • If yes → inspect the major uncertainty before committing.

2. Is a material Product risk currently unknown?

  • If no → proceed with proportionate delivery.
  • If yes → choose the cheapest credible method that can actually update it.

3. Can that uncertainty be learned safely without production?

  • If yes → prototype, spike, research, or review before full delivery.
  • If no → consider controlled production learning.

4. Would a production experiment expose customers or the company to unacceptable harm?

  • If yes → do not “ship to learn.” Reduce the risk another way.
  • If no → a bounded experiment may be the right method.

5. What is the main unknown?

  • Technical feasibility → involve engineering now, through a spike or technical investigation.
  • Usability → use design and appropriate user evidence.
  • Value or behavior → use evidence appropriate to the decision; do not infer value from polite intent statements alone.
  • Viability → involve the function that owns the constraint (legal, finance, security, operations, sales).

6. Is the proposed work tiny, reversible and low risk?

  • If yes → avoid discovery theater and proceed.
  • If no → go back to question 1.

The router’s last branch matters as much as the first. A process that can only ever add discovery is not a decision system.

When discovery should be light

The old version of this advice implied discovery should always maintain a large pipeline ahead of delivery. That is wrong for a large share of real work.

Discovery can be light when the change is:

  • small;
  • reversible;
  • cheap;
  • already well understood;
  • supported by strong and relevant prior evidence;
  • best learned through production observation;
  • limited and controlled on the downside.

Typical examples:

  • a minor copy change;
  • a low-risk internal-tool improvement;
  • a small instrumentation change;
  • a reversible interaction refinement;
  • a bug fix where the desired behavior is already clear.

The important framing is proportionate learning, not “skip learning.” Even a tiny change usually has a cheap evidence loop: support-watch, a metric, or a quick check that the change did what you expected. What it does not need is a formal discovery stage that exists only to look rigorous.

When discovery should be deeper

More discovery is justified when:

  • the build is expensive;
  • migration is difficult;
  • the decision is hard to reverse;
  • user harm is plausible;
  • business viability is unclear;
  • an architecture commitment is large;
  • the target user or problem is genuinely uncertain;
  • the team holds conflicting evidence;
  • the opportunity cost is large;
  • regulatory, security or safety constraints are material.

Do not translate “higher stakes” into a fixed number of interviews or tests. Translate it into a question:

Which uncertainty could turn this commitment into a costly mistake, and what is the cheapest evidence that would materially reduce it?

That question points to the method. High stakes with a feasibility unknown points at an engineering spike. High stakes with a value unknown points at evidence about behavior and switching. High stakes with a viability unknown points at the function that carries the constraint.

Build-to-learn is sometimes the right choice

Some uncertainty can only be resolved in production or a realistic environment. Examples can include:

  • performance and reliability at real scale;
  • ecosystem and integration behavior;
  • real adoption over time;
  • network effects;
  • operational and support burden;
  • real payment and fraud behavior;
  • long-term retention;
  • third-party production dependencies.

SVPG frames this well: discovery is “building to learn,” delivery is “building to earn.” The phrase is commonly attributed to product coach Jeff Patton, and it captures why both activities build things but for different purposes. Crucially, the same source warns that this is a conceptual model, not a process, and that discovery and delivery are both continuous, we also learn from delivery.

So “never learn in production” is the wrong dogma. But so is “ship fast and see.”

The Build-to-Learn decision branch

Before choosing production as the learning method, answer these eight questions:

  1. What exactly can only production tell us?
  2. Can we reduce the risk more cheaply first?
  3. What is the minimum production scope that would still teach us what we need?
  4. Who is exposed, all customers, a cohort, opt-in users, internal users?
  5. What guardrails are required (limits, flags, circuit breakers, rollback, monitoring)?
  6. How will we roll back, and how fast?
  7. What evidence triggers expansion, change, or stop?
  8. What harms must not be experimented with casually?

If you cannot answer those, you do not have a build-to-learn plan. You have a hope. SVPG’s own principle is “test ideas responsibly,” precisely because customers who paid for a product should not feel like guinea pigs.

Controlled production learning means: bounded exposure, instrumentation, guardrails, a rollback path, and a written evidence plan. Ship-and-pray means none of those. The gap between them is the whole point.

One team, not two: the dual-track failure mode

The useful idea behind “dual-track” is simple and correct: discovery and delivery work can progress concurrently. A team does not have to finish all learning before any building starts.

The failure mode is equally simple and common: drawing two tracks produces two teams, two queues, and a waterfall handoff with better branding. One group obtains the learnings, writes them up, and “hands off” execution to another group. SVPG warns about exactly this anti-pattern and argues for a single, cross-functional product team responsible for both discovery and delivery.

A practical rule:

Use two kinds of work as a mental model, not two organizational silos.

The commitment boundary is where this matters most. Moving from “exploring options” to “committing production capacity” is a real decision, but it does not have to be a team handoff, and it should never be a document tossed over a wall.

Commitment boundary ≠ handoff

When work moves toward greater commitment, the context should travel with it. At minimum: the desired outcome; the relevant customer and problem evidence; important alternatives that were rejected and why; key assumptions; unresolved risks; the reason the current approach was chosen; the success and guardrail evidence; and the conditions that would reopen the decision.

If the people building the change cannot explain what would make them stop, the commitment boundary was really a handoff, and the team has lost the context it needs to make trade-offs during delivery.

Engineering belongs in discovery; Product and design belong in delivery

The old division of labor, PM and design discover, engineering delivers, is both inaccurate and expensive.

Engineering is especially important in discovery when the unknowns involve:

  • feasibility;
  • architecture;
  • performance;
  • integrations;
  • reliability;
  • data;
  • security;
  • migration;
  • technical constraints;
  • prototype or spike design.

A technical spike is discovery. An engineer reviewing a prototype is doing discovery. An engineer helping design a smaller, cheaper test is doing discovery. Judging feasibility risk without the people who will build the thing is one of the most reliable ways to commit to work that becomes far more expensive than expected.

The reverse also holds. Product and design belong in delivery, not just in the phase before it. During delivery they may need to participate in:

  • scope and trade-off decisions;
  • edge cases;
  • usability detail;
  • changed constraints;
  • rollout and instrumentation;
  • acceptance decisions;
  • new evidence that changes the bet;
  • customer and support communication.

When delivery reveals that the original bet must change, that is not automatically a delivery failure. It can be learning. The team should be able to act on it.

The collaboration pattern sometimes called a “product trio”, product, design and engineering working together on discovery and delivery, is a useful default in many product organizations. It is not a universal org chart. What generalizes is the principle: the people with the relevant knowledge make the relevant decisions, together.

Continuous discovery, defined precisely

“Continuous discovery” gets used loosely. Product Talk, the home of Teresa Torres’s work, defines it precisely: weekly touchpoints with customers by the team building the product, where they conduct small research activities in pursuit of a desired outcome. The definition has three requirements: the team building the product interacts with customers directly; research is small enough to fit alongside other work; and the work stays focused on outcomes.

That definition describes a specific, disciplined discovery practice. It is not the same thing as the broader relationship between discovery and delivery.

Keep the distinction clear:

  • Continuous discovery is a specific practice with its own cadence and habits.
  • The discovery↔delivery relationship is the operating boundary this page owns, how learning and production work interact around a bet.

A team can apply discovery continuously and still tailor the delivery boundary. A team can also run a focused discovery effort on one high-risk bet without adopting a full continuous cadence. Neither is a universal mandate, and “weekly touchpoints” should not be rewritten into “every Product team must run a fixed number of interviews per week.”

No universal recipe for timing or time split

Two questions come up constantly. Neither has a universal numeric answer.

“How many sprints ahead should discovery be?” There is no correct number. Discovery does not map neatly to sprint boundaries. Some bets need minutes or hours of learning; others need weeks or months. Multiple bets at different uncertainty levels can be in flight at once. Delivery constraints can create new discovery work immediately. Teams can learn from released product. And speculative discovery done far ahead of any plausible delivery capacity tends to go stale.

The better question is not distance. It is: do we have enough relevant evidence to justify the next level of commitment, and is that evidence still fresh enough to act on?

“What percentage of my week should be discovery?” There is no correct split either. It depends on the current risk, the stage, the team composition, the support available, the quality of current evidence, reversibility, and the size of the bets in front of the team. A team facing a major unknown should spend more effort learning. A team executing a well-understood migration should spend more effort delivering.

You will find directional observations, for instance, that PMs and designers often spend more of their time on discovery while engineers spend more on delivery, even though everyone participates in both. Treat that as a common pattern, not a target to hit. A fixed percentage turns a judgement question into a compliance exercise.

“Validated” is not a binary state

The word “validated” hides a lot. It implies certainty that almost never exists, and it makes a team stop thinking.

Instead, describe the state honestly:

  • evidence currently supports this;
  • material risk reduced;
  • remaining uncertainty is explicit and accepted;
  • enough evidence for this level of commitment;
  • evidence contradicts the bet;
  • unresolved, production evidence needed.

Use “validated” or “invalidated” only when the underlying test had a genuinely falsifiable claim and a clear result. Even then, say what was tested and what was not.

Two related traps:

  • A positive prototype result is stronger evidence, not a permanent verdict. Remaining risks stay explicit.
  • A shipped feature is not proof that the original assumption was correct. It proves the team can build and release. Whether the outcome moved is a separate question.

The same caution applies to feature-adoption rate. Adoption can show that people tried something. It does not by itself show that the intended outcome, activation, retention, revenue, reduced support load, actually improved. Usage and outcome are different questions.

The delivery feedback loop: shipping is not the end of learning

Delivery does not end at deployment. Treat release as the start of a decision loop:

release → observe → compare with the expected mechanism and outcome → inspect harms and guardrails → explain the discrepancy → continue / adjust / roll back / reopen discovery

Depending on the product, the evidence worth inspecting may include:

  • behavior and usage patterns;
  • support and success themes;
  • qualitative feedback;
  • performance and reliability;
  • commercial and revenue behavior;
  • operational burden;
  • safety signals;
  • retention;
  • downstream effects on adjacent systems or teams.

Use only what fits the product. The discipline is not the list; it is the comparison. State the mechanism you expected, then look for whether it happened. If the feature was adopted but the outcome did not move, the question is not “did the feature work?” It is “did our theory of how the feature creates value hold up?”

The same loop is how a team avoids post-launch amnesia: someone owns the review, the expected outcome is stated before release, and the evidence is actually looked at afterward.

Signals your discovery and delivery system is unhealthy

Benchmarks with fixed target ranges are usually fake precision. What is genuinely useful is a set of diagnostic signals, patterns that tell you something in the system is broken.

Delivery starts with major unanswered value or problem questions. Interpretation: commitment happened before relevant learning.

Discovery produces documents but does not change decisions. Interpretation: activity without decision impact.

Engineers discover core feasibility constraints after a large commitment. Interpretation: technical risk entered too late.

The discovery backlog grows far beyond any plausible delivery horizon. Interpretation: speculative, likely-to-go-stale discovery.

Production evidence contradicts pre-build assumptions, but the plan continues unchanged. Interpretation: the learning loop is broken.

Delivery repeatedly waits for “requirements.” Interpretation: weak context, collaboration, or commitment boundary.

Research cannot access real users. Interpretation: a system constraint, not something to paper over with invented confidence.

Every idea is “validated.” Interpretation: the tests may not be discriminating, or the language has lost meaning.

These are signals to investigate, not KPIs with universal targets.

Team-level measures, if you keep any

Most discovery “metrics” are vanity. If a team wants measures, prefer ones it can define locally and use for its own trend, not for external comparison.

  • Decision lead time, time from an important uncertainty being identified to a decision. Use it to find bottlenecks, not to publish a target.
  • Rework caused by late-discovered assumptions, track examples and categories. The value is in naming the pattern, not in hitting a number.
  • Share of major bets with an explicit outcome, risks, and reopen condition, useful only if the team actually finds it useful.
  • Post-release decision completion, was the expected outcome and guardrail evidence actually reviewed?

Avoid measures that reward activity rather than decision quality: interviews per week, insights per hour, “validation rate,” or the share of features that were “predicted correctly.” Those numbers go up when teams get better at performing process, not necessarily when they make better bets.

Copyable artifact: the Product Bet Review

The old version of this article offered a fixed weekly calendar. A calendar is a weak substitute for a decision. Replace it with a short review built around the board.

# Product Bet, Discovery ↔ Delivery Review

Decision / bet:
[...]

Desired outcome:
[...]

Current commitment:
[Exploring / preparing to commit / delivering / released / revisiting]

Material uncertainty:
- [...]

Risk type:
[Value / Usability / Feasibility / Viability / Other]

Evidence we already have:
- [...]

Cheapest credible next learning:
- [...]

What we do NOT need to learn before proceeding:
- [...]

Open uncertainty we accept:
- [...]

Why the next level of commitment is / is not justified:
[...]

Delivery safeguards:
- [...]

Production evidence to inspect:
- [...]

Reopen / stop trigger:
- [...]

Decision owner / contributors:
[...]

Two fields do the heavy lifting. “What we do NOT need to learn before proceeding” prevents research paralysis by naming what is deliberately out of scope. “Open uncertainty we accept” makes the risk explicit instead of pretending it does not exist.

Worked cases

These examples are hypothetical. They are included to show how the model changes the decision at different risk profiles, not to describe any specific company.

Case 1: An enterprise onboarding bet

Decision: Improve enterprise workspace activation.

Initial proposed solution: Add an onboarding wizard.

Current evidence: Activation lag exists. Support sees setup questions. The cause is not yet clear.

Material risks:

  • Value / mechanism, will a wizard solve the real delay?
  • Usability, can admins understand the setup path?
  • Feasibility, can permissions and integrations be simplified?
  • Viability, do enterprise security requirements constrain the approach?

Discovery work: inspect behavioral drop-off; talk to relevant admins; prototype the critical flow; have engineering investigate the permissions constraints.

Learning: The delay is partly caused by an external approval and security process, not UI confusion alone.

Commitment change: Do not build the full wizard. Narrow to clearer trust and security explanation, an admin checklist, and a better status state.

Delivery: Build the smaller change with instrumentation.

Production evidence: Some accounts progress faster. Highly regulated accounts still stall.

Reopen discovery: Investigate the approval workflow and stakeholder coordination.

The lesson: discovery did not “validate a feature.” It changed the Product bet.

Case 2: A low-risk reversible change

Situation: A label in a low-risk internal settings screen is confusing.

Evidence: repeated support confusion; the semantics are clear once understood; implementation is trivial; rollback is easy.

Decision: Do not run a multi-week discovery project.

Action: change the copy, watch support, observe.

Lesson: Not every Product change deserves a separate discovery phase. Proportionate learning is enough.

Case 3: A technical feasibility bet

Situation: A real-time collaboration feature.

Main unknown: architecture and performance at the required scale.

Discovery work: a technical spike, a load experiment, architecture options, and a Product/design conversation about acceptable latency and degradation.

What not to do: ask a handful of users to “validate” feasibility. Feasibility risk is tested with engineers, not with users.

Lesson: Method follows risk. The risk was technical, so the discovery method was technical.

Case 4: A ranking change learned in production

Situation: A new recommendation ranking.

Why prototypes are insufficient: offline and prototype evidence cannot establish real interaction behavior, downstream engagement, or guardrail effects.

Commitment: a bounded cohort, full instrumentation, a rollback plan, and clear guardrails.

Learning: the team learns in production, deliberately, with a hypothesis, not by shipping broadly and hoping.

Lesson: Controlled production learning is a legitimate method. Ship-and-pray is not. The difference is the plan.

Decision clinic: common situations

Use these as quick routing rules when a real question comes up.

“What percentage of my week should be discovery?” There is no universal percentage. Route by the material uncertainty in front of the team and the reversibility of the bet. See No universal recipe for timing or time split.

“How many sprints ahead should discovery be?” No universal distance. Judge whether the evidence is sufficient and still fresh enough for the next level of commitment.

“This change is tiny and reversible, do we really need discovery?” Not necessarily. Use proportionate learning and observe.

“Our prototype evidence was positive.” That is stronger evidence, not a permanent verdict. Keep the remaining risks explicit.

“Delivery uncovered an architecture constraint that changes the plan.” Reconnect discovery and delivery. The Product bet and scope can legitimately change.

“We shipped, but adoption is low.” Use production evidence to reopen the interpretation. Do not automatically label it a discovery failure.

“We shipped, adoption is high, but the outcome did not move.” Separate usage from intended outcome and mechanism. High adoption is not the same as a solved problem.

“We have twenty researched ideas ready two quarters ahead.” Flag speculative discovery inventory. Research done far from a decision tends to go stale.

“Leadership already mandated the solution, and we are running interviews afterward.” Name this honestly: discovery theater. The research cannot change the decision, so the real problem is the decision process, not the method.

“We cannot access users.” Name the system constraint and choose alternative evidence where it is valid. Do not invent confidence you do not have.

“The area is regulated or high-harm.” Use controlled, risk-specific learning and involve specialists. Do not “ship to learn” casually.

“Production is genuinely the only realistic environment.” Use a bounded build-to-learn plan with guardrails, rollback, and an explicit evidence plan.

“We have no material uncertainty on this.” Proceed. Do not invent discovery work to satisfy a process.

If the next job is a specific discovery method rather than a commitment decision, running interviews, mapping opportunities, testing assumptions, or prioritizing among understood bets, route to the appropriate owner: the Product discovery interview script guide, the Opportunity Solution Tree, or prioritization frameworks.

Anti-patterns that break the loop

Each of these is tied to a real decision failure, not to taste.

Discovery theater, research happens after leadership has already committed to the solution. The activity cannot change the decision.

Validation theater, methods are designed to confirm the preferred idea rather than to test it.

Two-team waterfall, a discovery team hands documents to a delivery team, and context is lost at the boundary.

Research paralysis, the team refuses to commit until uncertainty is impossible, which never happens.

Delivery dominance, every urgent sprint pushes discovery to “later,” until the team is shipping on assumptions no one has examined.

Speculative discovery inventory, a large backlog of researched ideas goes stale before capacity exists to act on any of them.

Feasibility too late, engineering sees the key constraints only after the Product commitment is made.

Ship-and-pray, production is used as an experiment without a hypothesis, guardrail, or rollback.

Post-launch amnesia, the feature ships and no one checks whether the expected outcome or mechanism occurred.

Ceremony without decisions, meetings, interviews, and prototypes happen, but the decisions stay exactly the same.

Cadence: patterns, not laws

There is no universal discovery cadence. Teams legitimately use async evidence updates, a weekly Product review, continuous day-to-day collaboration, sprint planning, a Kanban flow, or irregular risk reviews. A dedicated research cadence works for some teams and is overkill or impossible for others.

The test is not which rhythm you choose. It is whether the rhythm:

  • keeps meaningful uncertainty visible;
  • keeps it close enough to the decision to matter;
  • produces decisions rather than ceremony.

A cadence that generates meetings without changing decisions is worse than no cadence, because it consumes the time that could have reduced a real risk.

Small teams and large organizations

Small teams may have a founder and an engineer, a design-minded founder and engineers, or a PM and an engineer, with no dedicated researcher. They do not need to imitate a large-company discovery org. They do need to: identify meaningful uncertainty, choose evidence proportionate to risk, keep technical input early, ship deliberately, and inspect results. Roles can be combined; the decisions cannot be skipped.

Larger organizations may involve user research, data, security, legal, compliance, operations, product marketing, architecture, and support. Two failure modes appear here.

First, discovery becomes “the PM personally does all research.” It should not. Specialists can own craft while the Product team retains the decision context.

Second, delivery becomes “context disappears into engineering.” It should not. The same Product team stays responsible for the outcome even when specialists contribute to both kinds of work.

The organizing principle is the same at both sizes: one Product team owns the learning and the outcome, however many specialists help along the way.

Frequently asked questions

Is discovery always before delivery?

No. Discovery often starts before a commitment, but it continues during design, during technical exploration, during delivery, after a partial rollout, and after full release. The loop is continuous; the gate model is not.

Do we need separate discovery and delivery teams?

No, and separating them is a common source of context loss and weak ownership. A single cross-functional Product team should be responsible for both learning and production outcomes. Specialists can contribute to one side without splitting the team.

How much discovery is enough?

Enough to justify the next level of commitment at an acceptable level of consequence. That depends on the risk profile and on how expensive or hard to reverse the decision is. There is no fixed number of interviews, prototypes, or sprints.

Should we ever learn in production?

Yes, when the uncertainty genuinely cannot be resolved elsewhere and the exposure can be bounded safely. Use a controlled build-to-learn plan: minimum scope, guardrails, rollback, and an explicit evidence plan. Do not expose all customers to an untested idea to “see what happens.”

What if we cannot access users?

Treat it as a system constraint to solve or work around with the best available evidence, behavioral data, support data, sales or success input, or internal expert review. Do not substitute invented confidence for access.

How do we know our discovery and delivery system is working?

Look for whether decisions change when evidence arrives, whether feasibility risk enters early, whether production evidence is reviewed, and whether discovery output actually informs commitments. The diagnostic signals are more useful than a single score.

Is dual-track agile the same as continuous discovery?

No. “Dual-track” usually describes running discovery and delivery work concurrently. Continuous discovery is a specific practice, weekly customer touchpoints by the team building the product, using small research activities in pursuit of a desired outcome. They are related but not interchangeable.

References and further reading

These are methodology and point-of-view sources, not empirical universal law. Use them to sharpen judgement, then apply it to your own context.

When you want to build the underlying capability rather than answer one commitment question, continue with the Product Discovery course. When you are deciding what a Product Manager is accountable for across these activities, the product manager responsibilities guide covers that boundary.

Primary topic: Product delivery and execution

Delivery and execution turn strategy into shipped outcomes through clear scope, rapid iteration, strong collaboration, and disciplined follow-through from discovery to release.

Explore the full Product delivery and execution hub

Key terms

Recommended courses

From the blog

Build the full discovery system

Turn the operating boundary into a repeatable discovery practice

This page helps you decide how discovery and delivery interact around a Product bet. Use the Product Discovery course when you need the end-to-end system for framing questions, recruiting, choosing methods, synthesizing evidence, mapping opportunities, testing assumptions, and turning learning into Product bets.

Learn Product DiscoveryMap the opportunity
Portrait of Andrea Mezzadra, author of the blog post

Andrea Mezzadra@____Mezza____

Published on October 14, 2025 • Updated on September 25, 2026

Ex Product Director turned Independent Product Creator.