Product post-mortems have a reliable bias: they record the last visible thing that went wrong. The launch under-performed, so the launch is blamed. Churn spiked in month four, so onboarding is blamed. The number that moved most recently gets the causal story, and the actual defect — which was usually set six or twelve months earlier — goes unnamed.
This matters because the interventions for different failure modes are close to mutually exclusive. A product that nobody needs and a product that people need but never find produce very similar dashboards and require completely opposite responses. Get the diagnosis wrong and you spend a quarter on the wrong fix, then conclude the whole area is dead — which is the more expensive half of the mistake.
What follows is a diagnostic rather than a lament: eight distinct failure modes, the symptom that separates each from its neighbours, the cheap test that would have caught it early, and what to do once you know.
Key takeaways
- Products fail in eight recognisable ways, and the interventions do not overlap.
- Three of the eight — slow value, undiscovered capability, failed rollout — look exactly like "no demand" from the top line.
- The single most useful comparison: how do users who reached the feature behave versus users who never did?
- The earliest reliable signal is a retention curve that never flattens, two to four quarters before revenue shows it.
- Refusing to choose between reinvest, harvest and retire is itself a failure mode.
What "Product Failure" Actually Means
Product failure — definition
A product has failed when it stops producing enough value — for its users or for the business — to justify continued investment, and no available intervention changes that. Failure is a judgement about the trajectory and the economics, not about whether the software works or whether anyone likes it.
Two clarifications save a lot of unproductive argument. First, a product with modest, stable usage and working economics is not a failure just because it does not grow — it is a small business, and the only real question is whether the company wants one. Second, a product can be technically excellent, well designed and widely praised and still fail, because none of those properties is the same as being adopted.
The 8 Failure Modes
1. There was no problem worth solving
The classic. The product answers a question nobody was asking urgently enough to change their behaviour. Users understand it, find it interesting, and carry on with what they were doing.
The distinguishing symptom: people sign up, poke around, and never return — and when you interview them, they cannot describe what they would have used it instead of. There is no incumbent, because there was no job.
The cheap early test: ask what the person does today to handle this problem. If the answer is "nothing, really", you have found either a genuinely new category or, far more often, an absence of need. Jobs-to-be-done interviews surface this in a fortnight, long before a build does.
2. The right problem, the wrong buyer
The problem is real and painful — for someone who is not the person you are selling to. The classic shape is a tool that delights the practitioner and has no budget holder, or one that a manager buys and the team refuses to use.
The distinguishing symptom: strong enthusiasm in demos, long sales cycles that die quietly, or high purchase rates followed by seat usage that never grows past the champion.
The cheap early test: ask who signs, who uses, and who suffers if it goes away — three questions, sometimes three different people. If the sufferer has no influence over the signer, you have a structural problem no feature will fix.
3. The value is real but takes too long to reach
Everything works and the payoff is genuine, but the path to it runs through data import, an integration, an admin invitation and a configuration screen. Users who complete the path are delighted. Most never complete it.
The distinguishing symptom: a steep drop-off concentrated on one or two specific steps, plus excellent retention among the minority who got through. That combination is diagnostic — it means the product is fine and the runway is too long.
The cheap early test: measure time to first value honestly, from signup to the first moment of real payoff, and count how many decisions the user makes before then. Then cut steps rather than adding help text.
4. It shipped and nobody found it
The quietest and most misread mode. The capability exists, solves a real problem, and is genuinely good. It sits behind a menu the user has never opened, and the metrics report it as unwanted.
The distinguishing symptom: among users who did reach it, engagement and retention are strong — and that group is a small fraction of the people who would have benefited. If you have never run that comparison, you cannot rule this out.
The cheap early test: before concluding a feature failed, segment by exposure. Very often the finding is that discovery, not value, was the constraint — and that is the cheapest of all eight modes to repair, because the build is already paid for.
5. Too many features and no clear job
Years of accumulated requests produce a product that technically does everything and legibly does nothing. Each addition was individually justified. The aggregate is a tool that new users cannot form a mental model of.
The distinguishing symptom: long-tenured accounts are healthy while new-user activation steadily declines, and your own sales team needs a whiteboard to explain what the product is for.
The cheap early test: count distinct capabilities used per account. If the average is three out of eleven and falling, you are accumulating bloat rather than value, and the fix is subtraction.
6. The rollout failed, not the product
Especially common in B2B and internal software. The company bought it, the pilot went well, and the organisation never actually switched. Six months later the renewal conversation is about a product most of the seats never opened.
The distinguishing symptom: healthy usage in one team or one region, near-zero elsewhere in the same account, with no product-side reason for the difference.
The cheap early test: at the account level, track how many invited users reached first value in the first thirty days. If enthusiasm sits entirely with the champion, you have a rollout problem — which is solved with change management and in-product guidance for the people who were never in the sales conversation, not with more features.
7. Priced against the wrong value metric
The product delivers, but the meter measures something the customer does not associate with value — seats for a tool used by one person, or usage for a workflow they are trying to reduce. Growth stalls at the point where the price stops matching the benefit.
The distinguishing symptom: accounts deliberately limiting their own usage, sharing logins, or asking for a plan structure you do not offer. Expansion flat while satisfaction is high.
The cheap early test: ask five customers what unit they would expect to pay by. If none names your current metric, the pricing model is fighting the product, and no amount of pricing page work compensates.
8. Everything works and nobody is accountable
The organisational mode. The product exists across three teams' backlogs, each of which owns a slice and none of which owns the outcome. Decay is gradual, nobody is doing anything wrong, and no single meeting is where it dies.
The distinguishing symptom: ask five people who owns it. Five different answers, or five shrugs.
The cheap early test: can you name the person whose goals contain this product's outcome? If not, fix that before anything else — it is the only mode where the first intervention is a structural one.
The single most useful comparison in a product post-mortem. Skipping it is how teams rebuild features that were working and simply invisible.
A Diagnostic: Which Mode Are You In?
Start from the symptom you can actually see, not from the story you already believe. The right-hand column is the test that separates the mode from its nearest neighbour.
| What you observe | Likely mode | The test that confirms it |
|---|---|---|
| Signups fine, nobody returns, no incumbent named in interviews | 1 — no problem | Ask what they do today instead. "Nothing" is the tell. |
| Great demos, deals die, or seats bought and never used | 2 — wrong buyer | Separate signer, user and sufferer. Are they the same person? |
| Sharp drop at one setup step; survivors retain beautifully | 3 — too slow | Retention of completers vs. non-completers. Big gap = runway problem. |
| Feature usage near zero, but strong among the few who used it | 4 — undiscovered | Segment by exposure before concluding anything. |
| Old accounts healthy, new activation falling each cohort | 5 — bloat | Distinct capabilities used per account, trended over a year. |
| One team in the account thrives, the rest are dormant | 6 — rollout | Share of invited users reaching first value in 30 days. |
| High satisfaction, flat expansion, customers rationing usage | 7 — value metric | Ask five customers what unit they expect to pay by. |
| Slow decay, no incident, everyone busy | 8 — no owner | Name the person whose goals contain the outcome. |
The Early Warning Signals You Already Have
None of the following requires new instrumentation. What they require is looking at them together, on a cadence, before the revenue line makes the point for you.
The single most predictive signal, visible two to four quarters before revenue turns. If no cohort reaches a plateau, nothing downstream will save the product. See how to read a retention curve.
Demand is intact and the first-run experience is degrading. Almost always mode 3 or 5, and almost always fixable — funnel analysis localises it in a day.
Track both lines on one chart. A widening gap is mode 4, mode 5, or both — and it is the chart that most reliably changes a roadmap conversation.
Support is a free, continuously updated list of where your product is unclear. Cluster tickets by the screen they mention rather than by category.
You are adding surface area that customers do not value enough to pay more for. Mode 5 or mode 7, and the two need opposite fixes.
Ask three people internally. Divergent answers predict divergent roadmaps, and a product losing the shape of a clear job.
What to Do Once You Know
The value of the diagnosis is that it rules interventions out. Most rescue attempts fail because a team applies the response to a mode it is not in — adding features to a discoverability problem, or rewriting onboarding for a product nobody needs.
| Mode | What actually helps | What wastes the quarter |
|---|---|---|
| 1 — no problem | Narrow to one segment and one job; be willing to restart | Better marketing, more features |
| 2 — wrong buyer | Re-target, repackage, change the entry point | Discounting |
| 3 — too slow | Remove setup steps; defer decisions; pre-fill defaults | Adding a longer tutorial to a long path |
| 4 — undiscovered | Contextual, targeted in-product guidance at the relevant moment | Rebuilding a feature that already worked |
| 5 — bloat | Remove or hide capabilities; make one job obvious again | A navigation redesign that keeps everything |
| 6 — rollout | Change management, in-app guidance for non-champions | Feature parity with whatever the team used before |
| 7 — value metric | Re-meter against what customers call value | Price cuts |
| 8 — no owner | Assign one person the outcome, in their goals | A new steering committee |
Mode 4 deserves special attention because it is both the most common and the cheapest to fix. The engineering is already paid for; what is missing is the moment of encounter. A targeted in-app announcement to the accounts whose behaviour suggests they need it, or a short guided flow at the point of relevance, routinely turns a "failed" feature into an adopted one in weeks. Before you write off any capability, rule this out.
How to Kill a Product Well
Sometimes the correct answer is to stop. Done properly, retiring a product costs you very little goodwill; done badly it damages trust in everything else you ship.
- Decide first, announce once. Moving a deprecation date twice costs more credibility than the original decision.
- Give the real reason. "We are consolidating three overlapping tools" is respected. Silence reads as instability.
- Tell the people who use it, in the product. A targeted in-app notification reaches affected users where the feature lives; a broadcast alarms everyone else for no reason.
- Do the migration work for the common cases. A path that requires customers to rebuild their configuration by hand is a churn event with a polite note attached.
- Keep the old surface reachable and clearly marked until the date, then remove it cleanly. Half-removed features that error out are worse than either state.
- Write the post-mortem against the eight modes, not against the last thing that broke — otherwise the next product inherits the same defect.
Product Failure: Do vs. Don't
✓ Do
- Segment by exposure before declaring a feature unwanted
- Watch the retention curve's shape, not just its level
- Separate signer, user and sufferer in B2B
- Track capabilities shipped against capabilities used
- Name one person accountable for the outcome
- Choose explicitly between reinvest, harvest and retire
✗ Don't
- Blame the last visible thing that went wrong
- Answer a discoverability problem by building more
- Add a tutorial to a path that should be shorter
- Read low usage as low value without checking exposure
- Let a declining product drift without a decision
- Announce a shutdown by email alone
The One-Paragraph Version
Products fail in eight distinguishable ways: no problem worth solving, the wrong buyer, value that takes too long to reach, a capability nobody discovers, bloat that obscures the job, a rollout that never happened, a price metered against the wrong thing, and nobody accountable. Three of them — slow value, undiscovered capability, failed rollout — look exactly like an absence of demand from the top-line numbers, which is why so many post-mortems reach the wrong conclusion. Diagnose from the symptom, confirm by comparing users who reached the value with users who did not, and apply only the intervention that matches. And when the honest answer is to stop, stop deliberately: announce once, explain why, and do the migration work yourself.
Rule Out the Cheapest Failure Mode First
Before you rebuild a feature, check whether anyone found it. Kompassify lets you put product tours, contextual guides, checklists and targeted announcements in front of the exact accounts whose behaviour shows the gap — and measure whether adoption moved. No code required. Free up to 100 monthly active users, from $129/mo after that, GDPR-compliant and EU-hosted.
Start for Free →Frequently Asked Questions
Why do most products fail?
There is no single cause, which is precisely the problem with the question. The eight recurring modes are: no problem worth solving, the right problem for the wrong buyer, real value that takes too long to reach, a product that ships and is never discovered, too many features with no clear job, a rollout failure rather than a product failure, pricing tied to the wrong value metric, and nobody accountable for the outcome. The middle three are the most commonly misdiagnosed, because from the top-line numbers they look identical to a lack of demand.
What is the difference between product failure and lack of product-market fit?
Lack of product-market fit is one specific failure mode: the product does not solve a problem this segment cares enough about to keep paying for. Product failure is the broader category, and several of its modes occur in products that genuinely do have fit — a product with real fit still fails if users cannot reach the value quickly, cannot find the capability that delivers it, or if the rollout inside a customer's organisation never happens. Treating every failure as a fit problem sends teams back to discovery when the actual defect was downstream of the build.
How do you tell an adoption problem from a product problem?
Compare the behaviour of users who reached the feature with users who did not. If the people who actually used it retain, come back and expand, while the majority never encountered it, you have an adoption problem — the value is real and the distribution is broken. If the people who used it also churned at the same rate as everyone else, the value is not there and you have a product problem. Teams that skip this comparison routinely rebuild features that were working fine and were simply invisible.
What are the early warning signs that a product is failing?
The most reliable early signal is a retention curve that never flattens, because it precedes revenue decline by two to four quarters. After that: activation rate falling while signups hold, a widening gap between the number of capabilities shipped and the number used per account, support tickets clustering on the same first-run step, and expansion revenue flattening while the feature list grows. All four are visible in data most teams already collect and rarely look at together.
Can a failing product be saved?
Often, but only if you correctly identify which failure mode you are in — the interventions are almost mutually exclusive. A discovery problem is fixed by narrowing to a segment and rebuilding around one job. A time-to-value problem is fixed by removing setup steps, not by adding features. A discoverability problem is fixed with in-product guidance and is frequently the cheapest of all to repair. Applying the wrong intervention costs you a quarter and, worse, produces evidence that seems to rule out the area entirely.
Is a product with users and no growth a failure?
Not necessarily. A stable product with loyal users and healthy unit economics is a legitimate business outcome that gets labelled failure only because growth is the default measure. The honest questions are whether the economics work without continued investment and whether the team is being asked to produce growth the market cannot supply. What is a genuine failure is drift: refusing to decide between reinvesting, harvesting and retiring, and letting the product decay while consuming the team's attention. See the product lifecycle stages for how that decision is normally framed.
How do you kill a product without damaging your reputation?
Decide the date before you announce, communicate once and clearly, give the actual reason, and target the message at the accounts that use the product rather than broadcasting it to everyone. Provide a migration path with the work already done for the common cases, keep the old surface reachable and clearly marked until the date, then remove it cleanly. Customers forgive discontinuation far more readily than they forgive surprise, moved dates, and being left to reconstruct their setup by hand.