Most PRDs are too long, too vague, or both. Engineers read the first paragraph, scan the rest, and ask follow-up questions to figure out what was actually intended. Claude can produce tighter PRDs in 20 minutes if you brief it on what engineers need.
Most PRDs are written by PMs who want to be thorough. The result: 8-page documents that obscure the actual ask. Engineers skim, get the rough idea, and start asking the PM what the doc actually meant.
The version engineers prefer is 1-2 pages: clear problem, clear user, clear success criteria, clear out-of-scope. The depth is in the appendix for those who want it, not embedded throughout.
1. The problem (1 paragraph). What user pain are we solving?
2. The user (1 paragraph). Who specifically, what context, what triggers the need.
3. Success criteria (3-5 bullets). How we know the feature worked. Measurable.
4. Scope (2 sections: "in" and "out"). Explicit about what is NOT in this build.
5. Open questions. What is unresolved that affects implementation.
6. Appendix (optional). User research, competitive analysis, supporting context.
Write a PRD for [FEATURE NAME]. The user problem: [SPECIFIC] The primary user: [PERSONA] What triggers the need: [SPECIFIC CONTEXT] Business outcome we expect: [METRIC THAT WILL MOVE] What I have heard from users on this topic: [PASTE INTERVIEWS / FEEDBACK] Known constraints: [LIST] What is already known about the technical approach: [SHORT] Write a 1-2 page PRD using the 6-section structure (Problem / User / Success / Scope / Open questions / Appendix). Constraints: - Total length under 800 words (excluding appendix) - Each section answers a specific question - Success criteria are measurable, not aspirational - Scope section is explicit about what is NOT in this build - Open questions are honest — do not pretend everything is resolved Goal: an engineer can read this in 3 minutes and understand what to build.