Key takeaways
- A discovery phase earns its cost when a core assumption about users, their job, payment or usability still has no evidence.
- Score six yes/no questions: two or fewer yes answers means full discovery, three or four a light sprint, five or six go straight to design.
- Good discovery hands design a one-page product brief, a research report, a sitemap with user flows and agreed success metrics.
- Stopping after discovery is a valid result: the cheapest product to cancel is one that has no code yet.
- In our engagement, discovery and user research are the first two of five steps, run by the designers who later design the screens.
Nitro League came to us with one racing game for gamers, non-fungible token (NFT) collectors and investors, the kind of product that makes a founder ask: is a discovery phase worth it before anyone designs a screen? We started with product discovery and stakeholder interviews, before any branding work. The Nitro League case study reports $5M in funding secured within 3 months, an outcome of the whole project rather than of discovery alone.
For most new products the answer is yes: discovery buys evidence on the assumptions that would sink the product while changing course still costs a document instead of code. It is not always worth it, and the six-question skip test below tells you when to go straight to design. In our digital product design services, discovery and user research are the first two of the engagement's five steps; this post helps you judge whether your product needs a discovery phase before design starts.
Is a discovery phase worth it for a new product?
Yes, when any core assumption about your users, the job they need done, whether they will pay or whether they can use the product still lacks evidence.
No, when the product repeats one you already sell and the proof sits in your research files. Here, a discovery phase means design-led product discovery: product strategy and user research before anyone designs screens. In Double Diamond terms it is the first diamond: explore the problem widely, then narrow it to one worth solving.
"Worth it" is easiest to judge as risk bought down. Marty Cagan of the Silicon Valley Product Group (SVPG) names four big risks: value (will customers buy or use it), usability (can users figure it out), feasibility (can engineers build it) and business viability (does it work for the business). Design-led discovery tests value, usability and viability with evidence; feasibility is an engineering call, so whoever will build the product joins in.
The GOV.UK Service Manual tells teams to reframe any predefined solution as a problem to be solved and not to start building the service during discovery. It is a public-sector standard, not startup data, but the logic transfers. Score your own evidence with the skip test below before you decide.
What does a discovery phase hand to your designers?
A useful discovery phase hands design four outputs: a one-page product brief, a research report, a sitemap with user flows, and agreed success metrics.
Each is something a designer opens on the first day of prototyping; an output nobody opens was not worth the time.
Show as text
| Output | What it holds | What the designer does with it on day 1 |
|---|---|---|
| Product brief (one page) | Target users, Jobs to be Done, scope | Picks the users and job every screen serves |
| Research report | 5–8 interviews per user group: unmet needs, workarounds, switching triggers | Turns workarounds into steps the product must beat |
| Sitemap and user flows | Every screen and core task | Builds the clickable prototype in Figma |
| Success metrics | Targets such as weekly active users and task completion time | Writes prototype test tasks against those targets |
The Jobs to be Done line names the progress a user hires the product to make, in the user's own words. In the made-up clinic scheduling app used as our example below, the job belongs to a clinic manager who needs tomorrow's cancelled slots refilled. Designers cut any screen that does not serve that job.
The Google HEART framework (Happiness, Engagement, Adoption, Retention and Task success) gives each success metric a category, so the team agrees on what "better" means before arguing about layouts. In our process, researchers synthesize the user interviews in Dovetail, and the flows feed a clickable prototype in Figma that a later step tests with 5 users per round in Maze; each round ends with a System Usability Scale (SUS) score.
Many lists of discovery phase deliverables online come from software development shops and center on a tech stack and an estimate, which answer feasibility; design-led discovery answers value, usability and viability. If you need both kinds, ask each provider which of the four risks its discovery covers.
Which assumptions should discovery test first?
Test first the assumptions that would change the product if wrong, and sort each into value, usability or viability with a method and an evidence bar.
Write them into an assumption ledger before kickoff, so interviews chase evidence instead of opinions. The illustrative rows below continue the made-up clinic scheduling app.
Show as text
| Assumption | Risk type | Method | Evidence that counts | Status |
|---|---|---|---|---|
| Clinic managers will switch from spreadsheets | Value | Jobs to be Done interviews | Most describe a recent scheduling failure and its workaround | Untested |
| Front-desk staff can rebook a patient unaided | Usability | Prototype task test | Staff finish the rebooking task without help | Untested |
| Clinics will pay a monthly fee per location | Viability | Pricing questions, competitor review | A named budget owner and current tool spend | Untested |
| Patients will book from a text-message link | Value | Stakeholder interviews, then a prototype test | Front desks report patients asking to book by text | Untested |
Rank each row by how bad it would be if wrong and how little evidence you hold, then test the top three first. Here the first and third rows lead: if managers will not switch or clinics will not pay, no flow design rescues the product. Write down your own riskiest assumptions now, three of them; the closing section asks for that list.
When can you skip a discovery phase?
Skip it when you answer yes to five or six of the questions below; three or four yes answers call for a light version, and two or fewer for full discovery.
Can you skip product discovery? Yes, if the test says so: it scores the evidence you already hold, not deadline pressure, and its cut-offs are our rule of thumb from running engagements, not research data.
Show as text
Count your yes answers:
- Have you interviewed at least 5 target users about this problem in the last 12 months?
- Can you name the one job users hire the product for?
- Do you know what users rely on today and why they would switch?
- Is there a paying customer, a signed pilot or a waitlist for this exact product?
- Have the founders agreed on the success metrics?
- Does a regulation, contract or platform rule fix the scope?
Score: 0–2 means full discovery, 3–4 a light version, 5–6 skip discovery and start design.
The light version is a 5-day design sprint for startups, which aligns founders on 1 target user and 1 core problem. A minimum viable product (MVP) tests the product in the market, and discovery decides what that MVP has to prove, so framing it as discovery phase vs MVP sets up a false choice.
It is safe to skip discovery when you rebuild a product whose users you already study, make an internal tool for one known user group, or work to a scope a regulation sets. There, a full discovery phase repeats what you know and returns little.
Your score is your own answer to "is a discovery phase worth it?" If you scored four or lower, you are about to design on assumptions, and your riskiest three make a good agenda for a first call with us.
What does skipping discovery cost you later?
The wrong assumption still surfaces, only later, and every later stage makes it more expensive to fix: first in prototype tests, then in build, then after launch.
Our service page puts the mechanism in plain terms: usability issues found in a clickable prototype cost hours to fix, while the same issues found after launch cost development sprints. A discovery phase before app development moves that moment to the cheapest rung, the interview.
Show as text
From cheapest to most expensive:
- Interview: the assumption fails in conversation; you rewrite a line of the product brief.
- Prototype test: users stall on a task; designers spend hours reworking the flow.
- Build sprint: code exists around the wrong flow; development sprints go to rework.
- After launch: users meet the problem and leave; the fix costs sprints plus lost users.
Discovery can end in "stop", and that is a good result. The GOV.UK Service Manual treats what a team learns in discovery as the basis for deciding whether to move on to the next phase at all. A product with no code is the cheapest to cancel. Short of stopping, you change direction: a different first user group, a narrower job or a pricing model the interviews support.
Vendor pages often put a percentage on the overspend from skipping discovery; none we found shows its method, so we leave those numbers out.
Take the top three rows of your ledger and ask on which rung each would surface without discovery. Any row that would first show up in a build sprint or after launch is your case for paying for discovery now.
What did discovery settle for Nitro, Vocable and Digno?
In all three idea-to-product projects, early research came before the screens: it gave Nitro League its user flows, Vocable the problems each screen was designed around and Digno its score calculation.
Each case study reports results from the whole project, not from discovery alone.
Nitro League. Unknown: how one product would serve three audiences while investors doubted whether crypto products were authentic. Settled: product discovery and stakeholder interviews produced the user flows and a detailed whitepaper. Built: branding workshops, the 3D garage and the website followed, and professional gamers validated the result.
Vocable. Unknown: where content marketers lose their time. Settled: we mapped the full creator journey and designed each screen around a problem heard in stakeholder interviews: planning, drafting, optimizing and publishing. Built: one editor across several artificial intelligence (AI) models, plus templates and a research tool. The case study on how Vocable went from idea to MVP reports a 35% increase in overall workflow efficiency and a 20% improvement in content quality and consistency.
Digno. Unknown: how a performance score should be calculated so managers and employees both understand it. Settled: we gathered requirements from different stakeholders and users to define the calculation, and studied competitors that had tried to solve similar problems. Built: that research shaped five core experiences of the Digno scoring platform, whose case study reports a 5x increase in overall revenue.
If your product is where these three started, with no users and no screens yet, score the skip test above and take the result into the scoping step below.
How long does discovery take inside an engagement?
In our engagement, discovery and product strategy take 5–10 days and user research takes 5–15 days, the first two of five steps.
The full engagement runs 8–16 weeks (40–80 working days), and discovery and research open it before information architecture, prototype validation and user interface (UI) design.
Discovery days go to stakeholder workshops, Jobs to be Done mapping and HEART success metrics; research days go to interviews with 5–8 users per user group. Information architecture and flows come next, and the prototype round builds on both.
Discovery sits at the start of the engagement because evidence gets lost at handoffs. The designers who run your research stay through design, testing and handoff, so whoever heard the clinic manager's workaround in our earlier example designs the screen that replaces it.
When you set a launch date, count the first 10–25 working days for discovery and research before information architecture starts. Book the people named in the FAQ "Who from our team needs to join a discovery phase?" into week one.
What does a good discovery readout contain?
A good readout states a decision to build, change or stop, shows the evidence behind it, and hands over outputs a designer can start from.
Workshop notes with no users in them are not discovery. Maria Rosala, Director of Research at Nielsen Norman Group (NN/g), surveyed user experience (UX) practitioners and found that many discoveries run short, lack user research and leave out the right people. Check any readout against the card below before you sign off on it.
Show as text
A good discovery readout contains:
- Named target user groups
- The interview count per group
- Top findings, each with a user quote
- The assumption ledger, with evidence status per row
- Success metrics with baselines or targets
- A sitemap and the core user flows
- An explicit build, change or stop decision
- Open questions for the prototype round
Treat four things as warning signs: no user interviews, only stakeholder opinions, no stated decision, or outputs that restate the founder's original brief. Ask any agency for a sample readout before signing and hold it to the card. If you already paid for a discovery that misses the decision or the users, reopen those lines before design starts and bring that readout along when you talk to us.
How do you scope discovery into a proposal?
Bring your skip-test score, your riskiest three assumptions and your number of user groups; together they show how much discovery and research the engagement needs.
Add your platforms, how you will reach users and your launch date. Each user group adds its own 5–8 interviews to the research step. Discovery and research are the first steps of an engagement that runs 8–16 weeks, and its price follows four factors (platforms, user groups, core user flows and validation rounds). The published range for the whole engagement is $60,000–$180,000, set out under what digital product design costs.
So, is a discovery phase worth it for your product? Your ledger answers better than any vendor percentage: every row still marked untested is a risk you would carry into code.
When the list is ready, send us your three riskiest assumptions with your skip-test score. Every project begins with a free consultation and a fixed-scope proposal. Our team has designed 200+ products since 2017.
FAQs
Is a design sprint the same as a discovery phase?
No. A design sprint picks one direction and tests it quickly, while a discovery phase first sets the target users, their jobs and the success metrics across the product. A sprint fits when one bet needs testing; a full discovery phase fits when several user groups, jobs or success metrics are still open.
Can you skip discovery if you already have a prototype?
Yes, if target users tested the prototype recently and the findings shaped the design. An untested prototype is an assumption with screens on it, and by itself it earns no yes answers on the skip test.
What happens if discovery shows the product should not be built?
You stop or change direction before any code exists, which is the cheapest moment to do it. The GOV.UK Service Manual frames discovery as the point where a team works out whether to move on at all, and the interviews stay useful for the next idea.
Who from our team needs to join a discovery phase?
Three roles need a seat: the founder or product owner who makes the build, change or stop decision; one or two people who talk to customers every week, such as sales or support; and an engineer for feasibility questions. The decision maker matters most, because a readout without one ends without a decision.
Does discovery still matter for an AI product?
Yes. Model choice is a feasibility question for engineers, but whether users trust the output and act on it is a value and usability question discovery tests. For Vocable, an AI content marketing platform, each screen was designed around a problem heard in stakeholder interviews.
