What makes a PRD critique actually useful

Why most critique fails

Critique is easy to ask for and hard to do well. The Product Manager gets back a list of "considerations" — twenty bullets, each technically correct, none of them actionable.

A useful critique does three things. A useless one does one: it comments on what is already on the page. Polish on the prose, a nicer phrasing for goal #2, a note that the metrics section "could be stronger." All true. None of it changes what you ship.

The difference is not effort or model size. It is what the reviewer goes looking for.

Principle 1: Name the missing thing

The most expensive problems in a PRD are not the wrong sentences. They are the sentences that are not there.

A copy-edit reads what you wrote. A real critique reads what you should have written and did not — the success metric you never defined, the failure state you skipped, the assumption you made without saying so out loud. Those gaps are exactly what blows up in review, because they are invisible to you: you cannot proofread a section that does not exist.

So the first job of critique is gap detection, not polish. "This reads well" is worthless. "There is no acceptance criteria for the shared case, and that is the case engineering will ask about first" is the whole game.

Principle 2: Conflict, not compliment

Critique that only agrees with you is noise dressed as feedback. If every finding makes you feel good, the reviewer is performing thoroughness, not doing it.

Useful critique is willing to disagree. It says the problem statement and the proposed solution do not match. It says this metric will not move even if the feature works. It says this is a blocker, not a nice-to-have — and it is willing to be wrong about that in writing.

You do not need a cheerleader before a review. You need the one read that conflicts with your own, so the conflict happens at your desk on Tuesday instead of in the room on Friday. A critique that never tells you something you did not want to hear has told you nothing.

Principle 3: Specific over thorough

Thorough is the trap. Twenty findings of equal weight is not a critique — it is a homework assignment, and you will skim it.

A useful critique is ruthless about priority. It tells you the three things that will sink the spec before it tells you the eleven that would merely improve it. Every finding is specific enough to act on — it points at the line, names the problem, and proposes the rewrite — and severity is assigned the same way every time, not by the reviewer's mood that afternoon. You fix what matters first because the critique already sorted it for you.

Specific beats thorough because you can act on specific. Thorough you just acknowledge.

How Thinkr does it

These three principles are the spec for Thinkr's critique. It runs eleven distinct passes — from a context summary and completeness check, through engineering readiness, edge cases, and domain-gap analysis, to a final scored verdict — and each pass is built to name the missing thing, take a position, and prioritize.

The output is not a list of considerations. It is findings: classified as blocker, major, or minor, sorted by severity, each landed as a comment on the line it concerns, with a suggested rewrite you can accept inline. The goal is not a longer document. It is a sharper one — before your team opens it.

Want these principles as something to run against a draft? The standing version is the PRD review checklist, or apply them to your own spec before anyone else does with how to critique your own PRD.

---

Part of a series on building the critique surface in Thinkr. See it run on a real spec in How Thinkr critiques a PRD, or read where critique fits the wider workflow in the loop.