Notes on Product Management craft.

A generated PRD fails differently from a human one. Five checks to run first: invented baselines, fake evidence, generic personas, symmetric scope, exclusions.

When the same input can give different outputs, Given-When-Then is not enough. How to write evals as acceptance criteria: a fixed set, a threshold, an owner.

Most AI feature specs define success and error. The states in between (low confidence, abstention, refusal, escalation) decide how the feature fails.

A leadership deck is not a shorter PRD. What to pull from the spec (the ask, the cost, the risk, the decision), what to leave behind, and where it fails.

A coding agent reads early, commits early, does not ask and does not check its work against your spec. Six changes to how you write the requirements.

For many teams a general assistant with good context drafts a usable PRD. The specific point where a dedicated PRD tool earns its price, and where it does not.

Judge a PRD generator by what it does when it lacks information: ask, mark the gap, or invent. A seven-check test you can run on any tool, ours included.

A synthesis of thirty posts in thirty days. Every spec failure we covered was one of six patterns — and two are about order, not content.

An AI reviewer checks the document against itself. Checking it against the world stays human — and that gap is structural, not a capability we are waiting on.

The tool is not the bottleneck, but it is not neutral either. What a spec needs from its home, and the specific failure each tool makes easy.

They answer different questions and most work needs both, in order. The test is whether the thing in front of you could still be rejected.

The objection is fair — specs can be waterfall. But what makes a document waterfall is the ceremony around it, not the fact that somebody wrote it down.

Five situations where writing a spec delays the real question. The tell is what you are trying to get — approval, a decision, and a correct build differ.

A vanity metric is not a fake number. It is a real one that can only go up — which is why it passes review and settles nothing afterwards.

"Increase activation to 40%" — from what? The most common defect in a PRD metric, why it happens, and the three honest ways to handle a number you do not have.

Most metrics in a PRD cannot fail, which means they are not metrics. Three tests — measurable, attributable, baselined — and the counting rules nobody writes.

Five sections are irreducible, six are conditional, and six are usually inherited from a template rather than chosen. Each with the failure it prevents.

One to two pages for a small feature, three to six with real scope, six to twelve for a migration, plus a one-question test for what to cut and where it goes.

The PM owns it, which is not the same as writing all of it. Who writes which section, the four to never delegate, and co-writing without contradictions.

Why AI writes fluent, generic specs. Context is four things with very different retrievability — and retrieval cannot find what was never written down.

Six fields that earn their place, five that do not, and the reader you are actually writing for — someone in eight months with the opposite instinct.

A decision that comes back was not badly made — it was badly stored. What a round of relitigation costs, and why the second round is worse than the first.

Teams that write everything down still lose decisions. Specs record what was decided, never why or what was rejected — and retrieval is the harder half.

If the spec needed a meeting to be understood, the meeting was patching it — and the patch is not written down anywhere. What handoff is actually for.

When the consumer is another service, the what/how line does not move — the user does. One test for which side any line belongs on.

Engineers do not read a spec top to bottom. What they skip, what they re-read, and the five things they wish were in there and usually are not.

Six ambiguities that make an estimate impossible, the question each produces, and why a wide range measures the document rather than the engineer.

Fidelity is three independent dials, not one. Which to raise depends on the decision you need — and too much fidelity costs more than too little.

Some requirements have a picture and some do not — and the invisible half is where incidents come from. A rule for allocating between prototype and spec.

The three kinds of AI prototype generator, what to evaluate before picking one, and the four limits that decide whether the output is useful or just fast.

Seven practices that hold up under a deadline, plus five that sound right and never survive — each with the specific failure it prevents or causes.

One feature, two specs. The weak one is not badly written — it is well written and empty, which is exactly why it passes review.

PRD testing starts in the spec: where the PRD ends and the test plan begins, the four things a spec must supply, and how to rewrite untestable requirements.

Five classes of dependency that go unwritten in PRDs — team, technical, data, legal, vendor — and the one question that surfaces each of them.

Most PRDs write what is in scope and stop. The exclusion list is what prevents the scope fight that arrives after approval, when your leverage is gone.

Error states are the most-skipped requirement class in a PRD. The seven failure modes worth specifying, and the five things to write for each one.

Five lenses for finding the edge cases a spec leaves out — boundary, sequence, permission, concurrency, absence — and what to write once you find one.

How to go from a written PRD to a clickable prototype, what an AI prototype generator can and cannot infer from your spec, and the gaps the exercise exposes.

A plain comparison of the PRD, MRD, BRD, SRD and RFC — what each one answers, who writes it, when it earns its keep, and when it is ceremony.

How to review another PM's spec when you lack their context: separate real gaps from decisions nobody told you about, rank findings by severity, and disagree in writing without stalling the draft.

How to run a PRD or spec review meeting that produces decisions: the silent-read open, a fixed four-block agenda, who owns which role, and what to write down before anyone leaves.

Every Product course teaches you to write the spec. None teach you to read one and break it. That gap explains most of what goes wrong in review, and most of what AI writing tools quietly make worse.

A complete example PRD for a real feature, then the exact gaps an 11-pass critique flags in it, with the fix for each. See what review actually catches.

A copyable PRD template with the review check baked into every section, so the gaps a critique would flag are harder to leave in. Copy it and start writing.

What is a PRD (product requirements document)? The plain definition, what goes in one, who writes it, and the review step most definitions leave out.

An AI PRD writer drafts a spec from a prompt. An AI PRD reviewer reads the spec you have and finds where it breaks. Why you need both, not one.

A fair, dated comparison of AI PRD review tools (Thinkr, ChatPRD, PMPrompt, Centercode) on the one thing that matters: how much of its rubric it publishes.

Can AI review a PRD? Yes, and it is a different job than writing one. What it catches reliably, what it cannot, and whether it is safe to paste your spec.

The seven PRD mistakes that get specs sent back (solution-first framing, unfalsifiable metrics, missing edge cases) and how to catch each before review.

A six-step way to review your own PRD like a skeptic, find the missing sections, pressure-test the metrics, and catch the gaps before your team does.

A non-functional requirements checklist for PMs, built on the ISO/IEC 25010 quality model. Eight attributes, the question to answer, and a measurable NFR example each.

Each 1-5 PRD evaluator grade, defined: how blocker, major and minor findings set the number, why one blocker caps it at 3, and why a 4 ships after edits.

The 11 checks a senior PM runs on a PRD, and how to run them with AI: what an AI review catches reliably, what it misses, and the standard behind each check.

Turn vague acceptance criteria into runnable Gherkin Given-When-Then a tester can verify, plus measurable non-functional criteria like p95 latency under 500ms.

A good PRD is one your team can act on without you in the room. The qualities that define the bar (framed problem, falsifiable metrics, testable criteria) and how to measure against it.

Most Product tooling covers one slice of the workflow. Thinkr covers the chain. That is the actual unlock.

Three principles that separate critique that ships better PRDs from critique that wastes the reviewer’s time.

A constructed B2B spec run through Thinkr's 11-pass critique: each finding with its severity and suggested rewrite, the 2/5 verdict, and what it missed.