The Most Important Distinction Most Teams Get Wrong
Walk into a typical product team and ask what they are working on. You will hear a list of features in flight, sprints they are executing, and dates they are aiming for. Ask the same team what they are learning, what they are uncertain about, what they are validating, and you will often get a confused look. The team is doing one half of product work fluently and the other half barely or not at all.
The two halves are discovery and delivery . They are fundamentally different activities, with different goals, different rhythms, different artefacts, and different definitions of success. Teams that conflate them end up either delivering features that miss the mark, or running endless research without ever shipping. Teams that run both deliberately and in parallel are the ones that consistently produce products that work.
Marty Cagan and Teresa Torres have done more than anyone to popularise this distinction in the modern product community. The framing here owes much to their work, especially Cagan's books Inspired and Empowered and Torres's book Continuous Discovery Habits. We have lived the distinction in our own teams for two decades and watched it transform mediocre product organisations into great ones.
Defining Each Mode Precisely
Discovery: Reducing Uncertainty Before You Build
The goal of discovery is to reduce the risk that the team will spend three months building something that does not work. The currency is learning. The artefact is decisions about what is worth building, with confidence levels attached. The success metric is not features shipped; it is hypotheses validated or killed cheaply.
In discovery you are doing things like: talking to customers, watching them use prototypes, analysing data to find patterns, running small experiments, building wireframes to test concepts, or shipping the smallest possible test of an idea to a small audience. None of these activities ship the actual product. They tell you whether the actual product is worth shipping.
Discovery work is messy and ambiguous by nature. The output of a good discovery week may be that you killed an idea that the team was about to commit a quarter to. Externally, this looks like nothing happened. Internally, it saved twelve weeks of wasted engineering. PMs who do not understand the value of discovery feel guilty during it because nothing visible is shipping. PMs who do understand it feel proud, because they are getting paid to prevent waste.
Delivery: Building It Well
The goal of delivery is to take a validated idea and turn it into shipped software that works reliably, scales gracefully, and is maintainable over time. The currency is working code. The artefact is product in users' hands. The success metric is shipped functionality that meets the quality bar.
In delivery you are doing things like: writing detailed requirements, planning sprints, coordinating engineering and design, running standups, doing acceptance testing, managing the release, and reviewing post-launch performance. These activities produce visible progress and are how most teams measure themselves.
Delivery work is structured, predictable in shape, and rewards operational excellence. A good delivery week ships planned work with no surprises. Externally, this looks like the team is productive, which they are. The risk is that delivery excellence becomes the only excellence, and the team starts shipping things that should never have been started. This is the most common failure mode of mature product teams.
Why the Distinction Matters
If you collapse the two modes, several specific bad things happen. Each is common. Each is preventable.
Failure Mode One: Delivery Without Discovery
The team executes very well on a backlog full of features that nobody validated. They ship on time. The features get adopted at low rates. Metrics do not move. Leadership starts asking questions. The team responds by working harder on delivery: tightening sprints, adding more requirements detail, refining estimates. None of it helps because the problem is not delivery. The problem is that the team is delivering things that were not worth delivering. This is the single most expensive failure mode in product management. Companies pour years of engineering into it.
Failure Mode Two: Discovery Without Delivery
The team is constantly researching, prototyping, interviewing, and experimenting. Workshops abound. Insight documents proliferate. But nothing ever ships, because every idea spawns another round of discovery before commitment. The team feels intellectually busy but produces nothing for the business. This is rarer than the first failure mode but it does occur, especially in newer or design-led teams that fall in love with research as a process.
Failure Mode Three: Sequential Discovery and Delivery
The team does discovery for a quarter, then delivery for two quarters, then discovery again. This is better than either of the first two failure modes but it has its own problems. By the time delivery starts, the discovery insights are stale or assumptions have changed. By the time discovery resumes, the team has been out of the customer's head for six months and has to rebuild context. The right approach is continuous parallelism, not alternation.
How the Two Modes Run in Parallel
The simplest way to think about the parallel rhythm is that, at any moment, your team is doing both. While Feature A is in delivery, Feature B is in discovery. While B is being shipped, C is being researched. The discovery and delivery threads are continuously flowing, with the PM acting as the dispatcher who decides what moves from discovery to delivery and what does not.
Aspect Discovery Mode Delivery Mode
Goal Reduce risk of building wrong things Build the right thing well
Currency Learning and validated insights Working software in users' hands
Time horizon Days to weeks per cycle Sprints to quarters per release
Output Decisions about what is worth building Shipped features and improvements
Definition of done Hypothesis validated or killed cheaply Feature meets quality bar in production
Primary risk Spending time on insight that goes Shipping things that should not be
unused shipped
Who leads PM with designer and researcher PM with engineering and design as full
partners partners
Typical artefact Opportunity briefs, prototypes, research PRDs, designs, code, release notes
notes
Discovery Techniques That Work
Discovery is not just do user research . It is a portfolio of techniques, each suited to different kinds of risk. The mature PM has fluency in several and can pick the right one for the question they are trying to answer. Here are the techniques we use most often.
Customer Conversations
The cheapest, most consistently valuable discovery activity. Talk to five to ten users about a problem space. Not do you want this feature , but tell me about the last time you tried to do this and what happened . The goal is to understand the problem, not test the solution. Done well, this surfaces the real problem and disqualifies many proposed solutions before any code is written.
Prototype Testing
Build a low-fidelity prototype, often in design tools, and put it in front of users. Watch them try to use it. Listen for confusion. Most teams discover within five sessions that their solution has fundamental issues that would have taken months to surface in production. The cost is a few days of design time.
Concierge Tests
Manually deliver the value of a feature to a small number of users without building any of it. If you are considering an automated report, send a few users a manually-built version and see if they use it, share it, and ask for more. If they ignore your hand-built version, your automated version will not save the situation.
Wizard of Oz Tests
Build the user-facing interface of a feature but power it with humans behind the scenes rather than the eventual automation. Useful when the underlying system is expensive to build but the interface is cheap to mock. Lets you test the experience and demand before committing engineering resources.
Data Analysis on Existing Behaviour
Often overlooked. Before assuming users want a new flow, look at what they currently do. Are they finding workarounds? Are they abandoning at certain steps? The existing behaviour usually contains evidence about what the real friction points are. PMs who skip this step often build solutions to imaginary problems while real problems sit in plain sight in the data.
Painted Door Tests
Add a button or link for a feature that does not yet exist. Track how many users click it. Show them a message acknowledging the interest and offering to follow up. Useful for testing demand before building anything. The risk is reputational if used too often or for major workflows; use sparingly.
Delivery Practices That Work
Delivery is more standardised than discovery, and most product organisations have established practices for it. We will cover these in detail in later articles. For now, the high-level points are:
- 1. Detailed enough requirements. The team needs sufficient specificity to start building, but not so much that the spec becomes obsolete the moment users try the feature. Most PMs over-specify.
2. Continuous collaboration with engineering and design. Delivery is not a hand-off. The
PM stays engaged through the build, answering questions, making trade-off calls, and adjusting as edge cases surface.
- 3. Quality bar discipline. The team agrees in advance on what "done" means: not just feature complete, but performant, accessible, observable, and tested. Pressure to ship faster always exists. The PM is the steward of not letting the bar slip in unprincipled ways.
- 4. Launch craft. The launch itself is part of delivery. A feature that ships without proper rollout, monitoring, and communication can fail in users' hands even if the code is good.
- 5. Post-launch follow-through. Delivery does not end at launch. The team monitors performance, fixes urgent issues, and feeds learnings back into discovery for the next iteration.
The PM's Role in Each Mode
In Discovery
The PM is usually the lead. They identify the most important questions to answer, design the discovery activities, run the customer conversations, synthesise the findings, and make the judgment call about what graduates to delivery. Designers and researchers are essential partners, especially in usability testing, but the PM owns the integration of insights into a decision.
In Delivery
The PM is one of three equal partners with engineering and design. The PM continues to make trade-off decisions as questions come up, but engineering owns how things are built and design owns how things look and feel. The PM's contribution in delivery is primarily to keep the team aligned to the original intent, surface stakeholder questions early, and adjust scope honestly when reality diverges from plan.
How to Establish a Healthy Discovery Cadence
If your team currently does little or no discovery, the way to introduce it is gradually and with low ceremony. Big-bang research programs fail. Small, repeated habits succeed.
Week One: Three Customer Conversations
Block three hours this week for customer conversations. Pick three users at random from your active base. Ask them to describe their last week of using the product. Listen. Take notes. Do not pitch anything. At the end of the week, write a one-page summary of what you heard.
Week Two: Repeat, with a Theme
Same three conversations, but now with a specific theme: tell me about the moments this week where the product frustrated you . Or: walk me through your morning workflow . The theme focuses your listening without scripting the conversation.
Week Three: Bring in a Prototype
Sketch or build a low-fidelity prototype of something you have been considering. Put it in front of three users in conversational settings. Watch their reactions. Notice where they get confused. Notice where their eyes light up. Notice what they ignore.
Week Four: Establish the Habit
By now you have done twelve customer touchpoints in a month. Establish a calendar block: every Tuesday afternoon, you do discovery work. Defend it. Once it is established, your team starts asking you what you have heard, which raises the discovery discipline of the whole team.
When Discovery Should Slow Down
Discovery is not always the right answer. Some moments call for more delivery and less discovery. The mature PM recognises these moments rather than defaulting to one mode.
- When a market window is closing fast and a competitor will capture the opportunity if you delay further. Imperfect action beats perfect insight delivered too late.
- When the team has already validated the problem and the solution and is in execution mode. More discovery here is procrastination wearing a serious face.
- When you are scaling a known solution into a new geography or segment where the underlying needs are well understood. Adapting is delivery work, not discovery work.
- When the discovery you would do would not change the decision because the cost of being wrong is small. Sometimes you ship to learn, because the experiment is the cheapest research.
When Delivery Should Slow Down
Conversely, certain signals indicate that delivery should pause and discovery should intensify.
- When two consecutive features have shipped on time and missed their outcome targets. The pattern says the team is solving the wrong problems, and more discovery is the fix.
- When stakeholder requests are arriving faster than the team can evaluate them, suggesting that the strategy is unclear and discovery on direction is needed.
- When user research surfaces a fundamental change in user behaviour or context that invalidates current assumptions. The roadmap may need to be reshaped before more is built on the old assumptions.
- When the team is repeatedly surprised by edge cases that are breaking the current architecture. Often the answer is more discovery into how users actually work, not just better code.
A Final Word
Most product organisations would benefit from doing twice as much discovery and the same amount of delivery. They do not, because delivery is visible and discovery is invisible, and most organisational pressure rewards visibility. The PM is the person responsible for resisting that pressure where it produces bad outcomes, and for making discovery visible enough through writing and shared learning that the team starts to value it as much as shipped features.
Run both modes, run them in parallel, and protect the discovery thread when execution pressure threatens it. Two years of doing this consistently will put your team in the top decile of products in your category. Five years of doing it will put you in the top one or two percent.
Key Takeaways
- Discovery and delivery are different activities. Discovery reduces risk of building wrong things; delivery builds the right things well.
- They should run continuously and in parallel, not sequentially. At any moment, some features are in discovery and others are in delivery.
- The most common failure mode is delivery without discovery, which produces shipped features that do not move outcomes.
- Discovery techniques include customer conversations, prototype testing, concierge tests, painted door tests, and existing-data analysis. Match technique to the type of risk.
- Senior PMs spend twenty to thirty percent of their time on active discovery. New PMs should grow into this gradually with small, repeated habits.