Checklists

PRD review checklist

I can state the problem in one sentence because if I can’t, engineering will build different solutions for different imagined problems.
Success metrics are explicit because “ship it” is not a measurable outcome and we need a shared definition of done.
Non-goals are written because scope creep happens through reasonable-sounding “small adds” that accumulate into a rewrite.
Requirements are testable because vague requirements create QA guesswork and post-launch blame.
Edge cases are considered because the edge cases are where users lose trust (and support load explodes).

The rollout plan is written because “we’ll just release it” is how you accidentally break your best customers.
Monitoring and alerts exist because if you can’t detect failure quickly, your users will detect it for you.
Support has a plan because every launch creates questions, and unanswered questions become churn.
Docs are updated because internal teams and customers will follow the docs, not your Slack messages.
A rollback plan exists because the only thing worse than a bad launch is being stuck with it.

The top items have a clear problem statement because refinement should clarify tradeoffs, not decode intent.
Each item has a success signal because you can’t estimate value if you don’t know what “better” means.
Dependencies are listed because hidden dependencies create fake confidence in timelines.
Acceptance criteria are drafted because engineering needs to know what “done” looks like to size the work.
Obvious unknowns are written as questions because unanswered questions become mid-sprint blockers.
The priority order is intentional because refinement without a priority is just brainstorming with estimates.

The decision to be made is written in one sentence because vague decisions create endless debate.
The options considered are listed because “only one option” usually means we didn’t do the thinking.
The tradeoffs are explicit because alignment comes from shared sacrifices, not shared optimism.
The decision owner and override path are clear because confusion about decision rights creates politics.
The communication plan is ready because a good decision still fails if it’s announced badly.

We compare outcomes to the pre-launch hypothesis because without that, we can’t learn — only celebrate or blame.
We review guardrails because many launches “win” the primary metric while quietly breaking something else.
We capture what surprised us because surprises are the seeds of better systems and better future estimates.
We document the biggest user friction points because the next iteration should target pain, not aesthetics.
We record operational issues and fixes because reliability work is easier when the history is written down.
We decide the next action (iterate, rollback, or pause) because post-launch reviews without decisions are just therapy sessions.