Q:How do I write a good PRD or product spec?

Sources converge on writing the problem and outcome first, with the solution left open, and on keeping the document short and collaborative rather than a long, final-word spec.⁴⁵⁷⁹

01Start with the problem, not the solution

• Describe the user opportunity and its benefit before naming any solution, since detailed upfront solutions cause overcommitment.⁵
• Lead with a crisp problem statement and define specific success criteria so teammates aim at the same target.⁹
• Marty Cagan says the spec should describe the functionality and behavior of the product, not how it will be implemented.⁶

02Make it specific and testable

• Name a specific role or triggering context, then the challenge and the user benefit, and define a measurable outcome.⁵
• Write acceptance criteria from the end user's perspective before implementation, with quantifiable thresholds and enumerated error cases.²
• Cagan proposes a high-fidelity prototype as the core spec, tested with target users before engineering starts, with release and platform requirements kept in a supplementary wiki.⁷

03Keep it short and shared

• Teresa Torres recommends many small user stories over one long PRD, since engineers tend to read a long document once and then lose the reasoning.¹
• Give enough direction on requirements and constraints without prescribing the solution, and move extra context into an appendix.⁹
• Agree on a team process for who chooses and defines opportunities before development begins.⁵