How to critique your own PRD before anyone else does

To review your own PRD, read it the way a skeptic would. Put a night between writing and reading. Hunt for the sections that should exist and don't. Pressure-test every success metric until it could fail in public, walk the unhappy path of each flow, and end with a ranked verdict — ship, revise, or rethink. The goal isn't a longer doc. It's a doc that survives the meeting.

The hard part is that you wrote it. You can't proofread a gap you didn't notice the first time, and you're reading with the same blind spots that put the gap there. So self-review isn't re-reading. It's switching roles — from the person who made the case to the person whose job is to break it.

And here's the part nobody tells you: we're taught to write PRDs, never to review them. Every PM course and every PRD template is about getting the spec onto the page. Reading a draft to break it, not bless it, is a separate skill, and most PMs only ever see it done to them, in someone else's comments, a sprint too late to help. The first real review your PRD gets shouldn't be your reviewer's. It should be yours.

Here's the six-step version I run.

Step 1: Put a night between writing and reviewing

Finish the draft, then close it. Come back in the morning, or at minimum after lunch and a different task. The distance is the whole point: you're trying to read your own words as if someone else wrote them, and that only works once the sentences stop sounding like the ones in your head.

What goes wrong: reviewing while you're still proud of it. Fresh off writing, every section feels covered because you remember intending to cover it. Intention doesn't ship. The reader gets the page, not the plan in your head.

Step 2: Read for the missing thing, not the wrong sentence

This is the move that separates a review from a proofread. Don't fix phrasing. Go looking for the section that should be there and isn't: the success metric you never defined, the error state you skipped, the dependency you assumed someone else owned. Those are the expensive ones, and they're invisible precisely because there's nothing on the page to catch your eye.

A trick that helps: read the doc against a fixed list instead of your memory. Run it past a PRD review checklist so the absences have something to fail against. "Is there an acceptance criterion for the shared case?" is a question your memory will answer "probably." A checklist makes you point at the line.

What goes wrong: commenting on what's there because it's there to comment on. Nicer wording for goal two, a note that the metrics "could be stronger." All true, none of it changes what you build.

Step 3: Make every metric able to fail

Take each success metric and ask one question: could this be wrong in public? "Increase engagement" can't — it names a direction and hides the cohort, the number, and the deadline. Rewrite it until someone could check it and catch you out. Lift activation from 22% to 30% for new workspaces within one quarter is a metric. It has a baseline, a target, and a clock.

Do the same to the problem statement. Read it, then read the proposed solution, and check that they're actually about the same thing. Half the PRDs I've reviewed solve a slightly different problem than the one they open with, and nobody notices because both halves are individually reasonable.

What goes wrong: metrics that only describe a hope. If the number can't fail, it isn't measuring anything — it's there to make the section look finished.

Step 4: Walk the unhappy path

The happy path wrote itself, and it's the path nobody files a bug against. The damage lives in the branches. For each user flow, walk the empty state, the error, the expired session, the partial permission, the offline case. Write each one as a condition a tester could run, not as prose:

Given a user whose invite was revoked When they open the shared link Then they see a request-access screen, not a 404.

That's the Given-When-Then form, and it leaves nothing to interpret. Write the unhappy paths this way and you've drafted the test plan as a side effect.

What goes wrong: "handle errors gracefully." That sentence feels like coverage and specifies nothing. An engineer will read it, shrug, and pick whatever's easiest to build.

Step 5: Write the non-functional half

Most drafts cover what the feature does and go quiet on how well it has to do it. That silence is where estimates blow up. Borrow the engineer's vocabulary (performance, reliability, security, compatibility) from ISO/IEC 25010, the quality model they already think in. You don't have to cite it. You have to answer it. "Fast" isn't a requirement; p95 under 500ms at 1,000 concurrent users is.

What goes wrong: leaving the non-functional requirements for "later." Later is the sprint planning meeting where an engineer asks how many concurrent users this has to hold, and the room turns to you, and you don't have a number.

Step 6: Rank the findings and call it

A review that ends in twenty equal findings isn't a review. It's a list you'll skim. Sort what you found by severity (blocker, major, minor) and assign it the same way every time, not by how the draft made you feel. Then make a call: ship, revise, or rethink, plus the one gap to fix first. The decision is the deliverable. Everything before it was just gathering evidence.

What goes wrong: stopping at the list. Twenty observations with no priority and no verdict is homework, and you'll do the easy three and miss the one that actually blocks the launch. (For the longer argument on why this ordering matters, it's in the principles behind a rigorous critique.)

When to hand it to a machine

You can run all six steps by hand. It takes real attention, and the honest difficulty is staying skeptical about the sections you skimmed because you're the one who wrote them. The discipline is the work, and discipline is exactly what's hard to keep at 6pm on the day the doc is due.

That's the pass Thinkr's Critique automates: it runs the same review (eleven passes, severity-classified findings, suggested rewrites landed as comments on the line) so the skeptic shows up even when you've run out of distance from your own draft. Use it as the first read, then spend your human attention on the one judgment a rubric can't make: whether the thing is worth building at all. And if you're still drafting, the checks start upstream, in how the spec gets generated.