The six ways a PRD contradicts itself
Contradictions in specs are not random. They arrive in recognisable shapes.
A specification rarely contradicts itself on the same page. It contradicts a decision made three weeks earlier in a different tool, or a revision of itself that nobody reconciled. Reading enough of them, the same shapes keep appearing.
1. Scope inherited from a dead revision
A section survives a rewrite because nobody re-read it. The document says a capability is out of scope while a later section describes its behaviour in detail.
2. Research overruled silently
An interview establishes a hard requirement. The requirement never makes it into the document, and no note records that it was considered and rejected. Both states — 'forgotten' and 'deliberately dropped' — look identical afterwards.
3. The undefined default
Retry counts, timeouts, empty states. The document assumes a default that was agreed verbally and written nowhere, so two engineers implement two different ones and both are correct.
4. Two owners, one behaviour
Two teams each specify the same interaction from their own side. Neither is wrong in isolation. Together they describe an interface that cannot exist.
5. The design that specifies itself
A Figma frame contains a state the document does not mention. Whoever builds it follows the frame, which quietly becomes the specification without ever being reviewed as one.
6. The constraint that expired
A limitation drove a design decision. The limitation is gone. The decision remains, and is now defended by people who never knew why it existed.
The pattern behind the pattern
Five of the six are not writing failures. They are reconciliation failures — the document is fine, and the thing it disagrees with lives somewhere else. Which is why proofreading a PRD does not find them, and reading a PRD against everything around it does.
Stop writing PRDs without understanding the product.
Anchor reads your interviews, tickets and docs first — then writes, citing every line.
