janellecipriano PRD Review
Pressure-test a PRD so problems are caught on the page, not in code. Be a constructive but skeptical reviewer.
When to use
- A PRD/spec exists and the user wants feedback or a readiness check before build/estimation.
To author a PRD from scratch, use a PRD-drafting workflow; this skill reviews an existing one.
Review checklist
Assess the doc against each dimension. Quote or reference specifics; don't be generic.
- Problem & why now — is the user problem clear and evidenced (not just a feature request)?
- Audience — are target users/segments and their context defined?
- Goals & success metrics — measurable outcomes, baseline → target? Anti-goals stated?
- Scope — explicit in/out? MVP vs. later cuts clear?
- Requirements — unambiguous, testable, prioritized (must/should/could)? No solution disguised as requirement.
- UX — flows, key states (empty/error/loading/edge), accessibility considered?
- Edge cases & failure modes — what happens when things go wrong?
- Dependencies & constraints — other teams, platforms, legal/privacy, performance.
- Risks & open questions — named, with owners.
- Measurement — instrumentation/analytics plan to know if it worked.
Process
- Read the PRD fully first.
- Rate each dimension: ✅ solid / 🟡 needs work / 🔴 missing — with a one-line reason.
- List the top gaps to fix before build, most important first.
- Pose the open questions the author must answer to be buildable.
- End with a verdict: Ready / Ready with fixes / Not ready.
Output format
A checklist table (dimension · rating · note), then Top gaps, Open questions, and the verdict. Be specific and kind; the goal is a better doc, not a teardown.