Discovery Phase vs Product Discovery: Which One Do You Mean?
ยท 6 min read
"Discovery" means two different things in software. A discovery phase is a bounded step at the start of a project, usually a few weeks, that ends with an agreed scope, an estimate and a plan. Product discovery is an ongoing habit of a product team: talking to users every week and testing ideas before building them. Most confusion comes from using one word for both.
Two meanings of "discovery"
The two ideas grew up in different worlds. The discovery phase comes from project delivery: agencies, consultancies and public-sector teams who need to decide whether and how to build something before committing a budget. Product discovery comes from product management in companies that run their own product for years and need to keep deciding what to build next.
Both share a goal (avoid building the wrong thing) and some methods (interviews, journey maps, prototypes). They differ in who runs them, how long they last and what they produce.
| Discovery phase | Product discovery | |
|---|---|---|
| Shape | A project step with a start and an end | A continuous habit, no end date |
| Typical length | A few weeks (the UK government's service manual cites 4-8 weeks as typical for public services) | Ongoing, often with weekly user contact |
| Who runs it | A small discovery team, often an agency with the client | The product team: product manager, designer, engineer |
| Main question | What should we build, and what will it take? | Which problem should we solve next, and will this solution work? |
| Output | Written scope, requirements, architecture sketch, estimate, roadmap, risks | Validated (or rejected) ideas, a prioritised backlog of opportunities |
| Paid for as | Often a separate fixed-price engagement | Part of the team's normal work |
| Ends with | A go / no-go decision on the build | It does not end |
Discovery phase: a bounded project step
A discovery phase answers "should we build this, and if so, what exactly?" before the expensive part starts. The GOV.UK service manual describes it as understanding the problem before committing to a solution, says that you should not start building the service during discovery, and notes that stopping at the end of discovery is not a failure.
In a client project, the phase usually produces a set of documents someone can act on:
- Stakeholders and who signs off
- Background, problem statement and goals with metrics
- Users, journeys and key flows
- Requirements with priorities and acceptance criteria
- A first architecture picture and the decisions behind it
- A roadmap with estimate ranges, assumptions and risks
The discovery phase template lists these sections with what belongs in each, and the discovery phase in software development article walks through the steps in order.
The last of those documents is what makes the phase a bounded step: a plan with milestones, an estimate range and the assumptions behind it. In the example report, built for an invented field-service project called Fieldwise, it looks like this:
The phase is a good fit when there is a decision to make about money: a client choosing whether to fund a build, a vendor needing a scope it can price, a board needing a business case.
Product discovery: an ongoing habit
Product discovery assumes the product already exists, or will exist for a long time, and that the team owning it keeps choosing what to change. Its job is to reduce the risk that a feature is not valuable, not usable or not feasible before the team spends weeks on it.
Teresa Torres, whose book Continuous Discovery Habits popularised the term, defines continuous discovery as, at a minimum, weekly touchpoints with customers by the team building the product, where they run small research activities in pursuit of a desired outcome. Typical activities:
- Short customer interviews, every week rather than in a batch
- Mapping the opportunities (needs and pain points) behind a business outcome
- Testing the riskiest assumption of an idea with a prototype or a fake door
- Comparing several solutions for the same opportunity before choosing one
There is no final document. The output is a stream of decisions: build this, drop that, test the other next week.
How they fit together
They are not rivals; they sit at different points in a product's life.
- Before the first build, a discovery phase sets the scope, the plan and the budget. Its user research is deep but happens once.
- During the build, the team keeps the discovery documents current: when a requirement changes, the goals and estimates it touches are checked again.
- After launch, the product team switches to continuous product discovery to decide what comes next, using the goals and metrics from the discovery phase as the starting outcomes.
A large new feature on a live product can need a small discovery phase of its own, for example when it needs a separate budget, a new integration or a new vendor. And a discovery phase borrows product-discovery methods: interviewing users, mapping journeys and testing a rough prototype are common in both.
A sign that the two are mixed up: an agency is asked for "product discovery" and delivers a fixed two-week engagement with a report, or a product team is asked for a "discovery phase" on every feature and ends up writing documents nobody needs.
Which one you need now
Answer three questions:
- Is there a funding or contract decision ahead? If someone has to approve a budget, sign a statement of work or pick a vendor, you need a discovery phase. Its output is what they decide on.
- Does a product and a team that owns it already exist? If yes, and the question is what to improve next, you need product discovery as a habit, not a one-off project.
- Is the scope unknown, or is the value unknown? An unknown scope (what exactly are we building, what does it connect to, what will it cost) calls for a discovery phase. An unknown value (will users want this, will it move the metric) calls for product discovery.
If you are starting from zero with an outside team, it is usually both in sequence: a discovery phase now, product discovery after launch. Before the phase ends, run the discovery phase checklist to see whether every part has an answer.
For the discovery-phase side, Discovery Phase AI drafts the documents from material you already have (decks, notes, call transcripts, images) and keeps them as one project you can check and export; the example report shows the result for an invented project. Product discovery, by contrast, depends on talking to users every week, and no document replaces that.