Product Integrity • Decision failure modes
Product decisions often fail in recurring ways—whether by choosing the wrong problem, confusing stakeholder preferences with customer needs, or tracking delivery over actual outcomes. While some warning signs appear directly within the decision document, others stem from the surrounding environment, such as skewed incentives, limited capacity, or a lack of psychological safety to challenge requests.
Product decisions go wrong in the same 52 ways, again and again. This page names them, shows how to spot them in a brief, and shows the conditions around a team that make them likely.
52
Failure modes
9
Decision questions
6
Organizational Conditions
Definition
A failure mode is a recurring way that a product decision can lose contact with the things that should be holding it up.
It is not proof that a decision is wrong. It is a signal that a claim, assumption, relationship, or condition deserves closer examination.
The purpose is not to diagnose people or assign blame. It is to make recurring patterns easier to notice while the cost of changing course is still low.
A decision can lose contact with
Two levels of investigation
A decision can be examined from two connected directions.
The document gives you signals. The organizational context helps you investigate them.
Level one
What does the brief, roadmap item, request, or commitment claim?
Level two
What organizational conditions may have shaped the decision?
The failure-mode catalog
Every product decision has to answer these. Each category holds the recurring ways the answer goes wrong.
Failures in choosing what the team works on at all.
9 modesFailures in specifying who actually has it.
4 modesFailures in sizing the bet against what being wrong costs.
3 modesFailures in choosing the approach.
13 modesFailures in stopping.
6 modesFailures in checking.
5 modesFailures belonging to no single decision, where reasoning is dropped in the handoff.
6 modesWhether the person accountable is the person deciding. Cuts across all six.
3 modesWhether the reasoning survives outside the head that had it. Cuts across all six.
3 modesFailure-mode catalog
Filter the ontology by decision cluster, then expand a mode to read its definition, document signatures, and nearby failure modes it can be confused with.
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
Specimen
An anonymized document from one of our customers. Every marked passage is a surface signature. Select a flag, or a marked phrase.
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.
Claims examined
Readout
A single document can show explicit claims, missing support, untested assumptions, absent alternatives, and delivery measures standing in for outcomes.
App slot / Decision brief scanner
The scanner reviews the claims in a product document and links each signal to the claim that produced it. There’s no score.
17 of 52 modes are checkable from a document of this type. The scanner checks only those.
Claims in document order
Dispatchers want one place to write up what happened on a shift
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.
A document review tells you where to investigate next. It can establish explicit claims, missing support, contradictions, assumptions, absent alternatives, unclear success criteria, and where additional context is needed. It cannot establish alone why the decision was made, what evidence existed outside the document, who had authority, whether organizational pressure shaped it, whether the outcome was successful, or whether a failure mode caused the result.
| The document shows | What you still need to know | Where that answer lives |
|---|---|---|
| A customer claim with no source | Whether evidence exists elsewhere | Interviews, feedback, support tickets |
| A solution chosen before alternatives | Who chose it, and why | Decision records, meeting notes |
| A behavior change assumed | Whether it happened | Product analytics |
| Delivery measures used as outcomes | Whether the outcome was reached | KPIs after release |
| Unclear authority or commitment | Who had the authority | Decision rights, the org itself |
| No stopping criteria | Whether pressure kept it alive | Roadmap and decision history |
Read findings carefully
A document review shows what was claimed, what was omitted, and which links in the reasoning are weak or missing. The right response to a finding is investigation, not automatic rejection.
A failure mode can be local to one decision. When the same pattern appears repeatedly, the problem may sit in the environment around the team.
The document alone cannot establish
Organizational structure and product decisions
Organizational structure affects who can set priorities, whose information reaches a decision, and what happens when someone challenges a commitment. The org chart shows reporting relationships. To understand product decisions, you also need to examine rewards, workload, decision authority, and how people share evidence.
When the same problem recurs across projects or leadership changes, these working conditions deserve investigation. They can make some choices easier and others harder, even for capable people. A reporting line alone does not establish the cause of a poor decision.
This page describes six areas to examine, the failure patterns that may be associated with them, and practical changes to consider. We build Shorter Loop for product teams, so we also explain where software can help and where leaders need to change how the organization works.
Structure
The failure modes are visible in documents, but many of them are produced upstream by organizational structure. Many failure modes show up in documents but start upstream, in how the organization is set up. Where product reports, what people are rewarded for and how thin a PM is spread make some decisions easy and others close to impossible, even for capable people.
The arrangement
Whether the product function reports to a customer-facing revenue leader, to engineering, or to the chief executive. And separately, whether individual PMs report into a product organisation or into the business unit they serve.
What it produces
Problem selection stops being a product decision. Requests arrive already chosen, carrying the authority of whoever made them, and the PM's work becomes solving them well. The tell is subtle: nobody in this arrangement believes they are overriding evidence. They believe they are being commercially responsive, and much of the time they are.
Failure modes it produces
Diagnostic - run this week
Take the last ten roadmap items. For how many can you name the person who wanted it faster than you can name the evidence for it?
The intervention
Moving the reporting line, which is a board-level conversation. Short of that: making the origin of every roadmap item a recorded field. It does not fix the capture, but it makes the capture visible, which is a precondition for anyone doing anything about it.
The arrangement
What the bonus, the review and the promotion criteria actually depend on. Not the stated ones: the ones that decided the last three promotions.
What it produces
If the reward depends on shipping, shipping becomes the goal, and every metric the team adopts will be one it can control. This one is close to unbeatable by individual virtue. A PM who prioritises outcomes in an organisation that promotes throughput is choosing to be worse off, and most people are sensible.
Failure modes it produces
Diagnostic - run this week
Name the last person promoted in your product organisation, and say why.
The intervention
Tying part of the review to an outcome measured after release, which requires someone to still be looking after release.
The arrangement
The ratio. One PM to one team, or one PM to four.
What it produces
Presence is a capacity question. Beyond about two teams a PM becomes a queue, decisions get made in their absence by whoever is present, and reasoning stops being recorded because there is no time. The organisation usually reads this as a performance problem in the individual. It is arithmetic.
Failure modes it produces
Diagnostic - run this week
Count the open questions in current planning documents that are addressed to a PM.
The intervention
Hiring, or reducing the number of teams. Both are expensive, which is why this persists longer than the others. The partial mitigation is deciding explicitly which decisions a team may make without the PM, so absence produces delegation rather than drift.
The arrangement
Functional reporting lines with their own leaders, their own roadmaps and their own definitions of good work, versus reporting into the product team.
What it produces
Each function optimises its own output, and the handoffs become where reasoning is dropped. Functional structures exist for good reasons: craft quality, career progression, consistency. The cost is paid at the seams, the seams belong to nobody, and so the cost is invisible in every function's own reporting.
Failure modes it produces
Diagnostic - run this week
Find the last discovery study your organisation completed. Was an engineer in the room while the hypotheses were formed, and what changed in the roadmap because of it?
The intervention
Keep functional reporting for craft and career, and make the team the unit that owns the decision, with a named artifact that crosses the seam and a requirement that it be referenced downstream.
The arrangement
Whether anything structurally connects support, sales and customer success to product decisions. Not goodwill, and not a Slack channel: an owned route with a person accountable for it.
What it produces
The richest evidence in the company sits with the people who talk to customers all day and never reaches the decision. It is why organisations simultaneously complain about lacking customer insight and drown in unread customer contact.
Failure modes it produces
Diagnostic - run this week
Ask your head of support which three problems generate the most contacts. Then check your roadmap.
The intervention
One person accountable for routing and synthesising it, on a defined cadence, with the output landing where roadmap decisions get made.
The arrangement
What happens, socially and professionally, to a product manager who declines a senior stakeholder's request and writes down why.
What it produces
Where it is not survivable, scope grows to accommodate everything, nothing is deprioritised on the record, and reasoning stops being written because writing it creates exposure. This is the hardest of the six to see from inside, because the behaviour looks like collaboration.
Failure modes it produces
Diagnostic - run this week
Find a written record of a PM declining a request from someone senior, with reasoning, in the last quarter.
The intervention
A senior person visibly backing a refusal, once, in public. The cheapest of the six interventions, and the one most dependent on an individual choosing to spend capital.
Organizational diagnostic
Answer from recent decisions and records, rather than general impressions. The readout highlights areas suggested by your answers; a flagged area is a prompt for review, not a diagnosis or a maturity score.
In recent product commitments, was work approved without reviewing its evidence, constraints, or trade-offs?
Do performance reviews reward completed work while overlooking evidence about its benefit and the team’s response?
Are important decisions repeatedly delayed because the responsible person is unavailable and nobody else can decide?
Did recent solution decisions miss relevant specialist input until the choice was difficult to change?
Can you trace important customer findings to a product review and an explained decision about what to do?
When people raise evidence-based concerns about a senior request, are those concerns dismissed without review or treated as disloyalty?
Connect your product work and let Shorter Loop trace the evidence, assumptions, reasoning, and delivery behind your decisions as they change.
FAQ
It's a detection spec. Each of the 52 modes has a description and surface signatures, meaning what the failure looks like in a written artifact: 260 in total, version 1.1. It came out of 26 years of watching product decisions go wrong. It was piloted by classifying the CB Insights failure corpus, and it's tested against a benchmark of 100 documents across four product domains with known, planted problems.
We analyzed 128 Documents from 15 product teams over a period of 4 years.
We're measuring precision and recall on the benchmark and will publish them here. If you would like to help, join our Design Partner Program
A surface signature is the symptom in the text. A failure mode is the recurring pattern. An organizational condition is the likely cause, and it needs investigating.
Yes, all findings are subject to user review. A user can reject any finding they deem incorrect.
Yes, in the product. Feedback, analytics, CRM and delivery tools connect through native connectors, MCP and CSV. The scanner on this page reads the document only. Check out our integrations page to know more about how we do it.
Yes, when the outcome is stated as something measurable. Each solution or roadmap item carries its expected outcome: the metric, the target, and when to check. After release, the item moves to In Assessment. Shorter Loop then reads the metric from your connected sources, pulling from analytics, CRM or billing over MCP, or receiving data you push over the API. It marks the prediction as met or missed, with the data attached. If an item has no measurable outcome, it's flagged instead of quietly counted as a success.
It shows whether the outcome happened. Whether the release caused it is a separate question, and Shorter Loop keeps those two apart.
Each finding comes with what to investigate. In the product, Sage fetches missing evidence from connected sources. The response itself (more evidence, smaller scope, a test, or stopping) stays with the team.
The page scanner is one-off. In the product, claims are rechecked whenever new evidence arrives, and integrity checks run on a schedule.
They do different jobs. A careful human review of one important decision will catch things Shorter Loop can't: politics, context nobody wrote down, a hunch worth testing. What a human can't do is re-read every decision each time a new support ticket, interview or metric arrives. A product team gets hundreds of those a week. Shorter Loop checks each one against the claims your roadmap rests on and flags the ones that change something. That way your team's review time goes to the decisions that need it.
We are working with our design partners to measure the improvements