If you look at the CB Insights figures that get quoted in founder circles, 42% of startup failures in 2025 are put down to “no market need.” Don’t mistake this for products that couldn’t scale. These are things that ought not to have been built in the first place. Hardly ever is it a matter of bad code; more often it is a call made in haste and with scant evidence, one the team was loath to second guess once they were well into delivery.
A proper product discovery process is meant to plug that hole. I am not talking about a workshop or some canvas exercise. It is a system for making hard choices on what to build and for whom, and in what sequence, before you put a development budget behind the wrong answer.
We put this piece together for anyone about to put time or money into software – be it an AI feature, a redesign, a new module or your very first product. We want to demonstrate how discovery is supposed to work and where it goes wrong, so that you can let the evidence, rather than enthusiasm, be the driver.
## What Product Discovery Is, and What It Is Not
In short, it is the business of lowering the risk on your next irreversible move. You use evidence, not opinion, to figure out who this is for, which problem is the important one, and whether any solution is worth testing.
Don’t think of it as a phase you can check off. Good teams make it a habit that runs alongside delivery in what some call dual-track agile. If you want a good run-down of the discipline as a way to reduce uncertainty rather than a pre-build ritual, we point you to this product discovery process overview.
The distinction is this: discovery is a decision system. The template you use for an interview or a tree diagram is of secondary importance. Quality is measured by whether the evidence actually alters your course and how fast you will put an end to an idea that isn’t working.
### Where most teams get it wrong
You see the numbers in surveys from 2024 through 2026. Sixty to 80 percent of an organization will tell you they “do discovery,” yet only a quarter or so can show you a repeatable, documented process. That is the chasm between a team that does a couple of interviews to kick things off and one that has stage gates and weekly customer contact ingrained in its routine.
Most of the product budget is lost in that chasm. Industry data has long held that 60-80% of what gets shipped is never used. Not because it was poorly constructed, but because there was no clear answer to who needed it or what proof you had they would.
## Why it fails in practice
When discovery breaks down, it is seldom a technical issue. It comes down to pressure and politics, and how fast a team can stomach bad news.
**Stakeholders have already made up their minds.** An executive’s view or a sales promise has set the solution in stone. Any discovery after that is just window dressing to justify the decision. Itamar Gilad is blunt about it in his analysis of discovery problems, pointing to “must-have features” and “partial validation” as the usual culprits.
**Validation theater.** A survey of five people is taken as proof. Friendly chats are mistaken for demand. You collect what confirms your hunch and put the rest in the “edge case” file. At launch you have a raft of “validated” ideas your customers don’t care for.
**You are too slow to kill things.** The warning signs have been there for weeks but no one wants to be the one to halt the project. In a mature org, negative findings are put in writing and even welcomed for the money they save.
**Engineers are left out.** The specs come in fully formed and you find out it is not feasible when it is too late and costly to change. Get a technical lead in the room for the interviews; it is one of the best moves you can make.
These are the same issues you read about in every post-mortem of a named failure. Quibi went under six months in despite $1.75B in funding. Amazon wrote off $170M on the Fire Phone. The details of the retrospectives may vary but the story is the same: conviction ran ahead of the facts and the team had no standing to object.
## A Four-Stage Working Model
There is no need to invent a new framework. What you need is a sequence of decisions that yields evidence.
### 1. Understand the user and the current behavior
Put aside the solution for a moment and see how the problem is dealt with today. Review the support tickets, look at the analytics, do some interviews and observe the workflow. We want to put on record the workarounds people are actually using, what is impeding them and the cost of leaving the problem in place.
You will find two habits more valuable than any template: get in front of customers with some regularity and put aside preference questions (“would you use a feature that…”) for ones anchored in behaviour (“tell me about the last time you…”). Should you be new to the technique, we have a guide to user research for founders that goes over the usual pitfalls.
### 2. Define the problem and put your assumptions on paper
There is no sense in not having an opinion on raw feedback, but it is contradictory; people will tell you they want things that don’t go together. Your job is to make sense of the patterns, distinguish cause from symptom and note down the assumptions you are going on. A good problem statement can be read back to a customer in one sentence and still hold up.
Categorise your assumptions by desirability (do they want it), viability (is there a business in it) and feasibility (can we support and sell what we build). Rank them for risk and test the ones at the top of the list first.
### 3. Put forward options and prototype the riskiest
A lot of teams come to this part too soon. When you do, you need the discipline to produce more than one option and have a frank conversation about prioritisation based on impact or ease of execution. The Product School has a write-up on discovery if you want a RICE-style scoring template to start with.
After that, make the least expensive thing you can to put the riskiest question to bed. It might be a clickable flow, a landing page with a price on it or a fake-door test. Don’t worry about polish, the idea is to learn before you put money into it. And if you are on the fence as to whether a small MVP or a prototype is called for, we have explained the practicalities since the distinction is more important than it seems.
### 4. Test against pre-registered thresholds
This is where most teams let their guard down. Before you begin, decide what success and failure look like in hard numbers – a conversion rate, a signal of willingness to pay, a workflow completion rate. Not vibes.
If three out of five users can get through the core task unassisted, you have learned more about the reality of the concept than a dozen interviews with enthusiastic types would show you. As Amplitude lays out in the five phases of discovery, you end here to test, refine or kill.
| Stage | Goal | Typical activities | | :— | :— | :— | | Understand | See how the work gets done today | Interviews, ticket review, shadowing the workflow | | Define | Write the problem and rank your assumptions | Pattern synthesis, mapping assumptions, a problem statement | | Prototype | Make the cheapest thing to test the riskiest assumption | Sketches, concierge or fake-door tests, clickable flows | | Validate | Check your work against what you said was success | Usability and task tests, reviewing the signal, then pivot or persevere |
## How Deep Should Discovery Go?
It depends on the decision. You should tier your discovery by reversibility and risk. An investor applies due diligence with more rigour when the commitment is harder to unwind, and you should do the same.
Tinkering with a settings page doesn’t call for three weeks of research. But a platform migration, a regulated AI feature or a pricing model that the whole product rests on does. For early-stage software, four or six weeks of focus will surface the issues that would otherwise eat up three months of development. You won’t have a finished spec to show for it, but you will have the answers. You will have a defensible plan and a prioritized backlog, as well as a short list of the things you have put your foot down on not to build, with the reasons why. Should your team want some assistance in making that output actionable for the engineers, we have a guide to writing a product brief that is a good practical next step.
## What Good Discovery Leaves Behind
Discovery has failed if the only thing to show for it is “we had some good conversations.” The artifacts you produce ought to make your decisions legible to those who were not in the room. A useful output from discovery will typically be:
* A problem statement in one sentence that the team can quote verbatim. * User profiles based on behaviour rather than demographics (one or two at most). * Assumptions laid out and marked as tested, falsified or open. * A clickable prototype of the core flow to test and get the design moving. * Technical notes on any constraints, dependencies or complexity. * A decision log with the options you weighed, the evidence and the path you took and why. * A prioritized backlog where you know what is in version one and what is not.
The backlog is harder work than it seems. You need a documented “not now” list or every new discussion will have a way of pushing features back in; in effect, a disciplined backlog is the financial boundary for your first release. For planning further out, you might find our notes on product roadmap best practices and how to prioritize product features fit in well here.
## What This Looks Like at Refact
We do not expect most teams to have time for a six-month strategy exercise. They are after a short, disciplined push that results in a buildable plan and an understanding of what was left out by design.
Our discovery process is meant to fill that role. It is time-boxed and cross-functional, with four people in the room: the founder or product owner as domain expert, a strategist to frame and run the session, a designer to put assumptions to the test and a technical lead to spot complexity early on. There is no handoff. The code that follows is shaped by the decisions made there.
Take the case of the team behind Workform’s AI MVP. Their original idea was an AI assistant for project managers to handle “everything.” We put them through discovery and reframed the product around ingesting data from Slack, email, Asana and meetings, scoping the MVP to that job alone. That was not just paperwork; it determined what got built in version one and what did not.
In fact, we stand behind our discovery phase with a money-back guarantee. If the work does not give you real clarity, it should not exist. Discovery is to lower a founder’s risk, not to be another line item on a consulting bill.
Mature Teams and the Habits That Set Them Apart
Look at the best case studies and you will find a common thread of behaviour, not methodology. The teams that can be relied on to put out the right product have a way of doing things:
- They make it a point to speak with customers on a regular schedule, say weekly or bi-weekly, rather than waiting for a launch.
- They put their assumptions in writing and set about designing tests to disprove them, as opposed to confirming them.
- An experiment doesn’t run until they have pre-registered what success or failure will entail.
- Engineers are part of the problem framing, not just handed specs.
- If the evidence is thin they will kill an idea on the spot and put down what they have learned.
- Their discovery notes are a living thing, not some slides you put together once and forget.
There is nothing glamorous about these habits. Yet they are why one team’s products work and another’s features go unopened. You can swap out a framework but you cannot replicate this kind of behaviour.
What To Do Next
Before you write a check for development, ask yourself if engineering is really the highest-return task at hand. Chances are it isn’t. It is better to test the problem and your first pass at a solution with actual users, using pre-registered criteria for success, before you commit to building anything.
Discovery won’t do away with uncertainty; it simply puts the important stuff in the open so you can test it early and cheaply rather than at great cost later on. And when you are nearing a launch, a product launch checklist is a good way to ensure the transition from discovery to release doesn’t throw away your efforts.
Should you need a team to handle the strategy and product design prior to any development, Refact’s discovery process is designed to settle those decisions.
