Nobody teaches PMs how to review a PRD

I have read a lot of Product Management curricula. Courses, bootcamps, internal onboarding, the reading lists people post when someone asks how to break into the job. They are close to unanimous on one thing: they teach you to write.

Write the problem statement. Write the user story. Write the success metric. Here is a template, here are twelve examples, here is a rubric for your own draft.

Almost none of them teach you to read a spec and break it.

That is strange, because reviewing is what you will actually spend your time doing. You write a handful of PRDs a quarter. You read other people's specs, other teams' one-pagers, other functions' requirements, and your own draft with fresh eyes, constantly. The skill with the higher usage count is the one nobody trains.

Writing gets taught because writing produces an artifact

I think the reason is mundane. Writing is teachable in the way institutions like: it ends in an object.

A student writes a PRD. There it is. You can grade it, compare it against a template, put it in a portfolio. The feedback loop closes inside the course.

Review produces nothing you can hold. A good review is a conversation and some deleted paragraphs. Its output is the bug that never got filed, the sprint that did not get rebuilt, the meeting that ended in a decision instead of a follow-up. You cannot show anyone the disaster you prevented. Nobody gets promoted for the launch that went fine because someone caught the missing permission state in week one.

So the curriculum optimizes for the visible half, and PMs learn the invisible half by absorption. Which mostly means you learn it by having it done to you, in someone else's comments, two sprints after it would have helped.

Review is not proofreading, and that is the part that gets missed

Here is what I think most PMs believe review is, without ever having examined the belief: review means reading carefully.

It does not. Reading carefully finds bad sentences. The expensive problems in a spec are not the bad sentences, they are the sentences that are not there.

You cannot proofread a gap. There is nothing on the page to catch your eye. The success metric you never defined does not sit there looking wrong, it sits there not existing, and careful reading walks straight past it, because careful reading is a technique for evaluating text that is present.

That is why "I read it twice and it looked good" and "I reviewed it" are different claims, and why the second one is a skill. A real review is adversarial. You are not evaluating the prose, you are trying to construct the argument that this spec fails, and then checking whether the doc can defeat you. The sections you go looking for are the ones the author had no reason to think about, which is precisely why they are missing.

Nobody arrives at that stance naturally. It has to be taught, or at minimum modelled, and it usually is not.

The incentives run the other way

Even PMs who know how to review often do not.

Reviewing well is socially expensive. A blocker filed on a colleague's spec is a small conflict, on the record, with your name on it. Twenty soft "considerations" cost nothing and look thorough. The reviewer who writes "the problem statement and the solution describe different problems" is right and slightly unwelcome. The reviewer who writes "nice work, maybe tighten the metrics section" is neither, and gets asked back.

So the equilibrium in most teams is polite, useless review. Everyone participates, nobody says the disqualifying thing, and the disqualifying thing surfaces in sprint planning where it costs ten times more. I have been on both sides of this and the polite version always felt better in the moment.

AI made this worse before it made it better

The last two years produced a wave of tools that write specs. They are good at it. Give one a rough problem and you get a structured PRD with every heading filled in.

Which quietly moved the bottleneck. When drafting was the hard part, a weak draft looked weak, and its weakness was itself a signal. Now every draft arrives complete, well-formatted, confident, with a populated non-functional requirements section that may or may not contain a real number.

Worse, most of these tools flatter. Ask one to check your work and it agrees with you in a structured format. It comments on what is on the page, suggests a crisper phrasing for goal two, notes that the metrics could be stronger. It has no incentive to tell you the spec should not ship, and a strong pull toward being agreeable, because agreeable is what the interaction was trained to feel like.

The result is that specs now look reviewed. Confidence went up and gap detection did not, and the untaught skill became more load-bearing exactly as it became easier to skip. This is the whole reason I built critique as the flagship of Thinkr rather than generation. Generation is table stakes. The read that is willing to disagree with you is the part nobody was doing.

How you actually learn it

Three things worked for me, none of them a course.

Run against a fixed list, not your memory. Memory answers "did we cover error states?" with "probably." A written list makes you point at the line. Any standing list beats no list; ours is the PRD review checklist.

Review your own drafts as a stranger, deliberately. Put a night between writing and reading, then go hunting for absences rather than errors. The method is in how to critique your own PRD, and the hardest part is not technique, it is staying skeptical about the section you skimmed because you wrote it.

Watch a rigorous review happen and steal the moves. This is the one that is hardest to get, because rigorous reviews mostly happen in private and the good ones never get published. So we published one: a real spec, taken apart finding by finding, in how Thinkr critiques a PRD. The principles underneath it are in what makes a PRD critique actually useful.

The uncomfortable version of all this: your PRD is going to get reviewed either way. The only variable is whether the first rigorous read happens at your desk on Tuesday or in the room on Friday. One of those is cheap.

---

Written while building the critique surface in Thinkr. For the peer-review side of the same problem, see how to review someone else's PRD and how to run a spec review meeting.