All posts
A checklist for the PRD you're about to send
Eleven questions. If you cannot answer one, the document is not finished.
Dana Reeves5 min read
Most review cycles are spent discovering things the author could have caught alone. This is the list that catches them.
Completeness
- Does every requirement have a failure case?
- Does every limit have a number?
- Is there a stated behaviour for empty, slow and offline?
- Have you said what is explicitly out of scope?
Consistency
- Does anything here contradict the previous revision without saying so?
- Does anything contradict a decision made in another tool?
- Does the design file contain a state this document does not?
Accountability
- Is every open question assigned to a person, not a team?
- Is it clear who breaks a tie during implementation?
- Can a reader tell which parts are decided and which are proposed?
- Could someone who joined this week act on this without a meeting?
The last one is the real test. Every other item is a proxy for it.
PlaybookPRDsCraft
Stop writing PRDs without understanding the product.
Anchor reads your interviews, tickets and docs first — then writes, citing every line.
