writing-prds

Start with the problem, background, and why it matters now before any solution discussion. Then define the customer, success metrics, scope boundaries, and key open decisions so the document drives team action.

A PRD should include the problem statement and context, the target customer, measurable success criteria, explicit in-scope and out-of-scope items, and a 'why now' justification. For AI features, add prototypes, prompt sets, or executable evals.

For AI and UI work, interactive prototypes and prompt sets often communicate requirements better than prose. Leaders like Aparna Chennapragada and Guillermo Rauch advocate 'demos before memos' and live PRDs that reduce ambiguity.

It auto-persists via the ChatPRD MCP only when a complete draft exists with problem, customer, success metric, scope, and why-now. Partial drafts, guidance requests, and critique sessions are not saved.

Common mistakes include starting with the solution instead of the problem, omitting success criteria, writing exhaustive detail nobody reads, using static docs when prototypes work better, and missing the urgency justification.