Product decision failure modes
Product failures have causes, mechanisms, traces, and consequences.
A weak product decision rarely appears from nowhere. The reasoning may be wrong, incomplete, or stale. But the conditions around the decision matter too: who had authority, what people were rewarded for, which evidence reached the room, whether the decision maker had enough capacity, and whether someone could challenge the commitment.
The failure often becomes visible later in a roadmap, PRD, research summary, release plan, or outcome review. That document is a trace of the problem. It is not always where the problem began.
This catalog describes 52 recurring failure modes across both levels. Use it to follow a real decision from the working conditions around it, through the choice itself, into the artifacts it produced and the consequences that followed.
From condition to trace
The document is where a failure becomes visible, not always where it began.
This fictional brief shows how a decision failure can leave a visible trace in writing. The CRO's priority, the missing alternatives, the assumed customer need, and the success criteria appear in the document. The document alone cannot tell us why those conditions existed. The cause could involve decision authority, incentives, missing customer evidence, workload, or a reasonable constraint that is not written down. Select a highlighted passage to see what the text supports reviewing.
Leadership has identified a clear need for a unified customer view. , and today they are switching between four screens to get it.
surfacing activity, contract status, open tickets and health score in one panel.
The dashboard will drive better retention conversations.
Success criteria.
Alternatives considered.
The example links four claims to possible failure modes. Those matches describe what is visible in the brief: a customer need without a source, a solution commitment with no alternatives, an untested behavior assumption, and delivery measures used as success criteria.
The same traces can have different causes. A solution chosen early might come from executive authority, a contractual commitment, a deadline, an overloaded team, or simply a decision whose rationale was never written down. The artifact tells you where to investigate; it does not establish motive or organizational cause.
A useful review therefore moves in both directions: backward to the working conditions and evidence that shaped the decision, and forward to the work and outcomes that followed.
The system around the decision
The failure modes sit inside a larger product system.
The catalog is organized around six recurring product decisions: which problem to address, whose problem it is, whether it is worth solving, which solution to try, whether to continue, and whether the work produced the intended result. Other modes concern the seams between those decisions, decision authority, and whether the reasoning is legible to the people who need it.
But a failure mode is only the middle of the story. A recurring product problem often follows a chain: working condition → decision pressure → failure mode → artifact trace → delivery consequence.
The working conditions worth checking are broader than the org chart. Who can set priorities and change commitments? What do rewards encourage? Does decision workload match available capacity? Do research, design, and engineering influence the choice early enough? Does customer evidence reach the people making the decision? Can someone challenge a senior commitment without the concern disappearing?
These conditions do not mechanically cause a failure. A sales commitment may be legitimate. A senior leader may have context the team lacks. A specialist may join late for good reasons. Treat the conditions as possible explanations to investigate, not as diagnoses.
Start with a real decision. Identify the visible failure pattern, then look backward for the conditions and evidence that shaped it. Finally look forward at what the team built, what happened, and whether the result changed the next decision.
Which problem
Choosing what to work on. These patterns can allow requests, incentives, or unclear priorities to displace a reasoned comparison of customer problems.
Whose problem
Identifying the people affected and their circumstances. These patterns can lead teams to generalize beyond the evidence or rely on an assumed customer profile.
Whether it's worth solving
Assessing whether an investment is worthwhile. These patterns can obscure demand, costs, incentives, or the consequences of technical debt.
Which solution
Choosing and testing an approach. These patterns can narrow the options too early, omit relevant expertise, or leave important assumptions unexamined.
Whether to continue
Deciding whether to continue, change, or stop. These patterns can prevent new information from influencing the remaining investment.
Whether it worked
Assessing the result. These patterns can substitute completed work for evidence of benefit or make success difficult to evaluate.
The seams
Preserving context between teams and stages. These patterns can separate research, design, planning, and delivery from the evidence and reasoning they need.
Authority
Making decision rights and accountability workable. These patterns concern who can decide, who must be involved, and how unresolved choices are handled.
Legibility
Making reasoning understandable to others. These patterns can conceal trade-offs or leave people with conflicting interpretations of the same direction.
The failure-mode catalog
Explore the 52 recurring failure modes
Document review
A document can show the trace. It cannot always show the cause.
Upload a PRD, strategy brief, roadmap narrative, or business case. The review looks for failure patterns that are visible in the text itself: unsupported assertions, hidden assumptions, causal claims that outrun the evidence presented, missing alternatives, and success criteria that measure completion rather than benefit.
The review cannot tell from one document whether research elsewhere contradicts the claim, whether another team is funding the same assumption, whether the evidence has gone stale, whether a senior commitment constrained the choice, or whether a shipped change caused an observed outcome.
Treat each finding as a prompt for investigation. A clean result means no applicable check flagged the text. It does not verify the underlying decision.
Dispatchers want one place to write up what happened on a shift