What Is Product Discovery, and What Should It Hand You?
Tanjim Islam
Founder & CEO · · 5 min read
This post defines product discovery, lists what you should be holding when it ends, and walks through the stages. If you are about to start with a partner, read what happens in the first two weeks next.
What is product discovery, in one sentence?
Product discovery is the short phase before building where you find out what to build, for whom and whether it can work, and it ends with things you can hold, not just ideas.
Atlassian's guide quotes Marty Cagan's book Inspired: the aim of discovery is "to quickly separate the good ideas from the bad. The output of discovery is a validated product backlog" (Atlassian, Product discovery, fetched 25 Oct 2026).
The UK Government Digital Service makes the boundary clear: "You should not start building your service in discovery" (GOV.UK Service Manual, How the discovery phase works, last updated 21 Jun 2021, fetched 25 Oct 2026).
Why does product discovery matter?
Because building is the expensive part, and changing direction mid build costs the most. Discovery is where changing your mind is cheap.
It answers four questions Atlassian lists for any idea: is it valuable, usable, feasible and strategic? In plain words:
- Valuable: will people want it, or pay for it?
- Usable: can they work out how to use it?
- Feasible: can it be built with the time, team and tech you have?
- Strategic: does it fit where the business is going?
What should you hold at the end of discovery?
This is the part most guides skip. Here is the list we use. If any item is missing, ask why.
| You should hold | What it looks like |
|---|---|
| Problem statement | One paragraph, in the user's words, not a feature list |
| User evidence | Notes or clips from real conversations, not guesses |
| Tested concept | Screens or a clickable prototype that users have reacted to |
| Scoped first release | The one core flow, plus a written "out of scope" list |
| Risk list | What could sink it: tech, legal, data, adoption |
| Success measures | How you will know the first release worked |
| Go or stop decision | A clear call, with reasons |
GOV.UK's list for moving on is similar. Before the next phase you should "have a list of ideas you'd like to test" and "know how you'll measure whether you've been successful."
What are the stages of product discovery?
Most discovery moves through five stages. They overlap, and you may loop back.
- Frame the problem. Turn "we need an app that does X" into "people struggle to do Y". GOV.UK gives an example: the problem is not building an interactive map of contact centres but how to make it easier for people to find their nearest contact centre.
- Learn from users. Talk to the people who have the problem. Watch how they deal with it today.
- Map constraints. Legal, technical, data and budget limits. Some you can change, some you cannot.
- Shape and test a concept. Sketch the core flow, turn it into screens, put it in front of users, change it.
- Scope and decide. Write the first release and what is out. Make the go or stop call.
How long should product discovery take?
GOV.UK says "there's no set time period for a discovery, but around 4 to 8 weeks is typical" for government services, and shorter if the problem is well known. Many smaller products move faster.
Speed comes from getting something visual in front of people early. At Gr8r, the first concept is ready within 48 hours of kickoff and a revised draft follows by day 2 to 3. Seeing a screen gets better feedback than reading a document.
What are the best practices for product discovery?
Start with the problem, show rough screens, talk to real users, write the out of scope list early, keep one decision maker, allow a no, and end with things you can hold.
- Start with the problem, not the feature. Write it down and agree on it before any design.
- Show, do not describe. A rough screen tells you more in one meeting than a spec does in a week.
- Talk to real users. Five honest conversations beat fifty survey ticks.
- Write the "out of scope" list early. It keeps the first release small.
- Keep one decision maker. Discovery stalls when every choice needs a committee.
- Allow a "no". GOV.UK notes "it's not a failure to stop at the end of the discovery phase" if research shows that is right. You save the build budget.
- End with things you can hold. Use the list above as the finish line.
What are the signs discovery went wrong?
Warning signs:
- It ended with a slide deck and no tested screens.
- Nobody outside the team spoke to a user.
- The scope grew instead of shrinking.
- There is no out of scope list.
- The build started "just to get going" before the scope was agreed.
What comes after discovery?
Delivery: designing in full and building the first release. With a clear scope, quotes become comparable and timelines become believable. See how long an MVP takes for why. To see how the first weeks run with a partner, read Your First Two Weeks With a New Product Partner.
Frequently asked questions
What is product discovery in simple terms?
It is the work you do before building to decide what to build. You learn who the users are, what problem they have, and whether your idea solves it in a way people want, can use and you can build.
How long does product discovery take?
There is no fixed length. The UK Government Digital Service says around 4 to 8 weeks is typical for its services, shorter when the problem is well known. Smaller products often move faster.
What is the difference between product discovery and delivery?
Discovery decides what to build and why. Delivery builds it. GOV.UK's guidance is blunt: you should not start building your service in discovery.
What should I get at the end of product discovery?
A problem statement, evidence from real users, a concept people have reacted to, a scoped first release with an out of scope list, a risk list and a plan for how you will measure success.
Can product discovery say no to my idea?
Yes, and that is a good outcome. GOV.UK notes it is not a failure to stop after discovery if the research shows that is the best thing to do, because you save time and money.
About the author
Tanjim Islam is the founder and CEO of Gr8r Studio. He founded the studio in 2023. Here he writes about how Gr8r approaches hiring, product design and AI engineering. More on the About page.
Discovery and audits share a habit: write findings down and rank them. Our UX audit of Veluno, a product we built, is an example of that write up. Built by Gr8r for its own portfolio. Not client work.
If you want help with this, book a 30 minute call.
