Product Integrity
Product decisions fail for more than one reason.
A weak decision can come from the reasoning itself: the wrong problem, the wrong customer, a solution chosen too early, or an outcome never checked. It can also come from the conditions around the decision: unclear authority, incentives, overloaded roles, missing specialist input, or customer evidence that never reaches the people making the choice.
This page brings those two views together. The aim is not to diagnose people. It is to make recurring failure patterns easier to notice, investigate, and correct while the cost of changing course is still low.
TWO PLACES TO LOOK
Look at the decision, then look at the system around it.
A product decision can be poorly reasoned even inside a healthy organization. A sound decision can also be distorted by the way authority, information, incentives, and workload are arranged. Reviewing only one level misses half the problem.
Decision-level failure
The problem is in the choice or the reasoning behind it. Examples include treating a stakeholder request as a customer need, committing to a solution before comparing alternatives, generalizing beyond the evidence, or declaring success because the work shipped.
System-level failure
The surrounding conditions make good decisions harder. A team may lack the authority to change a commitment, rewards may favor output over benefit, one person may become a decision bottleneck, or relevant evidence may arrive after the choice is already difficult to change.
THE DECISION MODEL
The failure catalog follows the decisions product teams keep making.
The catalog groups recurring failure modes around choosing a problem, understanding who has it, deciding whether it is worth solving, choosing an approach, deciding whether to continue, and assessing whether the work produced the intended result. It also covers the seams between those decisions, decision authority, and whether the reasoning is legible to other people.
- Which problem should we address?Requests, incentives, or unclear priorities can displace a reasoned comparison of customer problems.
- Whose problem is it?Teams can generalize beyond the evidence or rely on an assumed customer profile.
- Is it worth solving?Demand, cost, incentives, or technical consequences can be misunderstood or omitted.
- Which solution should we try?The options can narrow too early or important assumptions can remain unexamined.
- Should we continue, change, or stop?New information may fail to influence the remaining investment.
- Did it work?Completed work can be mistaken for evidence that customers or the business benefited.
THE ORGANIZATION AROUND THE DECISION
Recurring decision problems can come from working conditions, not from a careless PM.
When a pattern repeats across projects or survives a change of people, examine the conditions that shape the decision. Reporting lines are only one part of that. The more useful questions are about authority, incentives, workload, specialist input, information flow, and whether people can challenge a commitment constructively.
Who can set priorities and change commitments?
A request can become a commitment before product, research, design, or engineering has a workable chance to examine the evidence, constraints, and trade-offs.
What do performance reviews and rewards encourage?
Rewards centered on completion can weaken the incentive to revisit whether the work is useful. Narrow outcome targets can create different problems, including gaming or unfair accountability for factors outside a person's control.
Does decision workload match the available capacity?
Important choices can wait on one overloaded person, or teams can proceed on inconsistent assumptions because nobody else has authority to decide.
Do the right disciplines influence the choice early enough?
Research, design, and engineering input is less useful once a solution is already difficult to change.
Does customer evidence reach the decision?
Support, sales, research, and usage data can remain isolated even when the organization technically has access to all of it.
Can people challenge a commitment constructively?
If a well-supported objection has no route to resolution, concerns may stay undocumented and conflicting commitments can survive longer than they should.
WHERE SOFTWARE HELPS
Some failure modes are information problems.
A shared system can keep evidence, assumptions, decisions, delivery work, and outcomes easier to find and relate. That can reveal stale evidence, duplicated assumptions, missing rationale, and work that no longer connects to the reason it was funded.
WHERE LEADERSHIP HAS TO ACT
Authority, incentives, staffing, and reporting relationships are organizational decisions.
Software can make the consequences easier to see. It cannot give a team authority that leaders withhold, change evaluation criteria, resolve a staffing problem, or make it safe to challenge a senior commitment. Those require people with the relevant authority to act.
DOCUMENT REVIEW
A single document can show warning signs. It cannot establish the whole case.
The document review looks for patterns visible in a PRD, strategy brief, roadmap narrative, or business case: unsupported assertions, hidden assumptions, causal claims that outrun the evidence presented, missing alternatives, and success criteria that measure completion rather than benefit.
What one document cannot tell you
It cannot know whether research elsewhere contradicts the document, whether another team is funding the same assumption, whether evidence has gone stale, or whether a shipped change caused an observed outcome.
Those questions need the wider product context, not just the text on one page.
Use the catalog to investigate a real decision,.
Start with one current decision. Compare the warning signs with the evidence that was available, look for alternative explanations, and decide what proportionate follow-up would reduce the uncertainty.