Product Requirements (PRD)

---
name: Product Requirements (PRD)
description: Write requirements that align a team.
---
# Product Requirements (PRD)

A PRD exists to make the team build the *right* thing, not just any thing. The trap is writing specs so detailed they pre-decide the solution, or so vague that everyone builds something different.

## Required sections
- **Problem.** The user's pain, with evidence (interviews, data). If the problem isn't real, the spec is moot.
- **Target user.** Who specifically. Not "users" — a named segment with a named context.
- **Success metric.** What number moves, and by how much, to call this done. Without it, "done" is opinion.
- **Scope.** What's in, what's explicitly out. The "out" list prevents scope creep more than the "in" list does.
- **Open questions.** What you don't yet know. Naming them lets the team solve them rather than guess around them.

## Avoid
Solution detail belongs in design docs, not the PRD. The PRD says what and why; the team figures out how.