What each path looks like
Starting development immediately means the team takes your brief, sets up the project and begins building the first features. Questions are answered as they come up. When the brief is right, this is the fastest route to working software.
Product discovery is a short phase before the build. The team talks to users and stakeholders, maps the process, tests a prototype and examines the technical unknowns. It ends with a prioritized scope, a design direction, an architecture outline and an estimate that rests on something.
The two paths at a glance
| Start development now | Discovery first | |
|---|---|---|
| First output | Working features, early | Decisions, a prototype and a plan |
| What it assumes | The brief describes the right product | The brief is a hypothesis to test |
| Main risk | Building the wrong thing well | Spending time on analysis that changes nothing |
| Estimate quality | A guess that firms up as work proceeds | A range grounded in an agreed scope |
| Cost of a wrong turn | Rework in code, which is the expensive place to learn | Rework in a prototype, which is the cheap place |
| Stakeholders | Aligned as features appear, sometimes painfully | Aligned before money is committed to the build |
| Suits | Small, familiar, well-specified work | New products, unclear scope, many voices or technical unknowns |
When each one fits
Start development now when
- You are rebuilding or extending something that already works
- The scope fits on a page and nobody disputes it
- Users have already been observed or interviewed
- The technology is familiar to the team
- A wrong turn would cost days, not the project
Run discovery first when
- The idea has not been shown to a single real user
- Stakeholders describe the product differently
- The feature list is long and nothing is ranked
- There is a technical question nobody can answer yet
- You need a credible budget before you can get approval
What a discovery phase should produce
Judge discovery by what you hold at the end. If the list below is not in your hands, it was a meeting series, not discovery.
- The users and their jobs. Who the product is for and what each needs to get done, from conversations, not from guesses.
- A ranked scope. What is in the first release, what waits and what was dropped, with the reason for each.
- A tested prototype. The main journey as clickable screens, tried by a few real users.
- The technical outline. Architecture, integrations and the risks that could change the estimate.
- An estimate as a range. With the assumptions behind it written down.
- A plan for the first release. Ordered so that the riskiest part is built first.
All of it should be usable by any competent team, not only the one that ran the discovery. Our software requirements document template shows the level of detail to expect.
How to keep discovery short
- 01
Fix the length before it starts
A set number of working sessions and a date for the outputs.
- 02
Name the questions
List the specific unknowns to resolve. Anything else waits.
- 03
Prototype early
A rough clickable flow in the first days gives everyone something to react to.
- 04
Talk to few users, but real ones
A handful of conversations with the right people beats a survey.
- 05
Decide in the room
Have the person who owns the budget present when scope is ranked.
- 06
End with a build plan
The last session agrees the first release, not a list of further studies.
A worked example
A booking tool and a marketplace idea
Both projects are invented.
- The booking toolA dental group wants online booking added to its existing patient system. The process is known, the screens are few and staff have listed exactly what they need.
- Its decisionDevelopment starts at once, with a one-day kickoff to confirm the list. There was nothing left to discover.
- The marketplaceA founder wants to connect event organizers with local suppliers. She has a list of 60 features and has not yet spoken to a supplier.
- Its decisionDiscovery first. Interviews showed suppliers would not pay a listing fee but would pay per confirmed booking, which changed the product and cut the first release to a third of the list.
The dental group already had its answers. The founder had questions disguised as a feature list.
A checklist to decide
Tick what is true today. The first four mean you can start building. Any of the last four is a reason to run discovery first.
Build now or discover first
0 of 8 checkedWhat to do next
Write the product in one paragraph and ask three colleagues to do the same without conferring. If the paragraphs match, start building. If they differ, that gap is what a discovery phase closes. Our product discovery workshops page describes how we run one.
If you want an outside opinion on whether you need one at all, send us the brief. When the brief is ready to build from, we will tell you so.
Common questions
Is discovery just a way to charge more before building?
It can be, which is why its length and outputs should be fixed in advance. A sound discovery phase is short, has named deliverables and leaves you with material any team could build from. If a proposal describes discovery as open-ended, or its outputs are useful only to the company that wrote them, treat that as a warning and ask for it to be tightened.
How long should a discovery phase take?
It should be a small fraction of the build it prepares. For a first version of a product, think in weeks, not months. The right length depends on how many open questions there are, so list them before you agree a duration. When the questions are answered, discovery is over, even if the calendar says there is time left.
Can we run discovery ourselves?
Yes, if you have people with the time and the skills: someone to interview users, someone to design and test a prototype, and someone to judge technical feasibility. Many teams do part of it in-house and bring in help for the prototype or the architecture. What matters is that the outputs exist before development starts, whoever produces them.
What if discovery shows the product should not be built?
Then it has paid for itself several times over. Finding out before the build that customers will not pay, that the process cannot be automated as imagined, or that an existing product already does the job is the best outcome a small early budget can buy. More often discovery changes the product and shrinks the first release, which also saves money.
