Product Requirements Document
By Cameron Chen · Published · Updated
Enough detail that two engineers would build the same thing.
Tags: Product, Planning, Writing
Prompt template
# PRD **Problem** - What is wrong today: [textarea: The user problem] - Evidence: [textarea: Data, support tickets, research, or say if it is a hunch] - Who is affected and roughly how many: [textarea: Segments and scale] **Solution** - What we would build: [textarea: The proposed change] - User-visible behaviour: [textarea: What actually happens, step by step] - Edge cases and error states: [textarea: Empty, failed, slow, unauthorised, existing data] - Explicitly out of scope: [textarea: What people will otherwise assume is included] **Constraints** - Technical, legal, or dependency: [textarea: Anything that limits the solution] - Deadline and what is driving it: [text: Date and why] **Success** - How we will know it worked: [text: Metric and target] - When we will check: [text: Date] Lead with the problem and the evidence, not the solution. If the evidence is thin, say so in the document rather than burying it. Write the requirements as observable behaviour including the edge cases, because that is the part engineers otherwise have to invent. Say what happens to data that already exists. Make the out-of-scope section prominent. It is the cheapest scope-argument prevention available. End with open questions, each with an owner and a date.