How to sanity-check a PRD before you hand it to engineering

A PM asked the quiet question everyone has: before a PRD goes to engineering, is there a real checklist and review process, or is it just experience and instinct? And how confident do you actually feel at that point?

Honest answer: for most people it's instinct, and instinct is exactly why the same category of miss keeps shipping. Another thread captured the consequence — a PM asked when engineering last pushed back on their PRD, and the replies were a parade of "missing edge cases," "feasibility nobody checked," "requirements that didn't make sense technically." Those aren't bad luck. They're the predictable output of a spec that never got a structured second look.

Why instinct fails in a specific way

You wrote the PRD, so you read it the way you wrote it. You fill the ambiguous parts with the same interpretation you had in your head, which means the gaps you missed while writing are invisible while reviewing. A fresh pair of eyes catches them — but "get someone to review it" doesn't scale, and the someone reads it the way they'd have written it.

The sanity check that actually works

Replace vibes with a pass that targets the four things engineering pushes back on:

• Edge cases and negative paths. For every happy-path requirement, what happens when the input is empty, the network fails, two users act at once, the date crosses midnight? If the spec only describes success, it's half a spec.
• Internal contradictions. Pricing says 3% in one place and 4% in another. The user can do X per the flow but can't per the permissions. These are cheap to catch on a read and expensive to catch in code review.
• Unstated dependencies. Which downstream system does this touch? What has to be true elsewhere for this to work? The dependency you didn't write down is the one that blows up integration.
• Traceability. Can every requirement trace back to a real reason — a transcript, a ticket, a decision? A requirement with no source is usually a fabrication, and fabrications are where pushback lives.

Make the gap check the artifact, not the afterthought

The reason "sanity check" stays informal is that it's treated as a final glance instead of a stage. Promote it. Run an explicit gap-analysis pass that compares the flow against what a complete flow needs, surfaces each missing edge and contradiction, and makes you resolve or consciously dismiss it before the spec proceeds. Now the answer to "how confident are you" isn't a feeling — it's a list of gaps you closed and gaps you knowingly deferred.

That's also the honest reframe of "engineering pushed back." Pushback isn't a failure of the PM; it's the gap check happening downstream, in the most expensive place possible. Move it upstream and it stops feeling like an ambush.