PRD Review

Read a PRD and produce a structured product-leader review. The output is a standalone note that can be linked from a meeting note.

Scope: product-prd-review = critique of a PRD. For a slide deck, a stakeholder email, or a roadmap, use a different review skill.

Input

A PRD reference as argument: a URL, a doc ID, a file path, or pasted text. If no argument: ask which PRD to review.

Workflow

1. Fetch the PRD

Retrieve the full content. Extract:

• Product/feature name
• Author
• Date
• The full PRD content

2. Structural analysis

Evaluate the PRD against this checklist. For each item, note: present/missing/incomplete.

Problem & context

• Problem clearly defined with evidence (not just "customers want X")
• Target user/persona identified (which buyer? which end-user?)
• Current state documented (how is this handled today?)
• Quantified impact of the problem (support tickets, churn, lost revenue, workarounds)

Commercial & coherence lens

• Buyer/user impact: will the target audience understand, adopt, and support this?
• Pricing/packaging model defined or referenced
• Go-to-market enablement: communication and training (support, sales)
• Catalog fit + impact on existing modules
• UX/design coherence with existing product patterns; new vs modified user flows
• Feature flag / rollout strategy defined?

Success criteria

• Measurable success metrics defined (not just "increase satisfaction")
• Baseline values provided for comparison
• Timeline for measurement

Technical

• Dependencies on other teams/services identified
• Data model implications noted
• Performance/scale considerations addressed
• Security implications assessed

Risks & edge cases

• Risks explicitly listed with mitigation
• Edge cases considered (multi-country, legacy accounts, migration)

2bis. Two-axis review (do not merge)

Review along two independent axes:

• Form / conformance = the structural checklist above (template respected, sections present, consistent with the team's product standards and PRD conventions).
• Substance = does the PRD solve the real product/business problem, for the right user, at the right time, regardless of how well it's written?

Report both verdicts separately. The verdict in step 6 weighs both but keeps the two reads visible.

3. Knowledge gaps

List what the PRD does NOT address but should. Frame as questions to ask in the meeting, not as criticisms. Categorize:

• Must answer before dev: blockers
• Should clarify: important but not blockers
• Nice to know: context that would strengthen the PRD

4. Contextual research (mini-intel)

Run targeted research to arm the review with data:

Internal data — if the PRD touches an existing module:

• Current usage volumes for the module
• Trend (growing, stable, declining)
• Any active alerts or SLO issues

Note: pulling product analytics may require API keys. If not available in the session, skip and note "Analytics data not available — run manually if needed."

Existing docs — search the team's wiki or knowledge base for:

• Previous PRDs on the same topic or module
• Architecture decisions, tech specs
• Past meeting notes mentioning this feature

Competitors — check how direct competitors handle this feature/need and whether it's table stakes or differentiation.

Web — if relevant:

• Industry benchmarks or standards for this type of feature
• Competitor public announcements

Notes — search your own notes for related context

5. Risk assessment

Identify the top risks, categorized:

• Commercial: will users adopt? Does it cannibalize existing revenue?
• Technical: complexity, dependencies, performance
• Coherence: does this fragment the product experience?
• Timing: is this the right moment? What else is competing for attention?
• Support: will this increase or decrease support load?

6. Verdict

Provide a clear assessment:

• Go: PRD is solid, proceed to dev
• Go with reserves: proceed but X must be addressed first
• Needs rework: fundamental gaps, send back to PM with specific asks
• No-go: wrong problem, wrong timing, or wrong approach — explain why

Always justify with specific references to the PRD content and the research.

7. Questions for the meeting

List 5-7 prioritized questions to ask in the PRD review meeting. For each:

• The question itself
• Why it matters (one line)
• Who should answer (PM, tech lead, support, commercial)

Output

Create a self-contained file with the following format:

Filename: YYYY-MM-DD - PRD Review - [Product Name].md

Structure:

# PRD Review — [Product Name]

Source: [PRD title](URL)
Author: [Name] | PRD date: [date]

## Verdict

[Go / Go with reserves / Needs rework / No-go]
[2-3 lines justification]

## Two-axis review

### Form / conformance: [solid / ok / weak]
[Does the PRD respect the template, format, product standards? 1-2 lines.]

### Substance: [solid / ok / weak]
[Does it solve the real product/business problem? Is it the right thing to build? 1-2 lines.]

## Structural analysis

[Checklist results grouped by category, with status and comments for each item]

## Knowledge gaps

### Blockers
- [question]

### To clarify
- [question]

### Nice to know
- [question]

## Context & data

### Internal data
- [Analytics / docs findings]

### Competition
- [How competitors handle this]

### Market
- [Web research findings if relevant]

## Risks

| Risk | Type | Severity | Proposed mitigation |
|------|------|----------|---------------------|
| ... | Commercial/Tech/Coherence/Timing/Support | High/Medium/Low | ... |

## Questions for the meeting

1. **[Question]**
   Stakes: [why it matters] — Ask: [who]

2. ...

Rules

• Be direct and critical. A useful review is honest, not diplomatic.
• Every criticism must be specific: quote the PRD, point to what's missing, explain why it matters.
• Never fabricate data. If you can't find competitive intel or usage data, say so.
• The verdict must be justified by the analysis, not by gut feeling.
• Keep the output dense. No filler, no AI slop.
• The review file must be self-contained and linkable from a meeting note.