The product failure ontology

We named 52 ways product work can go wrong so
your team doesn't have to keep re-discovering them

They usually begin with a reasonable-sounding claim:
“Users need this.”
“This is our highest priority.”
“We know what to build.”
“We will know it worked when we ship it.”
This catalogue describes 52 recurring ways product reasoning breaks down—and the warning signs those failures leave in briefs, PRDs, roadmaps, research reports, and backlog items.

52

Failure modes

9

Clusters they corrupt

260

Published signatures

v1.1

Current edition

01 — The specimen

What a failure looks like in practice

A normal-looking brief can hide weak reasoning. The brief below looks plausible. It identifies a user need, proposes a solution, includes an estimate, and defines success. But several of its claims rely on missing evidence, untested assumptions, or decisions made too early. Select a highlighted passage to see what may be wrong and what the team should investigate.

brief — unified customer view — draft 3

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.

Claims in the document· 5

Readout

Five claims. Eight modes across four of them, and one claim that comes back clean. A single claim can carry more than one failure — the solution claim carries three, because committing without alternatives and committing on authority are separate failures that arrived in the same sentence.

How it's organised

Failures are grouped by the decision they corrupt.

A product organisation makes six decisions, continuously, whether or not it names them. Thirty-six of these modes sit under one of the six. Six belong to the seams between them. The last ten aren't decisions at all — they're conditions that every decision either has or lacks.

1

Which problem

Failures in choosing what the team works on at all.

9 modes
2

Whose problem

Failures in specifying who actually has it.

4 modes
3

Whether it's worth solving

Failures in sizing the bet against what being wrong costs.

3 modes
4

Which solution

Failures in choosing the approach.

13 modes
5

Whether to continue

Failures in stopping.

6 modes
6

Whether it worked

Failures in checking.

5 modes
—

The seams

Failures belonging to no single decision, where reasoning is dropped in the handoff.

6 modes
A

Authority

Whether the person accountable is the person deciding. Cuts across all six.

3 modes
B

Legibility

Whether the reasoning survives outside the head that had it. Cuts across all six.

3 modes

The catalogue

All fifty-two

Showing 52 of 52

Which problem

Whose problem

Whether it's worth solving

Which solution

Whether to continue

Whether it worked

The seams

Authority

Legibility

04 — Run it

See how it reads our documents — then run your own.

A run experience: watch what the scanner reads on four documents we own, then upload your own and get the same read back — every claim, the failure modes detected on it, the quote it read and the rule that fired. No score anywhere.

Sample documents · pre-computed when this page was built
MODEL CALLAVAILABLE
Source documentBRIEF · CONFIDENCE 0.94 · 940 WORDS
BRIEF — SHIFT HANDOVER — DRAFT 2 Owner: Dispatch Product · Reviewer: VP Operations · Status: For approval Background Operations leadership raised handover as the top gap in the quarterly review. Dispatchers want one place to write up what happened on a shift, and today they use a shared spreadsheet nobody reads. Incidents that begin on one shift and resolve on another lose their context in the gap, and the receiving dispatcher often re-derives what already happened. Proposal We will build a structured handover form with incident tags, a free-text log and an acknowledgement step on the receiving shift. The form attaches to the active incident and travels with it across shift boundaries. Engineering has sized this at four weeks. Rationale The competitive window closes in Q3 — two accounts are evaluating alternatives that ship handover today. Losing either would set the segment back a full renewal cycle. Success criteria Handover form live for every dispatch team by 30 September, with positive feedback from the two accounts in evaluation. Alternatives considered None. The VP Operations asked for the form specifically.

17 of 52 modes are checkable from a document of this type. The scanner checks only those.

Claims in document order

Failure modes on claim C1The stated user need
01Stakeholder LaunderingDeterministic
Dispatchers want one place to write up what happened on a shift
RuleNeed asserted with no source, no named user and no research reference in the same section.
6CLAIMS EXAMINED
5WITH FINDINGS
1CLEAN
0NO EVIDENCE EITHER WAY
9MODES NAMED

No score, no grade, no percentage — not on screen and not in the response. A claim carrying three failures and a claim carrying one are different problems.

The scanner checks only the modes that are checkable from a document of this type — the rest need context a single document of this kind structurally cannot contain.