Catch Your PRD's Gaps Before Reviewers Do
Most PRDs go out after one read-through by the person who wrote them. That catches typos, but it rarely catches the gap that gets the same clarifying question asked in the comments of every doc you send, because you already know the answer and read right past where it's missing. A PM who's carried a feature's context in their head for two weeks reads a PRD about it completely differently than an engineer opening the doc cold for the first time.
Warning
A read-through by the author checks whether the doc makes sense to someone who already knows the feature. It doesn't check whether it makes sense to someone who doesn't, which is the actual reviewer.
The PRD that survives your own read-through is the one you're least qualified to judge.
Why the same question keeps showing up in review
You wrote the doc with the full context already in your head, so a gap in the requirements doesn't read as a gap to you, it reads as obvious. The reviewer doesn't have that context, so the same kind of question, an unhandled edge case, an unstated assumption, resurfaces doc after doc. If three of your last five PRDs got the same comment asking how the feature should behave for a specific user type, that's not bad luck, it's a pattern in how you write scope.
Take a PRD for a bulk-export feature that specifies exactly what happens for a standard user exporting up to 10,000 rows. It doesn't say what happens at 100,000 rows, or for a user on a free-tier plan with export limits, because the author was thinking about the common case the whole time it was being written. An engineer picking up the doc has no way to infer those answers, and the resulting comment thread, "what happens above the row limit?", is the same question that would have come up on the last three PRDs too, if anyone had thought to check.
Before: write the PRD, read it once, decide it's clear, send it for review.
After: hand it to Claude with the feature's actual context, ask specifically whether the scope is clear and what edge cases are missing, and fix what it finds before a reviewer has to ask.
A process for testing a PRD before review
- 1
Give Claude the actual draft and the real context
Paste the problem statement and requirements as written, not a summary, along with who this feature is for. A PRD for an internal admin tool needs different edge-case coverage than one for a public-facing feature, and the same missing edge case matters more or less depending on who's affected.
- 2
Ask specifically whether the scope is clear
A vague "does this make sense" gets a vague answer. Ask directly whether someone with no prior context could tell what's in scope and what isn't from the doc alone, which is the actual test an engineer picking up the doc cold will face.
- 3
Ask for missing edge cases, not a general critique
Request the specific edge cases the requirements don't address, not open-ended feedback. A missing edge case is concrete and fixable; "this could be clearer" isn't.
- 4
Fix the gaps before anyone else sees the doc
Update the requirements section directly from what Claude flagged. The version a reviewer sees should already reflect the questions you'd otherwise get asked in the comments, so review time goes toward real disagreements instead of basic clarifications.
Here's the problem statement and requirements section of my PRD for a bulk-export feature. Tell me honestly if the scope is clear, and flag any edge case I haven't addressed.
”For a feature with a specific technical constraint you already know about, a rate limit, a data size cap, a permissions boundary, it's worth telling Claude that constraint directly so the edge-case check is grounded in the real system rather than generic guesses.
Our export system has a hard 500,000-row limit at the infrastructure level, which isn't mentioned anywhere in this PRD. Given that constraint, what edge cases around row limits should the requirements explicitly address?
”
Inside Claude Tutorial
Testing a document against a reader who lacks your context is transferable.
Checking whether something makes sense to someone without your background, instead of trusting your own read-through, applies well beyond PRDs. The app has a full lesson on it, with practice that applies to any document you write for someone else to act on.
When the gaps keep coming from the same section
If edge cases keep surfacing in the same part of your PRDs, that's worth noticing as a pattern, not refixing from scratch each time. A recurring gap in, say, the permissions section usually means that section needs a standing checklist, not another one-off review. Fixing the same category of gap three separate times is a sign the underlying habit needs to change, not just the current document.
Tip
Ask Claude to compare this PRD's gaps against gaps from your last few docs, if you have them. A pattern across multiple PRDs is a stronger signal than one doc's edge cases, and it tells you where to build a reusable checklist.
This is the third PRD in a row where reviewers asked about permissions handling. Here's this draft's permissions section. What's missing, and what would a standing checklist for this section need to cover going forward?
”Once a checklist like that exists, it's worth running every new PRD's relevant section against it before the first review, rather than relying on memory to catch the same recurring gap every time.
Here's the permissions checklist we built last time, and here's a new PRD's permissions section. Check it against the checklist and flag anything the checklist covers that this draft is still missing.
”Continue reading
- Writing a PRD From a One-Line Feature Request: getting the structure right from the start, before the review-and-fix pass this article covers.
- Turning Support Tickets Into Prioritized Themes: where the edge cases a PRD needs to cover often come from in the first place.
- Getting Started with Claude: the underlying habits, context, iteration, specificity, this entire process is built on.