How to review someone else's PRD

Reviewing your own draft and reviewing someone else's are different jobs. Self-review fights your blind spots. Peer review fights your missing context. You were not in the customer calls, you did not see the constraint engineering dropped in Slack on Tuesday, and you cannot always tell a real gap from a decision nobody told you about.

Get that distinction wrong and your review lands in one of two failure modes. Too soft, so you hedge everything and the author learns nothing. Or confidently wrong, so you file a blocker against a decision that already has a good answer and burn your credibility for the next spec.

Here is the version I run. Five moves, in order.

Read it twice, in this order

First pass: no comments. None. Read start to finish and answer one question. What is this person claiming, and does the claim hold?

The temptation is to start annotating at paragraph three, while your attention is still fresh. Resist it. Comment on the first pass and you anchor on whatever section you happened to read first, then spend the rest of your budget on that section. The author gets a review of page one and silence on page four.

Second pass is the working pass. Now you hunt for what is absent, and you comment.

Reading twice sounds expensive. It is cheaper than the alternative, because the first read is what tells you which parts of the second read matter. A spec whose problem statement does not survive the first pass does not need line-level notes on its acceptance criteria.

Sort every finding into three buckets

Not two. Three.

Missing. There is nothing on the page. No success metric, no error state, no owner for the dependency.

Unclear. Something is on the page and it can be read two ways. This bucket is where peer review earns its keep, because ambiguity is invisible to the author. They read their own sentence and see the one meaning they intended. You read it cold and see both.

Disagreed. It is clear, you understood it, and you think it is wrong.

The bucket to be careful with is missing, because a good half of what looks missing to an outsider is a decision made in a room you were not in. So phrase it as a question the first time you raise it. "Is there a reason the shared-workspace case is out of scope, or was it not considered?"

That sentence costs you nothing and buys you a lot. If the answer is "not considered", it is now a confirmed gap and you were right to look. If the answer is "we cut it in the sync with legal", you have still found something: the doc does not record the decision, so the next reader will ask the same question. That is a real finding too, just a smaller one. Log it as minor and move on.

Rank before you comment, not after

A review that ends in twenty-two findings of equal weight is not a review. It is a homework assignment, and the author will do the easy nine.

So rank first, using severity levels the team has actually agreed on:

• Blocker. Engineering cannot start, or the launch will be wrong. The spec is not ready.
• Major. It will cost a rework cycle. Fix before the next stage, not necessarily today.
• Minor. The doc gets better. Nothing breaks if it ships as is.

Then write your comments in that order and put the ranking in the summary. The point of severity is not politeness, it is a shared unit of urgency. Without it, "have we thought about rate limiting" and "the problem statement and the solution describe different problems" arrive at the author looking identical, and they will spend their afternoon on the wrong one.

Assign severity the same way every time. If your blockers on Friday would have been majors on Monday, you are grading your mood, not the spec. This is most of the argument in what makes a PRD critique actually useful, applied to somebody else's document.

Say the thing, and be willing to be wrong in writing

Softened feedback is not kind. It is ambiguous, and ambiguity is what wastes the author's time.

"It might be worth considering whether the metrics section could be a little tighter" gives the author nothing to act on. They will read it, agree in principle, change a word, and move on. The gap survives.

Compare: "The activation metric has no baseline, so we cannot tell success from noise. Suggest: lift activation from 22% to 30% for new workspaces within one quarter."

That is the shape. Name the problem, point at the line, propose the rewrite. Same standard you would apply to your own draft in how to critique your own PRD, except now you have to hold it while being polite to a colleague.

Those two things are not in tension, and this is the part that takes most PMs a few years to believe. Respect is not softening the finding. Respect is assuming the person can hear it. Treating a peer as too fragile for a direct "this metric cannot fail, so it is not measuring anything" is the more condescending option, and they usually know.

Where you should hedge is confidence, not severity. "I might be missing context here, but I cannot find where the partial-permission case is handled, and I think it blocks engineering" is honest about your position and still files the blocker. Being wrong in writing occasionally is the cost of being useful in writing consistently.

Comment on the line, argue in the room

Async review carries specifics beautifully and disagreement badly.

A comment thread is the right place for "this criterion is not testable, here is a Given-When-Then version." It is the wrong place for a two-person debate about whether the feature should exist. If a finding has been through two rounds of replies and is not converging, stop typing. It is a conversation now.

Take it live, timebox it to ten minutes, and write the outcome back into the doc. The thread is not the record. The doc is the record.

End with a verdict, not a list

Close every review with two things: a call and a first fix.

The call is one of three words. Ship, it is ready. Revise, the shape is right and specific gaps need closing. Rethink, the problem or the approach does not hold and more comments will not help.

The first fix is the single item you would close before any other. Not a ranked list of nine. One.

The verdict is the deliverable. Everything before it was evidence gathering. A review that stops at observations hands the author your reading notes and makes them do the judgment you were invited to provide.

If you want the standing version of what to look for on the second pass, that is the PRD review checklist, and the recurring offenders are collected in common PRD mistakes.

Where the machine helps, and where it does not

The mechanical half of peer review is genuinely automatable. Completeness, testability of acceptance criteria, non-functional coverage, internal contradictions between the problem and the solution: those are rubric checks, and a rubric does them the same way at 6pm as at 9am. That is the pass Thinkr's Critique runs, eleven of them, with severity assigned identically every time and suggested rewrites landed as comments on the line.

Run it first, on your colleague's draft or your own. Then spend your human attention on the two things it cannot do: knowing what was decided in the room you were both in, and telling the author the uncomfortable thing they need to hear from a person rather than a score.

FAQ

How long should a PRD review take?

Budget 30 to 45 minutes for a normal feature spec, split across two passes: one uninterrupted read for the argument, one slower read for gaps. If you cannot finish, review part of the doc properly rather than all of it superficially, and say which sections you did not cover.

Should I leave inline comments or write a summary?

Both, because they do different jobs. Inline comments carry the specifics so the author can act line by line. A short summary at the top carries the verdict and the ranked list, since forty inline comments have no priority and will get skimmed.

What if I think the whole approach is wrong?

Say it once, at the top, as a single blocker with your reasoning, then stop commenting on details. Fifty line-level notes on a spec you believe should not ship is wasted work for both of you. Take that disagreement to a conversation instead of burying it in the margins.

Is it my job to fix the PRD?

No. Your job is to name what is missing or wrong and propose a direction. If you rewrite it, you have taken ownership of a spec you will not be accountable for, and the author loses the reps that make them better at this.

---

Part of a series on the review side of Product craft. See a full critique run on a real spec in How Thinkr critiques a PRD, or read why this skill goes untaught in nobody teaches PMs how to review a PRD.