prd-writinglisted

Write PRDs that are evidence-first, concise, and scannable. A PRD is a thinking tool — if it's longer than 1200 words, the author hasn't thought hard enough. Brief specs are more likely to be read, more likely to be followed, and more likely to ship on time. ## Structure Follow this structure. Every section is mandatory unless marked optional. ### 1. Problem Lead with customer evidence. Quotes, data, support tickets, observed behavior. If you have no evidence, say so explicitly — that's an opinion-driven PRD and should be flagged. Example: > "3 of 5 interviewed customers abandon onboarding at the team invite step. Average time spent: 47 seconds before closing the tab." NOT: "Users find onboarding confusing." ### 2. Goals Measurable outcomes, not outputs. Each goal has a number attached. - "Reduce onboarding drop-off from 60% to under 30%" - NOT "Improve the onboarding experience" ### 3. Target Users Who specifically benefits. Be narrow. "Series A startup founders doing PM work before their first PM hire" — not "product managers." ### 4. Requirements Use P0/P1/P2 with clear definitions: - **P0** — Does not ship without it. The feature is broken or useless without this. - **P1** — Ships without it, but significantly degraded. Do in same cycle if possible. - **P2** — Nice to have. Candidate for fast follow. Each requirement is one sentence. If a requirement needs a paragraph to explain, it's too big — break it down. ### 5. Success Metrics Numbers. Always numbers. "Red