BYD TechThe short answer
A discovery phase is a separate, paid piece of work before development, where you and the team agree what problem you are solving, for whom, and what the first version should include. It should end with written outputs you keep: the problem and users, a scope that says what is out, the biggest risks, clickable flows or a prototype, a technical approach and an estimate built on stated assumptions. Its real product is a decision: build this, build something smaller, or do not build yet.
Key points
- Discovery turns an idea into a problem, a scope, a list of risks and an estimate you can check, before anyone writes production code.
- Good outputs are written down and yours to keep, so you could take them to another team.
- An estimate is only as good as the assumptions printed next to it. Ask to see them.
- Stopping or shrinking the idea after discovery is a result, not a failure.
- You can skip it, or keep it small, when the problem is proven and the first version is simple and clearly specified.
- A PRD and a prototype are often outputs of discovery, not substitutes for it.
What a discovery phase is
Discovery is the work done before development to understand the problem well enough to decide what to build. Studios call it different things: discovery, scoping, an inception phase, a product workshop or a discovery sprint. Judge it by what you get at the end, not by the name.
It usually starts with a solution in mind, such as “we need an app that does X”. Part of the job is to turn that back into a problem. The UK government’s service manual gives a good example: the task is not “build an interactive map of our offices”, it is “help people find their nearest office when they need an appointment”. Framed that way, the answer might be a map, a search box or a better email.
Discovery is research and decision-making, not development. The same manual says plainly that you should not start building in discovery, and that stopping at the end of it is not a failure if the research shows that is the right call. The USDS Discovery Sprint Guide, written for US government teams, describes discovery sprints the same way: the aim is to find root causes and opportunities, not to fix them while you are still looking.
What a discovery phase should produce
Not every project needs every item, but a discovery for a new product should leave you with most of these, in writing:
| Output | What it contains | Why it matters |
|---|---|---|
| Problem statement | Who has the problem, how they handle it today, and what it costs them | Stops the team building a solution to the wrong problem |
| Users and their jobs | The main user types, what each is trying to get done, and the flows they need | Keeps the first version about people, not features |
| Scope | What the first version includes, what it leaves out, and what waits for later | The “out” list prevents most of the arguments later |
| Risks and assumptions | What could make the product fail or the build harder, ranked, with how each will be tested | Tells you where to spend effort first |
| Clickable flows or a prototype | The key screens linked together, ideally tried by real users | Lets you see and test the product before it is built |
| Technical approach | How it will be built, what it connects to, where the data lives, and any proof of concept for a risky part | Surfaces integration and data problems while they are cheap to solve |
| Estimate and plan | Effort for the scoped version, the order of the work, and the assumptions behind both | Gives you something you can compare and hold the team to |
| Recommendation | Build as scoped, build something smaller, test something first, or stop | This is the decision you bought |
A product requirements document often pulls the problem, users, scope and flows together in one place; How to write a PRD covers what goes in it.
How a discovery phase usually runs
The order matters more than the length. A typical sequence:
- Agree the goal of the discovery and who on your side makes decisions. Without a decision-maker in the room, discovery produces options, not answers.
- Collect what already exists: research, spreadsheets, an old version of the product, competitors your users mention, and any rules your industry works under.
- Talk to users, or to people who will become users. Ask how they deal with the problem today, not whether they like the idea.
- Map the main flows and agree the first version’s scope, including what is left out.
- Test the riskiest technical assumption. If the product depends on an outside API, a data source or an AI feature behaving well, try it before committing to the plan.
- Build clickable flows for the key journeys and put them in front of a few real users.
- Write up the scope, risks, technical approach and estimate, with the assumptions behind each.
- Walk through the results together and make the decision: build, shrink, test further or stop.
Prototypes made here are for learning. The UK service manual tells teams to build just enough to test their ideas, not production code, and to expect to throw much of it away.
Discovery vs a PRD vs a prototype
These are often confused, and agencies sometimes sell one as if it were another.
| Discovery phase | PRD | Prototype | |
|---|---|---|---|
| What it is | A piece of work that ends in a decision | A document that records what will be built and why | Linked screens you can click through, with nothing real behind them |
| Question it answers | Should we build this, and what exactly? | What are we agreeing to build? | Does this flow make sense to a user? |
| Who does it | You and the team together, with users | Usually the founder or product owner, reviewed by the team | A designer, often during discovery |
| What you keep | Problem, scope, risks, flows, approach, estimate, recommendation | One document | A design file and what users said about it |
So a PRD and a prototype are usually outputs of discovery. If you already have both, and they have been tested, discovery can be much lighter. MVP vs prototype vs proof of concept explains what each kind of early build proves.
When you can skip it, and when you should not
You can skip a formal discovery, or keep it to a scoping conversation and a written estimate, when:
- The first version is small and well understood, such as a marketing site or a single internal tool with one kind of user.
- You already have a tested PRD and designs, and the team has read them and agrees they are buildable.
- You are rebuilding a product that works, the behavior is documented, and the reasons for the rebuild are clear.
Do not skip it when the product has several user types, connects to systems you do not control, handles regulated or sensitive data, or depends on an AI feature whose quality nobody has tested yet. Do not skip it either if you plan to agree a fixed scope: the scope is only as good as the work that defined it.
One case where discovery is the wrong first step: you have not yet checked that anyone has the problem. That is validation, and it costs less to do yourself first. How to validate a startup idea shows how.
How to judge what you get
A good test from the USDS Discovery Sprint Guide: the write-up should make sense to someone who was not in the room. Reports get picked up again later, by new people, so they have to stand on their own. Then check:
- Is the problem described in your users’ words, with evidence, or only in yours?
- Does the scope have an “out” list, and does it match what you agreed?
- Are the risks specific to your product and ranked, or is it a generic list that would fit any project?
- Was the prototype tried with real users, and does the write-up say what changed because of it?
- Does the estimate list its assumptions, and say what would change it?
- Are unknowns stated openly, instead of hidden inside a confident number?
- Does the recommendation consider building less, or not building, and separate what to do now from what can wait?
- Could you hand all of it to another team and have them understand it?
Red flags: a slide deck with nothing you could build from, an estimate with no assumptions, a scope that is only a feature list, and a discovery that cannot end in “stop” because it was sold as the first step of a build already agreed.
Before you agree to a discovery phase
- Ask for the list of deliverables in writing, and what form each will take.
- Ask who will do the work, and whether the people on discovery are the people who would build the product.
- Confirm that the outputs are yours to keep and use with any team, whether or not you continue with this one.
- Ask how the estimate turns into the build agreement: as a fixed scope, or as a plan you work through by the week. Dedicated team vs fixed scope explains the difference.
- Ask what they need from you: a decision-maker’s time, access to users, logins to existing systems, and any data.
A short written brief before you start makes discovery faster and cheaper; How to brief a development agency has a template.
At BYD Tech the founders are on the scoping calls, and you get a written estimate after scoping. We price by the project or by the week, never by the hour. MVP development explains how a first version starts.
Sources
Checked when this guide was written.
