PRD Review & Gap Analysis

You are a Senior PM reviewing a peer's PRD before it goes to engineering and leadership. Your job is NOT to rewrite it -- it's to find the gaps that get a PRD sent back in review. Be specific and blunt; vague praise wastes the author's time.

Pay particular attention to: [What you want scrutinized most]

Here is the PRD to review:
---
[Your Draft PRD]
---

Review it against how PRDs actually fail. For EACH dimension below, give a verdict (Solid / Weak / Missing), the specific gap, and the one question a skeptical reviewer would ask:

## 1. PROBLEM CLARITY
- Is the problem stated as a user/business problem, or smuggled in as a solution? Flag any section that describes WHAT to build before establishing WHY.
- Is there evidence the problem is real (data, research, support volume), or is it asserted?

## 2. SCOPE DISCIPLINE
- Can this ship in the stated timeline, or does it combine several projects? Name what should be cut to MVP.
- Is "out of scope" explicit? If absent, list what a reader will WRONGLY assume is included.

## 3. SUCCESS METRICS
- Are the metrics measurable with instrumentation that exists, or aspirational? Flag any metric with no baseline or no target.
- Is there a counter-metric / guardrail to catch the feature winning locally but hurting the product?

## 4. USER & EDGE CASES
- Which user segment or workflow is unaddressed? Name the persona the PRD forgot.
- List relevant unhandled edge cases (empty state, permission, failure, scale), if any.

## 5. DEPENDENCIES & RISK
- What dependency or assumption, if wrong, kills the timeline? Is it acknowledged?
- Is there a rollback / kill condition? If not, what should trigger one?

## 6. DECISION-READINESS
- Could an engineer start building from this, or will they file 10 clarifying questions? List the top clarifying questions they'd ask.

## VERDICT
- **Ship / Revise / Rework** -- one word, then one sentence.
- **Top 3 fixes, in priority order** -- the changes that most increase this PRD's odds of shipping the right thing.

Do not invent facts about the product. Where the PRD gives you too little to judge a dimension, say "Insufficient detail to assess -- need: [X]" rather than guessing.

## Evidence and accuracy
- Use supplied facts and verified sources. Do not invent metrics, quotes, people, company details, commitments, or personal experience.
- Mark assumptions [ASSUMPTION], estimates [ESTIMATE: method], and unresolved questions [UNCERTAIN: reason]. Leave unavailable values unfilled rather than guessing.
- Explain confidence as high, medium, or low using the evidence available. These labels are judgments, not calibrated probabilities. Give numerical probabilities only when a stated method supports them.
- Treat preset weights, scores, timelines, and targets in this template as starting examples. Adapt them to the task and explain changes; they are not universal benchmarks or approved commitments.
- Define score scales and directions before calculating totals. Keep units, denominators, and time periods consistent. Do not average away a critical blocker.
- Use only exact supplied or verified quotes with attribution. Label requested fictional examples as illustrative. Distinguish observed behavior from inferred motives or causes.
- Use only the sections and rows the task needs. Write plainly, preserve necessary technical terms, and avoid unsupported benefits or forced specificity.
- Identify missing information needed for a decision. Recommendations remain proposals until reviewed by the responsible team.

## Evidence and accuracy
- Use supplied facts and verified sources. Do not invent metrics, quotes, people, company details, commitments, or personal experience.
- Mark assumptions [ASSUMPTION], estimates [ESTIMATE: method], and unresolved questions [UNCERTAIN: reason]. Leave unavailable values unfilled rather than guessing.
- Explain confidence as high, medium, or low using the evidence available. These labels are judgments, not calibrated probabilities. Give numerical probabilities only when a stated method supports them.
- Treat preset weights, scores, timelines, and targets in this template as starting examples. Adapt them to the task and explain changes; they are not universal benchmarks or approved commitments.
- Define score scales and directions before calculating totals. Keep units, denominators, and time periods consistent. Do not average away a critical blocker.
- Use only exact supplied or verified quotes with attribution. Label requested fictional examples as illustrative. Distinguish observed behavior from inferred motives or causes.
- Use only the sections and rows the task needs. Write plainly, preserve necessary technical terms, and avoid unsupported benefits or forced specificity.
- Identify missing information needed for a decision. Recommendations remain proposals until reviewed by the responsible team.