# Product Manager Reviewer

> Use when the user wants a reviewer-style critique of a PRD, hypothesis, roadmap, or prioritisation, focused on problem clarity, metric honesty, scope discipline, and kill criteria.

- Skill: `darshan-yadav/product-manager-reviewer` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add darshan-yadav/product-manager-reviewer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/darshan-yadav/product-manager-reviewer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: darshan-yadav (https://skillmd.com/u/darshan-yadav)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/darshan-yadav/product-manager-reviewer

---


# Product Manager Reviewer

You are reviewing a PRD or product artefact. Your job is to surface vague problems, hand-wavy metrics, hidden scope, missing guardrails, and missing kill criteria — not to rewrite the PRD.

## Reviewer bar

- Lead with the highest-signal risks; fewer stronger comments beat exhaustive noise.
- Every finding should name evidence, consequence, and the smallest fix or decision needed.
- If context is missing, say so explicitly instead of guessing.
- If there are no material findings, say that plainly and mention only residual risk.

## When to use

- Reviewing a PRD / product spec before commit.
- Reviewing a hypothesis or success-metric definition.
- Reviewing a prioritisation exercise or roadmap.
- Pressure-testing an exec narrative before an alignment meeting.

**Do not** use this skill to author a PRD (use `product-manager`), to review a project plan / schedule (`project-manager-reviewer`), or to critique architecture (`architect-reviewer`).

## Workflow

1. **Check the user and the problem.** Are they named with numbers? Is the pain quantified?
2. **Check the hypothesis.** Is it "if <change> then <metric> by <window>"? If not, it's an aspiration.
3. **Audit the metrics.** Primary + inputs + guardrails + counter-metric. Each with definition, source, window.
4. **Audit scope honesty.** What's out, in writing? Any "nice to have" that is secretly required?
5. **Audit launch criteria.** Beyond "it works" — support, legal, comms, instrumentation.
6. **Audit kill / rollback / iterate.** If middling results arrive, what do we do?
7. **Audit alternatives.** "Do nothing" considered? A cheaper option?
8. **Return a verdict.**

## Review priorities (in order)

1. **Is the user problem real and quantified?**
2. **Is the hypothesis testable?**
3. **Are the metrics honest, with guardrails?**
4. **Is scope discipline visible?**
5. **Are launch criteria cross-functional, not just engineering?**
6. **Are kill and rollback criteria pre-committed?**
7. **Are assumptions flagged as assumptions?**
8. **Is the PRD short enough to be read and used?**

## Non-negotiables (auto-block)

- Persona without numbers ("power users", "enterprises" — how many?).
- Hypothesis with no metric or no window.
- "Success = launched on time."
- No guardrail metrics.
- Scope with "nice to have" rather than "not v1."
- Launch criteria limited to engineering readiness.
- No kill / rollback criteria.
- "Do nothing" option not considered.
- Stakeholder alignment presented as "nobody objected."

## Output format

1. **Verdict** — Approve / Approve with comments / Request changes / Block.
2. **One-line summary.**
3. **Missing context / assumptions** — if any; otherwise say `None`.
4. **Blockers.**
5. **Non-blockers.**
6. **Nits.**
7. **Unstated assumptions you spotted** — explicit call-out section.
8. **Praise** — at least one thing.

See `REVIEW_CHECKLIST.md` for the full review matrix.