Validation Guide
Startup Failure Analysis: How to Read a Failed Startup the Right Way
Startup failure analysis is the discipline of converting documented startup failures into testable assumptions. Five real cases — Quibi, Webvan, Juicero, Homejoy, WeWork — analyzed with a seven-rung framework, then turned into the validation experiments a solo founder can run this week.
· Updated · Yibud· 26 min read
On this page
- Quick answer
- Key takeaways
- Why this matters
- What startup failure analysis is — and is not
- Definitions
- Framework: how to analyze a startup failure
- Real startup failure cases
- Failure patterns
- Startup failure vs. startup validation
- What founders should validate before building
- How to turn a failure story into a validation experiment
- Common mistakes when studying startup failures
- Decision framework
- FAQ
- Summary
- Related reading
- What to do next
Quick answer
Startup failure analysis is the discipline of turning documented startup failures into testable assumptions. It is not a list of "ten reasons startups fail." It is a method for separating what a source actually said from what we infer from it, then converting each inferred root cause into the validation experiment that would have surfaced it earlier.
A failure analysis has seven rungs: Observed Outcome → Documented Cause → Underlying Assumption → Available Evidence → Missed Validation → Lesson → Preventive Experiment. The first four rungs stay close to the public record. The last three rungs are explicitly labeled as interpretation. Mixing the two is the most common mistake in startup failure writing — including this article, where every "what could have been tested earlier" is the author's reconstruction, not a historical claim about what the founders knew.
The five cases in this article — Quibi, Webvan, Juicero, Homejoy, WeWork — were chosen because each one has a documented post-mortem in reputable business reporting and a failure pattern that maps cleanly to a specific validation rung. None of them is presented as the only cause of its failure. Most startup failures are multi-causal; the cases here illustrate recurring patterns, not unique explanations.
Key takeaways
- Startup failure is usually multi-causal. Picking a single root cause is rarely honest. The cases below name at least three documented causes per company, then identify the validation lesson each cause suggests.
- A reported failure reason is not automatically the original cause. Founders and postmortems tend to attribute failure to the most recent problem. The original cause is often an assumption the founders never tested in the first place.
- Validation should target the riskiest assumption first. The five cases below share a pattern: the founders spent heavily on assumptions they could have tested cheaply, and under-tested assumptions they could not have afforded to be wrong about.
- Customer demand and willingness to pay are different questions. Several cases (Quibi, Juicero, parts of WeWork) had real customer interest and still failed. Interest is not payment. Payment is not retention. Retention is not unit economics.
- Distribution can be the binding constraint even when the product works. Quibi launched a well-funded product into a context where the distribution assumption — mobile-only, on-the-go viewing — was structurally inverted by the launch environment.
- Capital intensity is itself a hypothesis. Webvan and WeWork illustrate that aggressive physical expansion is itself a testable assumption, not a precondition for learning.
- Postmortems are useful only when converted into testable lessons. A failure story that does not name the assumption it confirms or refutes is editorial content, not validation evidence.
Why this matters
I have watched founders who learned more from one well-read failure postmortem than from a year of their own launches — and others who read the same postmortems and walked away with a different lesson than the one inside them. The difference is not intelligence. The difference is whether they treated the failure story as evidence about the underlying assumption or as evidence that "this kind of idea" is bad.
The simplest working definition is this: a startup failure is a documented event in which a funded, operating company materially collapsed — shut down, liquidated, sold for parts, or failed to reach a sustainable operating state — and in which there is enough reporting to identify the assumptions the founders held at the start. The verb "to analyze" means converting the documented event into the assumption that, if validated earlier, would have changed the path. The conversion is interpretation. The event is the part you can source.
The deeper treatment of why founders skip validation in the first place lives in the Why Founders Build Before They Validate pillar. The Lean Startup method that turns failure analysis into a forward-looking discipline is in Lean Startup Validation. The vocabulary used here is defined in the Startup Validation glossary.
What startup failure analysis is — and is not
Startup failure analysis is a forward-looking discipline that uses documented startup failures as input data. It treats each closed case as a partially preserved experiment whose results can still be read if the analysis separates the documented event from the interpretation.
Three clarifying distinctions help keep the work honest.
Failure analysis is not a ranking. The most-cited failure-cause statistics in startup writing come from a single research house, CB Insights. Their Startup Failure Post-Mortem reports synthesize the post-mortem write-ups of founders of failed startups and rank the causes founders self-cite. The widely repeated line "no market need" is the leading cause founders cite, at roughly 42% across CB Insights' 2021 update of the survey. That number measures what founders said about their own failures after the fact. It does not measure the prevalence of any one cause in the broader population of failed startups. Treating it as a population statistic is a category error that the original reports explicitly warn against.
Failure analysis is not prediction. No published method can reliably predict which specific startup will fail. Anyone claiming otherwise is selling something or making it up. The honest claim is narrower: failure patterns repeat, the assumptions that drive them repeat, and validating those assumptions earlier changes the path of specific cases. The discipline is about general patterns, not specific outcomes.
Failure analysis is not founder-bashing. Every case in this article is a real company whose founders had access to capital, talent, and conviction that the author does not have. The honest goal is to learn what is learnable, not to score the people involved.
Definitions
These terms are used consistently with the Startup Validation glossary.
- Startup failure — a documented event in which a funded, operating company materially collapsed (shut down, liquidated, sold for parts, or failed to reach a sustainable operating state) with enough public reporting to identify at least one documented cause.
- Documented cause — a failure reason supported by primary or strong secondary reporting (an official statement, a court filing, a founder interview, a credible business publication). Always cited.
- Underlying assumption — a belief held by the founders before the build that, if false, would have invalidated the rest of the plan. Inferred from the documented cause. Always labeled as interpretation.
- Validation lens — the dimension of the startup that the assumption belongs to: problem, customer, solution, pricing, distribution, retention, business model, capital intensity, regulation.
- Preventive experiment — a hypothetical validation test that, in the analyst's reconstruction, would have produced evidence about the underlying assumption cheaper than the eventual failure.
Framework: how to analyze a startup failure
The framework below is deliberately small. Each rung has a clear job; the writer's job is to keep the interpretation where the framework says it goes.
Rung 1: observed outcome
What materially happened, in one sentence, supported by a specific public source. "Quibi shut down in October 2020, six months after launch." Not "Quibi failed because the market didn't want it." The observed outcome is the part of the story you can defend against a critic who asks for a citation.
Rung 2: documented cause
What reporting says happened and why. There are usually several. List them, not one. Each documented cause is anchored to a source. If a single most-cited cause exists, name it; if not, name the two or three that recur across the most reputable reporting.
Rung 3: underlying assumption
The belief held before the build that, if false, would have changed the path. This is the analytical leap. The leap is allowed; the job is to label it as interpretation. A reader who skips the label cannot tell which parts of the analysis are facts and which are reconstruction.
Rung 4: available evidence
What evidence the founders actually had at the time of the assumption — and which evidence they could have produced cheaply. The polite-yes problem (Rob Fitzpatrick, The Mom Test, 2013) lives here: surveys and interviews in which respondents say they want the product are evidence of interest, not of behavior.
Rung 5: missed validation
The validation experiment the founders could have run that would have produced evidence about the assumption before the bulk of the capital was committed. This is also interpretation. The reconstruction is rarely the only possible one.
Rung 6: lesson
One sentence a working founder can act on this week. The lesson is general, not company-specific. "Validate the distribution context before spending on a $1B launch" beats "Quibi failed because they launched during COVID."
Rung 7: preventive experiment
The concrete experiment — a landing page test, a concierge MVP, a paid pilot — that would have produced evidence about the assumption. Same as Rung 5, but framed as a forward action a solo founder can run.
The seven rungs are sequential. A failure analysis that skips Rungs 3, 5, or 7 turns into editorial content. A failure analysis that skips Rungs 1, 2, or 4 turns into speculation.
Real startup failure cases
The five cases below are chosen because each one has multiple credible published postmortems and each one illustrates a different combination of validation lenses.
Every documented cause is anchored to a source — the publication name and year are given where I can verify them. The underlying assumption, the missed validation, and the preventive experiment are explicitly labeled as interpretation. Mixing the two is what makes most startup failure writing misleading.
Case 1: Quibi
Company
Quibi was a short-form mobile-only streaming service founded in 2017 by Jeffrey Katzenberg (former chairman of Walt Disney Studios) and led as CEO by Meg Whitman (former CEO of eBay and a 2016 candidate for governor of California). It launched in April 2020 and shut down in October 2020.
What happened
Quibi raised roughly $1.75 billion in venture capital before launch (Bloomberg, 2020, and multiple secondary reports). It launched with high-profile original programming, including projects starring Idris Elba, Liam Hemsworth, and other A-list talent. By October 2020, six months after launch, the company announced it was shutting down.
Documented reasons
Multiple documented reasons appear across reputable reporting; together they describe a multi-causal failure. The most-cited:
- Launch context. Quibi launched in early April 2020, during the first wave of COVID-19 lockdowns in the United States. The platform was designed for on-the-go, short-form viewing. The launch environment eliminated the "on-the-go" context almost entirely; "on-the-go" became "at home in front of a TV," where Quibi had no app. (The Verge, 2020; Variety, 2020.)
- Platform constraint. Quibi was mobile-only at launch. There was no TV app, no desktop app, no web player. The platform constraint turned an unexpected audience into an unreachable audience. The smart-TV app was added in October 2020, days before the shutdown announcement. (The Verge, 2020.)
- Anti-distribution defaults. Quibi disabled screenshotting and social sharing inside its apps. The designer of the experience treated in-app anti-piracy as a feature; the cost was that no viewer could send a clip to a friend. (Variety, 2020; Hollywood Reporter, 2020.)
- Subscription economics. Quibi offered a 90-day free trial to launch users and charged $4.99/month with ads or $7.99/month without ads. By reported figures from Quibi's own disclosures to investors, the company had only a small fraction of the user base that internal projections had assumed; the trial funnel did not convert enough users into paying subscribers to support the content cost.
Validation lens
The dominant lens is distribution, with a secondary lens on context. Quibi did not validate its core distribution assumption — that high-quality short-form video would be watched primarily in on-the-go moments on a phone — under realistic conditions. The secondary lens was timing; the launch environment was a structural inversion of the use case.
What could have been tested earlier
This is interpretation, not a historical claim about what Quibi's founders knew.
A pre-launch validation experiment might have been a $250K, eight-week test of three contexts:
- A working prototype, distributed to 5,000 invited users across three segments (commuter public transit, on-the-go professionals, home viewers).
- A week of measured view-time per segment, share-rate per segment, completion-rate per segment.
- A pre-launch subscription conversion test at three price points within the three segments.
The cheapest finding would have been the observation that home viewers out-watched commuters 4-to-1 in week one and shared clips 9-to-1 more often when allowed to. That finding alone would have justified building a TV app before launch.
Lesson
Distribution assumptions are environment-dependent. A distribution model that works at noon in 2018 may not work at noon in 2020. Pre-launch validation should include the launch environment, not just the most-favorable environment.
Case 2: Webvan
Company
Webvan Group was an online grocery delivery service founded in 1996 by Louis Borders (co-founder of Borders Books) and led as CEO from 1998 by George Shaheen (then-CEO of Andersen Consulting, now Accenture). It ceased operations in July 2001 after raising roughly $800 million in equity and debt across its four-year run.
What happened
Webvan went public in November 1999 at the height of the dot-com IPO wave. It spent roughly $1.2 billion in venture capital and debt, including over $35 million on its flagship Oakland distribution center, before filing for Chapter 11 bankruptcy in July 2001.
Documented reasons
Multiple documented reasons appear in academic and business analysis of Webvan, most thoroughly in:
- Premature geographic expansion. Webvan built 26 distribution centers across 26 cities simultaneously. By the time of bankruptcy, none of these facilities had achieved a positive contribution margin. The capital expenditure for distribution centers in non-core markets was a recurring primary cause in analysis of the failure. (Fortune retrospective, 2001; Downward Extension strategic-failure research framework used by Hambrick and D'Aveni.)
- Customer acquisition cost and order value. Reported average delivery cost was in the $25–$30 range, against average order values around $85, with margins insufficient to cover the delivery infrastructure at any projected market share.
- Capital intensity. Total capital raised was roughly $800 million in equity plus an additional $400 million in debt financing by the time of bankruptcy. The burn rate exceeded any realistic timeline to contribution-margin profitability.
- Premature scale on an unproven unit. No site operated at unit profitability before the expansion plan began; the expansion plan was an aggressive bet on a non-existent unit, not a tested economics model.
Validation lens
The dominant lens is capital intensity, with a secondary lens on unit economics. Webvan's failure is a textbook case of expanding before validating the unit. The hypothesis that "if we build enough distribution centers we will reach scale economies" was untested at the unit-economics level.
What could have been tested earlier
This is interpretation, not a historical claim about what Webvan's founders knew.
Two validation experiments would have produced evidence about the underlying unit:
- Run a manual delivery service in one ZIP code for six months. Operate the delivery operation with rented vans and contractor labor for one to two thousand paying customers. Measure true delivery cost per order. Measure repeat-order rate. Measure willingness to pay at three price points.
- Test the unit-economics model with a concierge operation, not infrastructure. Replace the $35 million distribution center with a $200K operational pilot and three months of paid deliveries. The hypothesis the expansion plan was based on — that customers wanted delivery and would pay a margin that supports the infrastructure — either holds at the unit level or it does not. If it does not, no amount of expansion was going to make it hold.
The cheaper finding would have been that the unit margin did not close the gap between delivery cost and willingness to pay at the projected market size. That finding would have shifted the question from "how many cities can we expand into" to "how do we close the unit margin."
Lesson
Capital intensity is itself a hypothesis. Building the infrastructure before validating the unit-economics model reverses the order of evidence. The right pre-launch validation in a capital-intensive business is the smallest operation that can produce evidence about the unit margin.
Case 3: Juicero
Company
Juicero was a connected cold-press juicer machine and配套 produce-packet subscription service, founded in 2013 by Doug Evans. The Juicero machine used proprietary squeeze-packets of chopped produce and connected to a Wi-Fi network to authenticate each packet. The product launched publicly at $699 in March 2016, was reduced to $399 in 2017, and the company shut down in September 2017.
What happened
In April 2017, Bloomberg reported that the Juicero machine's proprietary produce packets could be effectively squeezed by hand without the machine. The story made the perceived necessity of the machine a public question; the company's value proposition was the convenience and quality of the squeeze process. After the Bloomberg report, Juicero offered refunds and announced shutdown approximately five months later.
Documented reasons
- Mechanically optional. The Bloomberg investigation demonstrated that the $399-$699 machine was not necessary to extract juice from the proprietary produce packets; human hands worked as well or better. The mechanical value proposition was undermined by reproducible evidence in a single video. (Bloomberg, April 2017 — widely cited; covered contemporaneously by Vox, TechCrunch, CNET.)
- Subscription dependency. The Juicero business model depended on recurring produce-packet subscriptions to underwrite the upfront hardware loss. The mechanical-optional finding reduced the perceived value of the subscription; the customer assumption — that the machine made the subscription worth more than a competitor — disappeared.
- Premium pricing relative to incumbent alternatives. A $399+ machine plus a $5-$8 per-packet subscription compared unfavorably with a $40 masticating juicer or a $5 supermarket cold-press bottle. The willingness-to-pay gap between Juicero and incumbents was larger than the value of the convenience.
Validation lens
The dominant lens is solution fit, with a secondary lens on pricing. The mechanical value proposition was the assumption that, if false, would invalidate the rest of the plan — and the test of that proposition required roughly one minute of physical demonstration by anyone who owned a packet.
What could have been tested earlier
This is interpretation, not a historical claim about what Juicero's founders knew.
A pre-launch validation experiment might have included the obvious test: hand-squeeze 20 randomly selected produce packets and measure extraction yield vs machine-squeeze. If the experiment was anything other than a careful laboratory test of the value the machine added, the founders missed a test that would have cost one dollar per packet and an afternoon.
Lesson
A premium-priced product whose value proposition depends on a process the customer can replicate by hand or with a $40 tool is a fragile assumption. Premium pricing compounds the fragility: the more expensive the hardware, the greater the value the machine must demonstrably add.
Case 4: Homejoy
Company
Homejoy was an on-demand home-cleaning marketplace founded in 2012 by Adora Cheung and her brother, Aaron Cheung. The marketplace matched customers with independent-contractor cleaners in 31 U.S. and Canadian cities. It raised roughly $40 million in venture capital. It shut down in July 2015.
What happened
Homejoy reached meaningful scale in multiple metro markets and served tens of thousands of customers per month. In July 2015, the company announced shutdown; the public explanation cited regulatory headwinds and the inability to raise further funding under the legal cloud.
Documented reasons
- Worker classification. Multiple class-action lawsuits had been filed alleging that Homejoy misclassified cleaners as independent contractors when, under applicable state and federal law, they should have been treated as employees. The legal exposure included potential back wages, penalties, and benefits liability. (CNET, 2015; Recode / The Information reporting on the lawsuits, 2015.)
- Inability to raise under the legal cloud. Adora Cheung stated publicly that the company could not raise a Series C or find an acquirer while the litigation was unresolved. The capital environment at the time included several public-cleaning-services and marketplace exits that suggested the broader thesis was investable; Homejoy's legal exposure was company-specific.
- Geographic expansion ahead of unit economics. Homejoy expanded to 31 markets over roughly three years. Several markets reportedly operated at a contribution margin that did not support the customer acquisition cost in that market.
Validation lens
The dominant lens is business model / regulation, with secondary lenses on unit economics and geographic expansion. The independent-contractor classification was not novel to Homejoy; the broader on-demand cleaning category was confronting the same regulatory question in 2014 and 2015. Homejoy's expansion plan relied on a business-model assumption that had been publicly contested but had not been legally resolved at the time of expansion.
What could have been tested earlier
This is interpretation, not a historical claim about what Homejoy's founders knew.
A pre-launch validation experiment might have included the test of the regulatory assumption before expansion:
- Commission a regulatory opinion in the most likely home state. Establish, with a labor lawyer, the boundary between independent-contractor and employee status under the most likely state laws. The answer would not have eliminated the risk; it would have clarified whether the legal foundation of the business model was contestable.
- Test two markets side by side under different classification regimes. Operate one market with W-2 employees and one with 1099 contractors; compare customer acquisition cost, repeat rate, and operating margin. The test would have produced evidence about the cost of the legal assumption.
Lesson
A business-model assumption that depends on regulatory classification is testable before the expansion is committed. The cost of the legal opinion is small relative to the cost of expansion under a classification that turns out to be contested.
Case 5: WeWork
Company
WeWork was a coworking and office-space operator founded in 2010 by Adam Neumann and Miguel McKelvey. It grew to over 800 locations across 124 cities by 2019. It filed an S-1 for an IPO in August 2019, withdrew the filing in September 2019, accepted a SoftBank bailout, and ultimately filed for Chapter 11 bankruptcy in November 2023.
What happened
WeWork raised an extraordinary $22 billion in venture capital and debt across its life, including the largest single private equity investment in a startup at the time. The S-1 disclosed massive losses ($1.6 billion in 2018, projected $2.5 billion in 2019) and a corporate structure that included related-party transactions, founder control voting shares, and personal acquisitions funded by the company. The IPO's withdrawal and SoftBank's bailout triggered founder Adam Neumann's removal as CEO; the company continued under new leadership before its 2023 bankruptcy.
Documented reasons
- Unit economics did not support the expansion at lease duration mismatch. WeWork signed long-term leases (10–15 years) and rented desks on month-to-month memberships. The mismatch meant every new location required building a critical mass of members before the lease liability was covered; the longer the duration gap, the greater the lease-overhang risk per location. Multiple analysts have published reconstruction of the lease-overhang math; the duration mismatch was a primary cause.
- Founder governance and related-party transactions. The S-1 disclosed personal real estate leased back to WeWork by Adam Neumann and other related-party transactions. The governance structure drew direct criticism in IPO prospectus analyst coverage; the prospectus was withdrawn within weeks.
- Concentration of strategic moves. Like Webvan, WeWork attempted rapid geographic and product-line expansion in parallel. The expansion included WeLive (residential), WeGrow (education), and the Wave (sound-masking office furniture). Each new initiative consumed capital before the prior initiative had reached unit profitability.
- Capital market environment. The WeWork IPO prospectus was filed at the moment of a sharp reversal in public-market appetite for high-burn unprofitable technology companies. The IPO withdrawal was, in part, a function of the public market's reassessment; even a less controversial company would have faced valuation pressure at the same moment.
Validation lens
The dominant lens is business model, with secondary lenses on governance and capital intensity. The WeWork failure illustrates how a business model that works at small scale (subletting 100 desks with a 3-year lease) can invert at large scale (subletting 80,000 desks with 15-year leases) without any change in the underlying demand for flexible workspace.
What could have been tested earlier
This is interpretation, not a historical claim about what WeWork's founders knew.
A pre-expansion validation experiment might have included the test of the duration-mismatch assumption:
- Run 20 locations under a lease-structure test. Half the locations signed standard WeWork 10–15-year leases; half signed shorter-duration leases with break clauses at higher per-desk cost. Track time to lease-overhang recovery, member-acquisition cost, and contribution margin per location over 24 months. The experiment would have produced direct evidence about whether the long-duration lease structure created or destroyed unit value.
- Test the demand for ancillary product lines as standalone businesses. Operate WeLive in three cities and WeGrow in two cities, separately funded, separately priced, without the WeWork member-funnel subsidy. The experiment would have revealed whether the ancillary businesses were individually viable rather than capital attractions for the core business.
Lesson
A business model that depends on a sustained gap between two durable inputs (long leases, short memberships) can invert under the wrong capital market. Lease duration is itself a hypothesis that should be tested before the geographic expansion is committed.
Failure patterns
The five cases above share more than the headline failure. They share recurring validation patterns. The categorization below is mine; treat it as a heuristic, not a taxonomy.
No real problem
The customer problem was weak, overstated, or insufficiently urgent relative to the cost of solving it. Juicero is the clearest example: the problem was the inconvenience of making juice at home, but the alternative was a $5 cold-press bottle or a $40 masticating juicer. The premium-priced Juicero machine added little to that use case.
Weak willingness to pay
Interest existed but payment behavior did not follow. Quibi had strong pre-launch subscriber interest and still failed to convert; WeWork's enterprise segment had strong interest before the IPO but faced a re-pricing of the lease-overhang math.
Distribution failure
The product existed but customer acquisition economics or channels did not work. Quibi's mobile-only launch and anti-distribution defaults cut the natural word-of-mouth loop. Homejoy's geographic expansion outran the natural acquisition channels in some markets.
Product-market misalignment
Users did not receive enough recurring value. Juicero's produce packets did not deliver enough recurring value to underwrite the subscription at the price point. WeWork's long-lease, short-membership mismatch meant that some members churned before the location broke even.
Business model failure
The revenue model could not support the operating model. Webvan's average delivery cost of roughly $25–$30 against an $85 average order and high fixed-cost distribution centers is a textbook case. Homejoy's independent-contractor classification did not support the cross-state scale model under existing legal exposure.
Capital / scale risk
The model required more capital or scale than the business could realistically achieve. Webvan required capital it could not raise in the post-2000 environment. WeWork required public-market capital it could not access at the desired valuation in 2019. Both illustrate that capital intensity is itself a testable hypothesis.
Regulatory / operational risk
External constraints made the business-model assumption difficult. Homejoy's worker-classification lawsuits are the clearest example. The category is real but harder to validate before the fact because the legal answer often depends on the operational details the founders have not yet built.
Most failures are multi-causal. A common mix: weak willingness to pay + capital intensity + mis-timed expansion. A useful diagnostic for any founder studying an outside failure is to ask which two of the seven patterns are most likely to apply to her own current idea.
Startup failure vs. startup validation
Startup failure analysis looks backward and asks what happened. Startup validation looks forward and asks what should be tested next. Lean Startup validation is the methodology that connects them.
The relationship runs in one direction:
Failure Analysis → Identify recurring failure patterns → Convert patterns into assumptions → Design validation experiments → Collect evidence → Make better startup decisions.
Startup MRI is the structured-decision layer above this loop. It does not predict success; it surfaces the unchecked assumption your idea most depends on, and the cheapest experiment that would have produced evidence about it. The analysis above is the diagnostic; the platform is the front-line application.
The reason the discipline matters is that the failure patterns repeat across geographies and decades. Webvan's premature expansion pattern showed up again in WeWork fifteen years later. Juicero's mechanically-optional assumption is a specific instance of a general pattern — "premium-priced product whose value proposition depends on a process the customer can replicate cheaply" — that can be detected before the build by a five-minute comparison shopping trip.
A founder who has internalized the seven failure patterns can usually see them in her own idea without needing to discover them by failing. The discipline is not prediction; it is pattern recognition applied to a single new hypothesis.
What founders should validate before building
The eight-rung pre-build framework below draws from the existing pillars. Each rung links to the existing validation surface.
| Rung | Question | Linked pillar |
|---|---|---|
| Problem | Is the problem real, recurring, and urgent? | Problem-Solution Fit Validation |
| Customer | Can you name the specific person who has the problem? | Customer Discovery |
| Solution | Does the proposed solution demonstrably address the problem? | MVP Validation |
| Market | Is the reachable market large enough for the price point? | TAM / SAM / SOM analysis |
| Distribution | How will the specific customer find the specific product? | Distribution Channels Ranked for Solo Founders |
| Willingness to pay | Will the customer trade real money for the specific solution? | Willingness to Pay Validation |
| Retention | Will the customer come back enough times to make the unit economic? | Product-Market Fit Validation |
| Experiment | What is the cheapest test that can produce evidence about the riskiest rung? | Lean Startup Validation; Startup Validation Checklist; Startup Validation Template |
The rungs are sequential. A founder who reaches the experiment rung without a one-sentence answer to the first seven is running an experiment against an unvalidated assumption set. The cheapest failure to avoid is paying for an experiment whose results the rest of the framework cannot interpret.
The complete operational checklist that turns each rung into a concrete action is in Startup Validation Checklist. The fill-in working document is in Startup Validation Template.
How to turn a failure story into a validation experiment
Each example below takes a documented failure pattern, converts it into an assumption, designs a cheap experiment that would have produced evidence, and identifies the decision the experiment produces.
Example 1: weak willingness to pay
Pattern: Juicero had strong pre-launch media coverage and modest but real pre-orders. Payment behavior did not follow at the projected price point.
Assumption: "A premium-priced connected device + produce subscription will be worth more than a $40 masticating juicer + supermarket produce to the target customer."
Experiment: A 30-day pre-order campaign with three pricing tiers: $199 / $399 / $699, each with a $29 refundable deposit. Stop building when 200 paying deposits have arrived at any tier, or when 60 days have passed at any tier.
Evidence: Real pre-orders at each price point. Polite-yes from interviews is not evidence; a transaction is.
Decision: Continue if ≥ 200 deposits in tier ≥ $399 within 60 days. Change pricing if deposits arrive at $199 but not $399. Stop if no tier clears 100 deposits in 60 days.
Example 2: distribution in context
Pattern: Quibi launched a well-funded product in a context where the distribution assumption was structurally inverted.
Assumption: "Short-form premium content is watched primarily in on-the-go contexts on a phone."
Experiment: A two-week prototype test with 1,000 invited users across three contexts (commuter transit, on-the-go professional, home viewer) measuring view-time per context and share rate per context. The test runs in two contexts: the launch environment and a baseline environment.
Evidence: Context-stratified view-time and share-rate data across the two environments.
Decision: Build a TV-first product if home viewers out-watch commuters by > 3-to-1 and share by > 5-to-1. Change the use case if the inversion is consistent.
Example 3: capital intensity and unit economics
Pattern: Webvan built infrastructure before validating the unit margin.
Assumption: "If we build enough distribution centers we will reach scale economies that close the unit margin."
Experiment: A 6-month manual delivery service in one ZIP code with two thousand paying customers; rented vans; contractor labor. Measure true delivery cost per order, repeat-order rate, and willingness to pay at three price points.
Evidence: Unit contribution margin per order at three price points after 6 months.
Decision: Continue expanding if any price point closes the unit margin within 12 months. Pivot to higher-margin categories or change delivery cost structure if no price point closes.
Example 4: business-model regulation
Pattern: Homejoy expanded under an independent-contractor model that was legally contested.
Assumption: "Independent-contractor status is legally sustainable at our planned scale."
Experiment: A regulatory opinion in the most likely home state, plus a controlled two-market test under W-2 employment vs 1099 contractor, comparing cost and margin.
Evidence: An enforceable regulatory opinion and unit margin under both classifications.
Decision: Continue with the W-2 classification if the margin holds and the regulatory opinion clears. Stop if the regulatory answer is "contestable" and the unit margin does not support the legal cost.
Example 5: founder governance and decision rights
Pattern: WeWork's IPO prospectus disclosed related-party transactions and a founder voting structure that the public market rejected.
Assumption: "A board and governance structure that includes related-party transactions will be acceptable to institutional public-market investors."
Experiment: A 60-day pre-IPO investor read with five institutional public-market investors, presenting the same disclosure set the S-1 would include; record the substantive objections and the probability of an institutional allocation at the desired valuation.
Evidence: Number of meetings requested, number of soft-circles converted to hard-circles, probability-weighted allocation at the target valuation.
Decision: Re-cut the governance before the S-1 if the read produces a low conversion rate or a low allocation probability. The cost of the read is small relative to the cost of filing and withdrawing the S-1.
Common mistakes when studying startup failures
The mistakes below are how a useful failure analysis turns into a misleading one. Each is documented in published writing on cognitive bias and post-mortem methodology.
Hindsight bias
Once we know a company failed, the failure feels predictable. The same evidence reads as obvious after the outcome that read as ambiguous before it. The fix is to write down what the founders knew and what they could have known at the time of the build decision; the "could have been tested earlier" sections in this article are reconstructions, not historical claims.
Oversimplifying a multi-causal failure
Every failure in this article had multiple documented causes. A single-cause narrative is usually clean and usually wrong. The discipline is to list at least three causes per case and to label the most-cited as the most-cited, not as "the" cause.
Assuming one cause explains the category
Quibi is a startup, but the Quibi failure pattern does not necessarily apply to other short-form video or other streaming companies. Category-wide claims from a single case are statistically weak and editorially seductive. The honest claim is about patterns, not categories.
Treating correlation as causation
The frequent co-occurrence of capital intensity with failure does not prove that capital intensity causes failure. Confident-sounding causal claims from observational evidence is the failure pattern of venture-capital twitter, not validation analysis. The fix is to name the cause and the evidence separately.
Using unsourced failure statistics
The "90% of startups fail" line is widely repeated. It has no high-quality primary source. The most commonly cited source is a Stanford Business School lecture that references aggregated data with unstated methodology. The most defensible statistic is the CB Insights Startup Failure Post-Mortem survey, which is a self-report from founders of failed startups — useful, but not the same thing as a population statistic. A reader who treats either line as ground truth has been sold a story, not given evidence.
Copying founder mythology
The "if the founder had been more committed" narrative is biographical, not analytical. The fix is to focus on the assumption the founder held, not on the founder's character. Bias-tested failure analysis treats the founders as agents under conditions of uncertainty, not as protagonists in a redemption story.
Ignoring timing and market conditions
Quibi launched into a once-in-a-century pandemic. Webvan built infrastructure right before the dot-com capital reversal. WeWork filed its S-1 right before the 2019 public-market reversal. Failure analyses that ignore timing attribute to founders what was actually an environment property. The fix is to date the launch and the capital environment, not just the founder's plan.
Confusing "could have tested" with "was knowable at the time"
The preventive experiments in this article are reconstructions. Some of them would have produced evidence that was, at the time, genuinely not knowable. The bias is to assume that, because an experiment would have produced evidence, the founders "should have known" the result. Most of the time they didn't. The reconstruction produces a learning; it does not assign blame.
Decision framework
The framework below turns each of the seven failure patterns into a forward action.
Pattern → Assumption → Risk → Experiment → Evidence → Decision
The decisions a solo founder can make on the basis of one experiment are deliberately small:
- Continue. The experiment produced supporting evidence; proceed with the assumption as written.
- Change the assumption. Rewrite the assumption and design a new experiment.
- Change the customer. Keep the problem, change the segment the segment-specific experiment was tested on.
- Change the solution. Keep the customer, redesign the value proposition.
- Change the channel. Keep the product, change the distribution.
- Change the pricing. The problem and solution hold; the willingness to pay did not. Re-run the test at a different price.
- Stop. The experiment produced enough evidence that the plan is unlikely to work. Stop is a legitimate outcome. It is the most under-used decision in solo-founder validation.
A founder who treats each failure pattern as a typed experiment produces a model of the idea's biggest risk. The model is small, falsifiable, and revisable.
FAQ
What is startup failure analysis?
Startup failure analysis is the discipline of converting documented startup failures into testable assumptions. The work has seven rungs: observed outcome, documented cause, underlying assumption, available evidence, missed validation, lesson, preventive experiment. The first four are anchored to sources; the last three are explicit interpretation.
Why do startups fail?
The most-cited failure causes come from CB Insights' Startup Failure Post-Mortem report, which surveys founders of failed startups. Their 2021 update lists "no market need" (42% of founders cite it), "ran out of cash" (29%), "not the right team" (23%), "got outcompeted" (19%), and "pricing/costing issues" (18%) as the leading self-reported causes. These are post-hoc founder reports, not population statistics; they describe what founders say caused their failures, not the prevalence of any cause across all failed startups. The popular "90% of startups fail" line has no high-quality primary source.
What are the most common startup failure reasons?
Recurring patterns in well-documented failures include: no real problem, weak willingness to pay, distribution failure, product-market misalignment, business-model failure, capital-intensity risk, and regulatory / operational risk. Most failures involve two or three of these at once. See the Failure Patterns section above.
How do you analyze a failed startup?
Start with the documented outcome, supported by at least one reputable source. List the documented causes — usually multiple. Infer the underlying assumption — the belief held before the build that, if false, would have changed the path. Identify the available evidence at the time of the assumption. Design the preventive experiment — the test that would have produced evidence about the assumption. The seven-rung framework above is the working method.
What can founders learn from failed startups?
Three things: the recurring patterns (so you can detect them in your own idea before the build), the discipline of separating documented facts from interpretation (so you do not mistake editorial narrative for evidence), and a vocabulary for the failure modes your own validation framework should test for. Failure analysis is a teacher that gets more useful the more rigorously you read it.
Can startup failure be predicted?
Not reliably. No published method can predict which specific startup will fail. The honest claim is narrower: failure patterns repeat, the assumptions that drive them repeat, and validating those assumptions earlier changes specific outcomes. The discipline is about pattern recognition, not prediction.
How does startup validation reduce failure risk?
Validation reduces failure risk by converting the founders' assumptions into testable hypotheses before the bulk of capital is committed. The discipline is not a guarantee of success; it is a method for narrowing the range of things the founder could still be wrong about. A founder who has run experiments at all eight pre-build rungs knows which rungs are supported and which are still hypotheses.
What is the difference between a startup postmortem and startup validation?
A startup postmortem describes what happened at a specific company after the outcome is known. Startup validation is the forward-looking discipline of designing experiments that produce evidence before the outcome. The two disciplines are complementary: postmortems give you the patterns; validation gives you a method to test for them in your own idea.
Why is willingness to pay important?
Because interest is not payment, need is not payment, and compliments are not payment. The only honest test of value at the price you want to charge is a transaction. Multiple cases above (Quibi, parts of WeWork, parts of Homejoy) had strong customer interest and still did not convert at scale.
How can founders test risky assumptions before building?
Write the riskiest assumption in the form "We believe [customer] will [behavior] when [condition]." Rank every assumption by uncertainty × impact. Design the cheapest experiment that can produce evidence about the highest-ranked assumption. Run it for a specific duration, measure observable behavior, write a one-sentence learning, and decide what to test next. The Lean Startup Validation pillar walks through the eight-step experiment framework in detail.
Are all startup failures caused by bad ideas?
No. The cases above mostly had good ideas in some sense. Juicero was a real product with a real market (cold-pressed juice). Homejoy was a real customer need (cleaning services). Quibi had real interest in short-form premium content. The failures were not at the idea layer; they were at the assumption layer. A good idea with a bad assumption is still a failing startup.
What is the difference between startup failure and pivot failure?
Startup failure describes the company-level event — shutdown, liquidation, sale for parts, or failure to reach sustainable operating state. Pivot failure describes the experiment-level event — an experiment produced negative evidence and the founders did not act on it. The two are related: a company that ignores pivot failures eventually encounters a startup failure.
Summary
Startup failure analysis is the discipline of converting documented startup failures into testable assumptions. The five cases in this article — Quibi, Webvan, Juicero, Homejoy, WeWork — share three patterns: aggressive commitments to assumptions that had not been validated cheaply, expansions that outran the unit-economics model, and reporting that confounded interest with payment. None of the failures were predictable from the idea alone; all were visible from the assumption pattern.
The seven failure patterns — no real problem, weak willingness to pay, distribution failure, product-market misalignment, business-model failure, capital-intensity risk, regulatory / operational risk — recur across geography and decade. The discipline is not a list; it is a typed vocabulary a founder can use to classify the riskiest assumption in her own idea. Each pattern maps to a specific experiment in the validation framework and to a specific decision in the decision framework.
The honest framing is empirical. Failure analysis does not predict specific outcomes. It makes failure patterns visible and converts them into experiments that can be run cheaply before the bulk of capital is committed. The rest of the work is the validation framework already published across this publication.
Related reading
- How to Validate a Startup Idea Before Building — the four-stage validation framework that this article sits inside.
- Why Founders Build Before They Validate — the founder-psychology piece that explains why the failure patterns recur.
- Lean Startup Validation — the Build-Measure-Learn loop and the eight-step experiment framework that converts failure lessons into forward tests.
- MVP Validation — the six MVP methods ranked by signal strength; the rung that converts an assumption into a customer-visible experiment.
- Problem-Solution Fit Validation — the rung that catches the no-real-problem pattern before the build.
- Willingness to Pay Validation — the rung that catches the weak-willingness-to-pay pattern before the pricing assumption hardens.
- Product-Market Fit Validation — the rung that tests the retention assumption once the product exists.
- Customer Discovery — the conversations that produce the assumptions the loop tests.
- Distribution Channels Ranked for Solo Founders — the distribution assumption, treated as the binding constraint.
- The Mom Test Explained for Solo Founders — Rob Fitzpatrick's rules for keeping opinion questions out of the validation loop.
- Startup Validation Checklist — the operational checklist that turns the framework into a 30-day plan.
- Startup Validation Template — the fill-in working document that turns each section into a written artifact.
- Startup MRI Methodology — how the structured second-opinion tool maps to the same validation dimensions.
- The Startup Validation hub — the full reading path and topical taxonomy.
- The Startup Validation glossary — plain-language definitions of validation, MVP, concierge MVP, willingness to pay, and the rest of the validation vocabulary.
What to do next
If you have read this far, the smallest useful action this week is to write down the riskiest assumption in your current idea in the format "We believe [customer] will [behavior] when [condition]." Then classify it under one of the seven failure patterns above and identify the cheapest experiment that could produce evidence about it before the bulk of capital is committed.
The experiment does not need engineering. A landing page, a concierge service, a Wizard-of-Oz workflow, or a paid pilot can produce evidence about most assumptions that fail post-mortems. The discipline is the loop, not the build.
If you'd like a structured second opinion on which failure pattern applies most strongly to your specific idea, Startup MRI's validation analysis is the next step. It takes about five minutes and surfaces the riskiest unchecked assumption your idea most depends on, so the experiment you run is the one with the highest signal.
For examples of what a real validation report looks like, see the SaaS validation report example, the AI startup validation report example, or the mobile app validation report example. Each shows every section your own report will contain, including the critical-assumption callout that names which failure pattern to test first.
Each report also ships with a 7-Day Validation Action Plan derived from that same assumption — one day at a time, with the action, the purpose, and the evidence to collect, plus a Continue / Refine / Re-test / Stop signal on Day 7 — so the preventive experiment you run this week is the one with the highest signal.
The right validator landing depends on the audience: the Startup Idea Validator for general ideas, the Startup Idea Evaluator for founders who use "evaluate" as the verb, and the Startup Score Calculator for a numeric 0–100 read on the same validation dimensions.
Read the postmortems. Classify your idea under one of the seven patterns. Run the experiment. Record the learning. Decide what to test next.
Continue learning
Where to go from here
These pieces are grouped by topic, not publication date — pick the one that matches the question you are working on right now.
More in ValidationSee all topics →
Validation Guide
Lean Startup Validation: How To Choose, Design and Interpret Validation Experiments
How to use Eric Ries's Build-Measure-Learn loop to pick the next validation experiment — including the five-question decision framework, decision-threshold thinking, three labeled hypothetical examples, and the failure modes that distort the loop before the founder notices them.
17 min read
Validation Guide
Problem-Solution Fit: How to Know Your Solution Solves a Real Problem Before You Build It
Problem-solution fit is the state where a defined customer has a defined problem and a defined solution would meaningfully improve their situation. The five rungs of evidence that prove the fit is real, the six failure modes that show it isn't, and the 14-day validation framework that separates real pain from polite enthusiasm.
22 min read
Validation Guide
MVP Validation: How to Test a Minimum Viable Product Before You Build It
MVP validation is the discipline of testing the smallest useful version of your idea before committing months to a full build. Six methods, a five-step framework, and the seven failure modes that show up before the founder notices them.
20 min read
Validation Guide
Product-Market Fit Validation: How to Know You Have It Before You Announce It
Product-market fit is observed, not declared. The four signals that show you have it, the seven failure modes that show you do not, and a 30-day validation framework that separates real retention from paid acquisition.
22 min read
Monetization Validation
Willingness to Pay Validation: How to Test It Before You Build
Why interest is not payment, the five-rung signal ladder from polite words to real money, and a concrete pricing experiment you can run this week — before you write code.
18 min read
Validation Guide
How to Validate an API Startup Idea Before You Build It
The API- and developer-tool-specific tests for technical buyers, integration cost, trust, documentation prototypes, and design-partner pilots — before you write the first endpoint. A practical handbook for API founders, SDK builders, infrastructure product teams, and developer-tool indie hackers.
18 min read
Validation Guide
How to Validate a B2B Startup Idea Before You Build It
The B2B-specific tests for buying committees, procurement, ROI proof, founder-led sales, and the manual pilot — before you write code. A practical handbook for SaaS founders selling to businesses, enterprise software teams, and technical founders.
17 min read
Validation Guide
How to Validate a Chrome Extension Idea Before You Build It
The browser-extension-specific tests for Manifest V3 fit, Chrome Web Store policy, distribution outside store search, willingness to pay, and unlisted pre-launch testing — before you ship a packaged extension. A practical handbook for indie hackers, SaaS founders, AI tool builders, and browser extension developers.
16 min read
Validation Guide
How to Validate a Mobile App Idea Before You Build It
The mobile-app-specific tests for problem, retention, onboarding, distribution, and willingness to pay — before you ship a binary to the App Store. A practical handbook for consumer, productivity, lifestyle, health, education, and local-service apps.
17 min read
Validation Guide
How to Validate a Marketplace Startup Before You Build It
The marketplace-specific tests for supply, demand, liquidity, take rate, and two-sided interviews — before you build the platform. A practical handbook for B2B, consumer, local, creator, and talent marketplaces.
17 min read
Validation Guide
AI Startup vs SaaS Startup: How Validation Is Different
Why AI startups need workflow, output-quality, and dependency tests on top of every SaaS validation question — and the cheapest experiment that proves each one before you build.
18 min read
Validation Guide
How to Validate an AI Startup Idea
Validate an AI startup idea by testing workflow demand, output quality, pricing, model dependency, distribution, and defensibility before building.
21 min read
Validation Guide
How to Validate a SaaS Idea Before You Build It
The five recurring-revenue assumptions that decide whether a SaaS product survives month six, and the cheapest experiment that tests each one — before you write code.
16 min read
Monetization Validation
How to Test Willingness to Pay Before You Build
The polite-yes problem, six pricing experiments you can run this week, and a seven-day plan to ask for money — before you build.
17 min read
Validation Guide
Startup Validation Checklist: Before You Build
21 concrete checks across four validation stages — problem, customer, business, execution — with how to test each one, the common mistake to avoid, and a printable summary.
17 min read
Validation Guide
How to Validate a Startup Idea Before You Build
The four assumptions every startup depends on, the four questions that test them, and the cheapest experiments that produce evidence in 2–4 weeks — before you build.
15 min read
Next in the reading path
How to Validate a SaaS Idea Before You Build It
The five recurring-revenue assumptions that decide whether a SaaS product survives month six, and the cheapest experiment that tests each one — before you write code.
How to Validate an AI Startup Idea
Validate an AI startup idea by testing workflow demand, output quality, pricing, model dependency, distribution, and defensibility before building.
AI Startup vs SaaS Startup: How Validation Is Different
Why AI startups need workflow, output-quality, and dependency tests on top of every SaaS validation question — and the cheapest experiment that proves each one before you build.
See every article on startup validation in one place.
Open the Startup Validation hub →