What a Research Summary of Early-Stage Startup Failures Tells Us About Market Validation

Between 80 and 95 per cent of new products fail within their first two years, according to MIT Professional Programs. That range is wide enough to suggest the studies behind it vary considerably, but the direction of travel is consistent. Most products do not survive. And the reasons they fail tend to cluster around a handful of causes that are identifiable before the first line of code is written.

The pattern is consistent: founders build things people do not want, or build them for users who exist primarily in the founder's imagination.

Research summaries of early-stage startup failures are useful precisely because they compress what would otherwise take years of trial and error into a pattern. The pattern is not flattering. Founders build things people do not want, or build them for users who exist primarily in the founder's imagination. The product launches, the numbers do not move, and the team spends months trying to fix execution problems that were never execution problems to begin with.

We work across this territory regularly, and what the research describes matches what we see on projects. The failure modes are predictable. More importantly, they are testable before significant money is spent. What follows is our reading of what the data actually says, and what it demands of founders who want to be in the minority that survives.

The Two Statistics Every Founder Should Know

Two figures sit at the centre of any honest conversation about startup failure. The first is that approximately 42 per cent of startups fail because there is no market for their product, according to CB Insights' post-mortem analysis of failed startups. The second is the 80 to 95 per cent overall failure rate within two years. Together, they describe a situation where the majority of products that fail do so for a reason that could have been caught earlier, and where nearly half of all failures trace directly to a demand problem rather than a build problem.

These two figures belong together because founders tend to treat them separately. The 80 to 95 per cent figure gets cited as a general warning about the difficulty of launching a product. The 42 per cent figure is more specific and more useful: it tells you what the single largest cause of failure actually is, and it tells you it is more common than running out of cash.

The practical implication is straightforward. If demand is the leading cause of failure, then testing demand is the first thing a founder should do, before the product exists in any form. It is also, relative to building a full product, cheap to test. A few focus groups or a structured survey costs a fraction of a six-month build. The asymmetry between the cost of early validation and the cost of a failed launch is large enough that skipping research is difficult to justify on financial grounds alone.

Why No Market Is Not a Build Problem

When a product fails, the diagnosis is often aimed at execution. The onboarding was confusing. The design was poor. The feature set was wrong. These are real problems, and they deserve attention. But they sit downstream of a more fundamental question: was there genuine demand for the product in the first place?

We worked on a product aimed at African communities living abroad, designed to help people maintain connection with their home communities. The concept was technically viable and relatively straightforward to build. We ran focus groups with people from the target market and the findings were clear: there was insufficient desire for the product. A secondary constraint compounded this. The devices commonly used in African countries at the time had limited capabilities, which would have made delivering half of the intended experience extremely difficult.

This was a demand problem and a technical feasibility problem, both identifiable before build. No amount of refined onboarding or improved visual design would have changed the underlying reality that the target users did not want the product in the form proposed. The focus groups surfaced this early enough to stop the project from consuming a full development budget. That is the function early research is supposed to perform.

Treating no-market failures as execution failures is a category error, and it produces the wrong remedies. You cannot design your way out of a product nobody wants.

The Founder Conviction Trap

Strong conviction is useful in a founder. It sustains effort through the long stretches where nothing is working and the people around you are uncertain. But conviction about a product and knowledge of what a market wants are not the same thing, and founders who conflate them tend to build for themselves rather than for the user they are trying to serve.

The version of this we see most often involves a founder who has personally experienced a problem and assumes, reasonably but incorrectly, that the market shares it. The logic runs: I have this problem, therefore others do too, therefore there is a market. Each step feels sound. The conclusion is often wrong. A focus group or a structured survey will tell you quickly whether the problem is widely felt or whether it is particular to a specific type of person, a specific context, or the founder's own situation.

Conviction about a product and knowledge of what a market wants are not the same thing, and conflating them tends to build for the founder rather than the user.

A pre-launch founder in the football industry came to us with a colour-coded spreadsheet mapping out competitor products. The goal was to merge several existing tools into a single all-in-one product. The founder was visibly excited. When we started asking questions about prospective users, why someone would choose a consolidated product over specialist apps, whether merging features risked simplifying them past usefulness, the energy in the room changed. The founder became deflated. Our job is to be honest about what will make a product succeed, and a spreadsheet full of competitor features is not a substitute for evidence that users want the thing being proposed.

Before committing to a product concept, run at least three to five interviews with people who are not your friends or colleagues. Ask them to describe the problem in their own words. If they struggle to name it, that tells you something the spreadsheet cannot.

When Research Gets Done But Not Used

There is a version of market validation that is formally present and functionally absent. The focus groups happen. The surveys go out. The findings come back. And then the founder, having confirmed to themselves that they have done their research, continues building exactly what they planned to build before the research started. The process was real. The intent to act on it was not.

We walked away from an engagement with a founder who had deep industry experience and correspondingly strong opinions about how their product should work. The research became a box-ticking exercise. When findings came back showing that a large portion of the target user base did not want certain features and actively preferred alternatives, the founder dismissed them. We showed the evidence, explained the reasoning, and the position did not shift. We ended the engagement.

The product launched about a year later, largely unchanged from the version the founder had envisioned from the start. By our understanding, it did not gain traction, for the same reasons the research had flagged. The Nielsen Norman Group has found that in lower-maturity organisations, fewer than 20 per cent of research findings result in a documented product change. That figure describes the gap between research that gets commissioned and research that gets used.

After each round of user research, write down three specific decisions the findings changed. If you cannot name three, the research has not been used yet.

What the African Communities Product Reveals About Demand Testing

What the focus groups actually found

The product we built for African communities abroad is worth examining in more detail, because it illustrates what genuine demand testing looks like and what it produces. The product was designed to help diaspora communities stay connected with life at home. The hypothesis was reasonable. The need felt intuitive. The technology to build it existed.

The focus groups did not confirm the hypothesis. The target users, when given the opportunity to describe their own behaviour and preferences, did not express the desire the product was designed to serve in the way the brief anticipated. This is, in fact, a common outcome. User groups frequently respond to a proposed product differently from how a founder expects, and that divergence is the most valuable output of the research process.

The device constraint that changed the picture

The second finding was structural. Delivering the full experience required device capabilities that were not reliably available to a significant portion of the intended user base at the time. Half the product would have been inaccessible to many of the people it was built for. This is a market reality that no amount of product iteration can fix. It requires either a different product or a different market.

Both problems, insufficient demand and a constrained device landscape, were identifiable before a build began through thorough app user research. The research found them. The project did not proceed to a full build. That is the correct outcome, and it is one that only happens if the research is done with genuine openness to what it might return.

Where Validation Effort Actually Needs to Go

We have seen the same pattern across two separate projects, a fitness and wellness app and a grassroots football product, where founders with strong personal conviction ignored data from research, focus groups, and surveys. In both cases the product became what we describe as a vanity product: shaped by the founder's preferences rather than by evidence of what users wanted. Early signs of this include an excessive drive to perfect the product before launch, decisions that keep getting reopened after sign-off, and a build process that stretches well past its original timeline. Both projects exhausted their budgets in design and build without reaching a fully live product.

The question that cuts through most of this is one we return to with founders who are uncertain whether to persist with a concept: are you solving a real problem that people will pay for, or are you in love with the solution? The distinction separates products that have a genuine market from products that exist primarily to satisfy the founder's vision.

Map your validation effort across four areas before committing to build. Check whether the problem is widely felt beyond your own experience, whether users understand your proposed solution without explanation, whether they would pay for it, and whether there are existing behaviours you would be displacing. Gaps in any of these areas are worth addressing before the build starts.

1. Confirm the problem exists beyond the founder's own experience, via interviews or structured surveys.
2. Test whether prospective users understand the proposed solution without prompting.
3. Establish whether they would pay for it, and at what price point.
4. Identify the existing behaviour your product would need to displace and assess how entrenched it is.

These four checks are a filter that removes the most common and most expensive causes of failure before the money is spent.

Conclusion

The research summary picture of early-stage startup failure is uncomfortable because it describes problems that are, in most cases, preventable. Forty-two per cent of startups failing because there is no market for their product is a description of capital, effort, and time spent building something the market did not ask for. The causes are consistent enough across the data that they function as a checklist of what to test before you build.

What the African communities product showed us, what the football founder's spreadsheet showed us, and what the founder who dismissed their research findings showed us is that validation is only useful if it is done with genuine openness to the answer. Research that confirms a decision already made is documentation.

The founders who avoid the 42 per cent are the ones who test demand before they build, who involve their target users in the conversation early, and who treat a finding that contradicts their assumption as information rather than inconvenience. After every product launch we have worked on, user feedback has redirected the product in ways the internal team did not anticipate. That is evidence that real users know things a founding team does not, and that finding out what those things are before launch is worth more than any amount of competitive mapping.

If you are at the stage where these questions are live for your product, let's talk about your validation approach.

Frequently Asked Questions