“Your PRD gets taken apart in the review over three objections you could have found yourself the night before.”

The struggle

You spent four hours on the PRD. In the review someone asks what happens to existing customers on the old plan, someone else asks why not the cheaper option, and your VP asks what you’d cut if you had half the time. All three are fair. All three were findable the night before. You go away and rewrite it, and the two weeks you lost weren’t spent on the hard part — they were spent discovering that you’d never written down the argument, only the plan.

The obvious fix is “get feedback earlier,” and it mostly fails in practice: the people whose objections matter are the ones with no time to pre-read, which is exactly why they raise the objection live. What actually works is running the review against yourself first, in the specific voices of the people who’ll be in the room.

The second thing that fixes it is sequencing. Everyone writes the PRD and then summarises it. Do it the other way. A one-page summary is the only artefact short enough that a missing argument has nowhere to hide — if you can’t write it, you don’t have a position yet, and no amount of PRD structure will conceal that from a good reviewer.

The chain

Step 1 — Write the exec summary first · Claude

Before the PRD. Give Claude your rough idea and make it interrogate the argument rather than dress it up:

I'm about to write a PRD. First, help me write the one-page exec summary that
would go in front of leadership — because if I can't write it, I don't have a
position yet.

My rough idea: <2–3 paragraphs, however messy>

Produce:
1. The problem, in one sentence, from the CUSTOMER's point of view.
2. Why now — what changed that makes this the right quarter.
3. The proposal in three sentences.
4. What we are explicitly NOT doing.
5. The single number that would tell us this worked.

Hard rules:
- Where I haven't given you enough to write a section honestly, write
  "INSUFFICIENT — I need to know: <the specific question>" instead of filling it.
  Do not smooth over a gap.
- Do not invent metrics, market sizes, or customer counts. If a number would
  strengthen this, name the number I should go and find.
- If my "why now" is weak, say so directly.

The INSUFFICIENT lines are the deliverable. That’s the review happening early, on your own time, where it’s cheap. Go and answer them before writing a word of the PRD.

Our standalone version of this is write the exec summary before the slides.

Step 2 — Draft the structure · ChatPRD

Now the PRD itself. ChatPRD is template-driven and cheap, and it’s good at the parts that are genuinely boring — sections, edge cases, the shape of a spec. Feed it the exec summary you just fought for, not the original rough idea, and the draft comes out arguing for something instead of describing something.

When to skip this step: if your company has a PRD template you must use, drafting in Claude with the template in project knowledge is a shorter path than fitting a tool’s structure to your own. The prompt-library version is PRD first draft from a rough idea.

Step 3 — Red-team it with the actual room · Claude

The step people skip, and the one that changes the outcome. Not “review my PRD” — that produces polite generalities. Name the skeptics:

Below is my PRD. Attack it.

The reviewers will be:
- <name/role>, who always asks about <their known concern>
- <name/role>, who owns <the thing this affects> and will resist because <why>
- <name/role>, who will ask what we'd cut to ship this in half the time

For EACH reviewer, give me:
1. The three hardest questions they will actually ask, in their voice.
2. For each: whether my PRD currently answers it. Quote the line that does, or
   say "NOT ANSWERED".
3. The one question in this set I am least prepared for.

Then, separately: what is the strongest argument for NOT doing this at all?
Make that argument properly — steelman it, don't strawman it so I feel better.

Hard rules: do not suggest improvements to wording. I want objections, not edits.
Quote my PRD verbatim when you say something is answered.

PRD:
"""
<paste the full PRD>
"""

“Quote the line that does” is the guardrail that makes this trustworthy — it converts “looks well covered” into a citation you can check. And the steelman at the end is the highest-value paragraph: if you can’t answer it, you have a genuine product question, not a document problem. Our standalone version: red-team your PRD.

Step 4 — Repair, don’t rewrite (25 minutes)

For each NOT ANSWERED, do one of exactly two things: answer it in the PRD, or add it to an explicit Open questions section with who will answer it and by when.

Resist the urge to make the document longer to look thorough. An open question you named yourself is a strength in a review; the same question found by your VP is a weakness. That asymmetry is the whole game.

Step 5 — Acceptance criteria that engineering can build from · PRDKit

The last mile is turning agreed scope into criteria specific enough to argue about before the sprint rather than during it. PRDKit goes from spec to user flows and wireframes, which is useful when the ambiguity is about the shape of the thing rather than its logic. If it’s the logic, our acceptance criteria from a user story prompt is faster and tool-agnostic.

Where it breaks

• Red-teaming with generic reviewers. “Act as a critical stakeholder” produces polite, useless output. The specificity — real names, real known objections — is what makes this work. If you can’t name three skeptics, ask why you’re holding a review.
• Accepting the summary instead of arguing with it. The exec summary is supposed to be uncomfortable. If the first draft feels fine, you probably gave it enough material to paper over the gap you actually have.
• Adding length to look thorough. A red-team that produces twelve new paragraphs has usually made the PRD worse. Most NOT ANSWERED items belong in Open questions, not in new prose.
• Believing the quotes without checking. Ask for verbatim quotes and then actually check two of them against your document. Models paraphrase persuasively, and a claim that your PRD “already addresses” something it doesn’t is the one failure mode here that costs you in the room.
• Outsourcing the position. These tools sharpen an argument you have. They cannot supply one. A PRD that’s structurally perfect and says nothing gets rejected more slowly, not less.