Prd Critic

PRD Critic

Purpose

Most PRDs ship with the same five flaws: vague metrics, hidden assumptions, undefined scope, missing tradeoffs, and a solution that doesn't quite fit the problem. The author can't see them because they wrote them.

This skill puts the PRD through three hostile reviewers, each with a different angle, then consolidates a punch list of fixes.

Use this before sharing the PRD with your real eng lead, designer, or exec sponsor. It is cheaper to fix issues here than after political fallout.

When to use

• You just drafted a PRD and are about to circulate it
• A teammate sent you a PRD and you want a second-opinion review
• Your exec keeps sending PRDs back and you want to pre-empt the same comments
• You're about to put a PRD into product review or sprint planning

When NOT to use

• For documents that aren't PRDs (use proofread or general review instead)
• For PRDs at the discovery stage where structure is intentionally loose
• For ticket-level specs - the overhead isn't worth it

Inputs

Required:

• PRD content (paste, markdown file, or path)

Optional:

• Specific angle to emphasize ("the eng lead is concerned about scope", "exec is skeptical about ROI")
• Target reviewer audience (helps tune severity)

Process

Phase 1: Three reviewers

Set up three reviewer personas explicitly. They argue in their own voice:

The Skeptical PM (Director-level, 10+ years)

• Pokes at strategic fit, prioritization, opportunity cost
• Standard moves: "why this instead of X?", "what does this displace?", "what's the second-order effect?"

The Senior Engineer (Staff+ engineer who has shipped at scale)

• Pokes at scope, complexity, technical assumptions, hidden integration cost
• Standard moves: "this is two features stapled together", "you're hiding a migration here", "what happens when X fails?"

The Target Customer (the actual user, in their voice)

• Pokes at value, workflow fit, why they would actually switch
• Standard moves: "I already have a way to do this", "this solves the wrong half of the problem", "I'd never pay for this without X"

Each reviewer reads the PRD and lists their top 3-5 concerns in their voice.

Phase 2: Consolidation

Merge the three lists into a single ranked punch list:

• Severity (Critical / Major / Minor)
• Source (which reviewer raised it; if multiple, that's a signal)
• What the issue is (in plain language)
• Why it matters (the consequence if not fixed)
• What to do (concrete suggested edit)

Phase 3: The five killer checks

Always run these five checks against the PRD even if no reviewer raised them:

1. Vague metrics: are success metrics directionally measurable with numbers?
2. Empty Out-of-scope: does the PRD say what is explicitly NOT being built?
3. Hidden assumptions: are key assumptions named or buried as fact?
4. Missing tradeoffs: does the PRD claim pure upside?
5. Solution-problem fit: would the solution actually solve the stated problem if shipped exactly as written?

If any check fails, add it to the punch list as Critical.

Phase 4: Suggested rewrite (optional)

For the top 3 Critical issues, draft replacement language the author can paste in. Not a full rewrite - surgical edits.

Output

# PRD Critique: [PRD title]

## TL;DR verdict (Ship / Revise / Rethink)

## Reviewer reactions
### Skeptical PM
### Senior Engineer
### Target Customer

## Killer checks (5/5)

## Punch list (ranked)
| # | Severity | Issue | Why it matters | Suggested fix |

## Suggested rewrites (top 3 Critical)

## What the PRD does well (do not cut these)

The final "does well" section is mandatory. A critique that only finds flaws gets dismissed. Naming what's already strong builds trust and prevents over-rewriting.

Common failure modes to avoid

• Surface-only feedback: "improve clarity", "add metrics" - useless. Be specific or be quiet.
• Reviewer drift: each persona must stay in voice. The engineer doesn't care about brand consistency, the customer doesn't care about technical debt.
• All-Critical inflation: if everything is Critical, nothing is. Use the severity scale honestly.
• Skipping the "does well" section: this is where you signal you actually read the doc

Pair with

Best used in tandem with prd-builder. Build → critique → revise → share. The whole loop runs in under an hour.