The Real Cost of Skipping Discovery, in Numbers

Most budgets for digital products contain a line for design, a line for development, and a line for testing. Discovery, if it appears at all, sits somewhere near the bottom as a negotiable item. Trim it back and the rest of the project can start sooner. That logic feels sensible right up until the point where the product arrives in front of real users and nothing quite works the way anyone expected.

The numbers behind product failure are stark. Between 80% and 95% of new products fail within their first two years, according to MIT Professional Programs. On any given day, 42matters records around 1,044 new iOS apps and 3,214 new Android apps entering their respective stores. The market is saturated, and the gap between a product that finds its audience and one that quietly disappears is rarely down to technical quality alone. It comes down to whether the team understood the people they were building for before a single line of code was written.

Discovery is the work that answers that question. And when it gets cut, the cost does not disappear from the project. It simply moves to a later, more expensive part of it.

The Discovery Budget That Never Gets Calculated

When teams plan a product budget, they tend to work from what they can see: design files, development sprints, QA cycles, launch costs. Discovery sits in a different category because its outputs are less tangible. You cannot point to a discovery phase the way you can point to a finished screen or a working feature. This makes it easy to treat discovery as an overhead rather than an investment, and easy to cut when budgets tighten.

What rarely gets calculated is the cost of the problems discovery would have caught. A feature built on an untested assumption does not just cost the time to build it. It costs the time to realise it is wrong, the time to decide what to do about it, and the time to build something better in its place. Those costs accumulate across every assumption the team made without checking.

The research patterns that exist in the industry make this dynamic visible. A 2022 survey by UserZoom and Ipsos found that approximately 72% of product decisions were made without user research informing them. That figure does not describe research that was ignored. It describes decisions made with no user data involved at all. The consequence of that is not just a slightly worse product. It is a product whose entire direction rests on internal opinion rather than external evidence, and which will need to be corrected once real users make contact with it.

Before cutting discovery from a budget, list every assumption the product is built on. Each one that goes untested is a potential rebuild cost sitting in the plan.

What Discovery Actually Costs in Time and Money

Discovery work typically runs over a defined period of weeks, not months. The activities within it include user interviews, behavioural observation, competitive landscape review, problem framing, and prototype testing. The time involved varies depending on the complexity of the product and the maturity of the team's existing knowledge, but it is a fraction of the overall project timeline in almost every case.

In practical terms, discovery costs tend to sit somewhere between 10% and 15% of total project spend. For a product with a £200,000 development budget, that means a discovery investment in the range of £20,000 to £30,000. That figure often triggers hesitation in project sign-off conversations. It feels like spending money before anything has been built.

The Comparison That Changes the Conversation

The relevant comparison is not between discovery spend and zero. It is between discovery spend and the cost of a post-launch rebuild. Software products can cost up to 100 times more to fix after launch than during development, according to BetterBugs. That multiplier applies to individual bugs. Architectural decisions built on wrong assumptions carry a proportionally larger correction cost, because they are embedded throughout the product rather than isolated in one area.

Discovery gives the team a way to challenge those decisions before they become load-bearing. A two-hour user interview session, run with eight to ten participants, can surface enough evidence to redirect a feature, retire a product assumption, or confirm that the core problem the product is solving is not the one the team thought it was. That kind of redirection at discovery stage costs almost nothing compared to the same redirection at launch.

The Hidden Price Tag of Skipped Research

The visible cost of skipping discovery is a shorter planning phase. The hidden cost is everything that fills the space where good research would have been: assumptions that harden into product decisions, features that get built because they felt right rather than because users asked for them, and launch moments that reveal a gap between what the team built and what the market needed.

A grassroots football product that we worked on illustrates how this compounds over time. The founders built based on what they believed the product should do, without grounding those beliefs in what the market was telling them. We advised against overcomplicating the product and adding features without evidence for them. The product became so complex that development had to stop. More than a year later, with only repeated announcements of "coming soon", there is still no marketable release. The time cost alone, a year of development without a shippable product, dwarfs whatever a research phase would have required.

Skipped research does not remove the cost of being wrong. It just delays when the bill arrives.

This pattern is not unusual. The Product Development and Management Association found that organisations with strong testing programmes have a 24% product failure rate, compared to 46% for those without. That is a 22-percentage-point difference in failure rate, and the main variable between those two groups is the quality of the research and testing work done before and during development.

Track every decision made during a project that rests on an assumption rather than evidence. That list is your risk register for post-launch corrections.

Real Overrun Figures Product Owners Know Too Well

Project overruns in digital product development are common enough that most teams have simply built them into their expectations. Timelines slip. Budgets expand. Additional sprints get added to address problems that only became visible once the product was tested against real behaviour. These overruns are treated as normal friction in the development process, but their root causes are rarely random.

Most overruns trace back to decisions made early in a project that turned out to be wrong. A feature set defined without user input gets rebuilt after beta testing. An information architecture designed around internal assumptions gets restructured when users cannot navigate it. An onboarding flow optimised for the team's understanding of the product gets redesigned when new users cannot complete it. Each of these corrections is, in effect, a second build. The team pays to build it wrong and then pays again to build it right.

Where the Overrun Starts

The place where this most often begins is scope. Products that skip discovery tend to grow in scope during development because the team is discovering user needs in real time, through build-and-test cycles, rather than through structured research up front. Every new insight generates a new feature request, and every new feature request extends the timeline and expands the budget. Discovery does not eliminate scope change entirely, but it compresses the period of uncertainty into the cheapest possible phase of the project.

Only one in four users uses an app on the day after download, according to a finding cited in Kim, 2019. A product that loses three quarters of its users on day two has a retention problem, and retention problems that stem from poor onboarding or unclear value propositions are discovery failures. The cost of that failure is not just the users lost on day two. It is the ongoing cost of acquisition to replace them, the marketing spend that cannot convert into long-term users, and the reputational signal that tells the app stores the product does not hold attention.

The Rebuild Maths Nobody Wants to Do Twice

A rebuild is not just a technical exercise. It is a signal that a product got far enough to reveal its fundamental problems to real users before those problems were understood and addressed. By the time a team reaches the decision to rebuild, they have usually spent the full original budget, delivered something that does not work well enough, and then need to find additional resource to fix it. The economics of that sequence are poor by any measure.

The maths gets worse when you account for what was lost during the first build. Time to market in digital products matters because the competitive landscape does not wait. A product that spends eighteen months in development and then six months being rebuilt has spent two years reaching a market that has moved on. Competitors who did the research work early have been in market for longer, building user bases and accumulating the behavioural data that makes their next product iteration faster and better-informed.

Between 30,000 new products launch annually, with failure rates ranging from 30% to 40% even for products that make it to market, according to G2. Those figures cover products that launched. They do not account for the significant number of products that never reach launch at all because the build became too complex, too expensive, or too disconnected from user need to continue. Discovery does not guarantee launch success, but it substantially improves the odds of arriving at a product worth launching in the first place.

When evaluating a rebuild decision, include the original development cost in the total project spend. The rebuild is not a fresh start, it is a correction cost added to work already done.

When Cutting Discovery Costs More Than the Project

There is a category of discovery cut that costs more than the original project budget. It happens when the skipped research phase would have revealed not just a feature-level problem but a fundamental one: the wrong target user, the wrong problem definition, or a market that already has a dominant solution the new product cannot meaningfully improve on.

A pre-launch founder we worked with arrived with a colour-coded spreadsheet mapping competitor products, excited about merging several of them into one. When we began asking questions about prospective users, such as why someone would choose an all-in-one product over specialist apps, and whether consolidation would dilute the quality of individual features, the founder became deflated. Those questions were not obstacles. They were the work. Because if those questions do not get asked and answered during discovery, they get asked by the market at launch, and the market's feedback loop is far more expensive and far less constructive than a structured research session.

• A wrong problem definition means every feature built to solve it is also wrong.
• A wrong user assumption means all usability decisions are calibrated for someone who does not exist in the real user base.
• A wrong competitive read means the product launches into a space it cannot win, regardless of how well built it is.
• All three of these failures are discoverable during research. None of them are easily fixed after launch.

The cost of cutting discovery in these cases is the entire project budget plus the opportunity cost of the time spent building something the market did not need. That is a significant sum to spend on information that a structured discovery phase could have surfaced in weeks.

Conclusion

Discovery is not a luxury phase for well-funded teams. It is the mechanism by which a product team replaces internal opinion with external evidence, and it is cheapest when done at the start of a project rather than at any point after. The costs of skipping it are real and they are calculable, even if most teams only calculate them after they have already been incurred.

The PDMA's research on product development practices shows a near-doubling of failure rates for teams without strong testing programmes. The UserZoom and Ipsos survey shows that 72% of product decisions happen with no user research at all. These figures describe an industry that consistently underinvests in understanding before building, and then absorbs the correction costs as normal. They do not have to be normal.

A product built on clear problem identification, tested assumptions, and real user insight is a product with a much shorter path from launch to traction. The discovery investment does not add time to a project in any meaningful sense. It removes time, specifically the time spent correcting decisions that were wrong from the start.

If you are weighing up whether discovery fits in the budget for your next product, the honest question is whether you can afford to skip it. Let's talk about your product discovery process and work out what that looks like in practical terms for your team.

Frequently Asked Questions