# PRD format

Use when a product manager needs to align a team on what to build and why, before design and engineering commit.

## Great instance

- Leads with the user problem and the evidence it's real, not with the proposed solution.
- States goals and explicit non-goals so scope is unambiguous.
- Ties every requirement to a user need and a success metric.
- Leaves design and implementation open — it says what and why, not how.

## Cut

- Engineering design, schemas, and API shapes (those belong in a design doc).
- Solutions with no stated problem or metric.
- Vague "delighters" with no acceptance criteria.

## Skeleton

```markdown
# PRD: <feature>

## Problem
<the user problem, who has it, and the evidence it matters>

## Goals and non-goals
- Goal: <measurable outcome>
- Non-goal: <explicitly out of scope>

## Users and use cases
<primary persona + the top 2-3 jobs they need done>

## Requirements
| # | Requirement | User need | Priority |
| --- | --- | --- | --- |
| 1 | <what> | <why> | P0/P1 |

## Success metrics
<the metric that tells us this worked, and its target>

## Rollout
<phasing, flags, and who gets it when>

## Open questions
- <decision still needed, and who owns it>
```

## Section prompts

- Write requirements as testable statements, one per row, so a reviewer can comment on exactly one.
- Name the metric before the feature; if you can't measure it, question whether to build it.
- Keep non-goals explicit — they prevent the scope creep reviewers worry about.

## Renderer moves

Catalog: ../building-artifacts.md#what-each-file-type-becomes - md doc reader sections; requirement + metric table cell anchors.