CB Insights reviewed public post-mortems, founder interviews and shutdown announcements from 431 VC-backed companies that shut down since 2023 and had enough detail to categorize failure reasons for 385 of them. Running out of capital led at 70%. Poor product-market fit followed at 43%. Bad timing or macro conditions came in at 29%. Unsustainable unit economics sat at 19%. Read the list twice. 'Couldn't build the product' isn't on it.
That absence is the whole argument of this post. Building is the part of a startup that engineers are trained for, staffed for, and comfortable estimating. It is also, according to the actual data on how these companies died, rarely the thing that killed them. The things that killed them were about people wanting the product, at a price that covered what it cost to get and keep them, before the money ran out. approaches product market fit from the operator's side, which complements the engineering view here. XenGrowth's growth operations team approaches product market fit from the operator's side, which complements the engineering view here.
What the data actually says, precisely
It's worth being exact here, because 'CB Insights says startups fail because of X' gets repeated so loosely that the actual report underneath it rarely gets checked. The percentages in the 431-company update sum past 100%, and the report says why: most startups cited more than one contributing cause, not a single clean reason. Running out of capital tops the list, but the same report is explicit that this is usually the proximate cause rather than the root one — a company runs out of money because something upstream wasn't working long enough before the cash ran out to fix it.
Failure reason (431-company update) | Share cited | What it actually describes |
|---|---|---|
Ran out of capital | 70% | The proximate trigger, per the report — usually downstream of a demand or economics problem |
Poor product-market fit | 43% | The product exists; not enough of the right customers wanted it enough |
Bad timing / macro conditions | 29% | The market, funding environment, or customer budgets moved against the business |
Unsustainable unit economics | 19% | It cost more to acquire and serve a customer than that customer was worth |
An earlier CB Insights pass, reviewing roughly 101 startup post-mortems, asked a related but distinct question and found 'no market need' cited in 42% of failures — the single most common individual reason in that analysis, ahead of running out of cash and being outcompeted by a rival. Two different samples, two different report vintages, and neither one has a line item for 'the engineering team couldn't ship it.' approaches this from the the operations side of this side. The XenGrowth resource library approaches this from the the operations side of this side.
It's worth sitting with why the two report vintages agree on this despite covering different companies in different years. If 'couldn't build it' were a real, common failure mode, you'd expect at least one of two independent post-mortem analyses, years apart, to surface it as a distinct category somewhere in the top nine or top twenty reasons. Neither does. That's not proof no company ever failed on execution — some clearly have — but it's strong evidence that execution failure is rare enough, relative to demand and capital failure, that it doesn't clear the bar for a named category in either dataset.
Failure reason (earlier ~101 post-mortem pass) | Share cited | What it actually describes |
|---|---|---|
No market need | 42% | The most-cited single reason in this earlier pass — the product existed, demand for it didn't |
Ran out of cash | 29% | Overlaps with, but is distinct from, the newer report's capital finding |
Not the right team | 23% | Team composition or execution gaps — the closest category to a 'build' failure, and still not about the product not working |
Got outcompeted | 19% | A rival captured the same demand faster or more cheaply |
"No market need" is not the same failure as "couldn't build it"
It matters to keep these two apart, because they point an engineer toward completely different fixes. 'Couldn't build it' is a construction failure — the team lacked the skill, time or technical approach to make the thing work. 'No market need' is a distribution and demand failure — the thing works fine, and almost nobody who could buy it wants it enough to pay for it. Peter Thiel's argument in Zero to One is the sharper version of the same point: a company can survive a mediocre product with real distribution, but it cannot survive a great product with no way to reach anyone who needs it. There's a real discipline built around finding this out cheaply, before a company burns through its capital discovering it the expensive way — closer to what works with operators on.
This is not a comfortable reframe for engineers, because it means the highest-leverage risk in most startups sits outside the part of the job engineers are best at. You can ship a technically excellent product on schedule and still die of exactly the failure mode CB Insights measured at 43%. The build succeeding tells you almost nothing about whether the market-need risk has been retired. On AI agents and marketing automation specifically, is worth reading. On AI agents and marketing automation specifically, XenGrowth on AI agents and marketing automation is worth reading.
A startup rarely dies because the code doesn't run. It dies because the code runs perfectly, in front of almost nobody who needed it enough to pay for it, until the money to keep finding out ran out.
Where the '90% of startups fail' folklore actually comes from
The number gets repeated constantly and rarely with its definition attached, which is its own small lesson in citing statistics honestly. It traces back to Startup Genome's research measuring venture-backed startups that fail to return 10x to their investors — a specific, narrow bar tied to venture economics, not a general statement about small businesses or even about startups broadly. By that definition, a company doing several million dollars a year in real revenue, profitably, still counts as a 'failure' if it raised a large round at a valuation that required a much bigger outcome. Compare that to general small-business survival data — U.S. Census and Bureau of Labor Statistics figures put roughly 20% of new businesses closing within the first year and about half by year five — and the picture looks materially less dramatic. Both numbers are real. They're measuring different populations against different bars, and conflating them is how a folklore statistic gets born. For the version of this validated against real spend, covers how teams test demand before committing a budget to it.
Read the original 101-post-mortem report closely and there's a 'Poor Product' category, but it sits at 17%, well below no market need and well below team problems — and even the closest thing to a pure construction failure in the whole dataset gets filed somewhere else. One founder, writing in the Standout Jobs post-mortem that CB Insights quotes directly, put it this way: 'The founding team couldn't build an MVP on its own. That was a mistake... If the founding team can't put out product on its own... they shouldn't be founding a startup.' CB Insights files that under 'Not the Right Team' — a hiring and composition problem, not a coding-ability problem. Even the one example that comes closest to 'the building part failed' turns out, on inspection, to be about who was on the team rather than whether building is hard.
What this means for how an engineer should spend risk-reduction time
If the data says building rarely kills a startup, the practical conclusion isn't 'stop building carefully.' It's that the hours spent de-risking the build are usually cheaper to find than the hours spent de-risking demand, and most teams unconsciously spend their scarce validation time on the risk they know how to reduce rather than the risk that actually kills companies. Writing more tests reduces a risk that's already comparatively low. Talking to ten more prospective customers before writing another feature reduces the risk that's sitting at 42-43% in the actual post-mortem data. On instrumenting that kind of validation properly, covers cheap ways to test demand for an offer before an engineering team commits real time to it. approaches this from the AI search, GEO and discovery side. XenGrowth on AI search, GEO and discovery approaches this from the AI search, GEO and discovery side.
Treat 'will anyone pay for this' as the primary technical risk on the project plan, not a marketing side-quest that happens after the build
When a launch goes quiet, check demand and unit economics before you check the build — the data says that's where the failure usually is, at roughly twice the rate of any construction issue
Budget calendar time for the discovery work that finds 'no market need' early and cheaply, because CB Insights's own framing is that running out of capital is usually the last domino, not the first one
Separate 'unsustainable unit economics' from 'no demand' when you diagnose a stalling product — the first means the model is priced wrong even with real customers, the second means there aren't enough real customers at any price
Distrust any startup statistic quoted without its sample size and definition attached — '90% fail' and '42% cite no market need' both come from real, specific analyses, and the specificity is exactly what makes them worth citing at all
There's a version of the '20 reasons' report worth reading for its texture, not just its percentages. Tutorspree's post-mortem, quoted in the same CB Insights analysis, describes exactly the distribution problem the companion post on this site covers: 'Tutorspree didn't scale because we were single channel dependent and that channel shifted on us radically and suddenly. SEO was baked into our model from the start.' That's a company that clearly could build — a working tutoring marketplace, live, with users — undone by depending on one channel that moved. It's a distribution failure wearing a business-model label, filed under 'Need/Lack Business Model' at 17% in the original chart, nowhere near a construction problem.
None of this makes building unimportant. A product that doesn't work reliably will eventually surface as its own failure, and every one of the demand-side numbers above assumes there's a working product behind the customer's decision to pay or not pay. But 'assumes there's a working product' is doing a lot of quiet work in that sentence — it's the baseline, not the differentiator. The data from hundreds of actual shutdowns says the differentiator lives somewhere else, and it's worth spending scarce hours accordingly.
Further reading from XenGrowth
Where this work meets go-to-market
Reducing demand risk before it becomes a shutdown statistic is its own discipline, distinct from the engineering discipline of shipping a working build. publishes operator guides on exactly that side of the business.
Further reading from XenGrowth
Where this work meets go-to-market
Working on product market fit inside a commercial team? publishes operator guides on the revenue side of this work.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
Working on product market fit inside a commercial team? XenGrowth's work on go-to-market systems publishes operator guides on the revenue side of this work.
Five questions on what CB Insights's post-mortem research actually found, versus what gets repeated about it.
