What goes in (modern PRD)
- Problem — what user / business pain are we solving?
- Outcome / success metric — how we'll know it worked.
- User — who specifically. Not "users" — a real persona or segment.
- Solution overview — what we're building, at conceptual level.
- Acceptance criteria / scope — what's in, what's out, what does done look like.
- Open questions / assumptions — what we don't know yet.
What's NOT in
Detailed UI specs (those live in design tools). Implementation details (those are eng's call). Project schedule (that's the project plan, not the PRD). Keep the PRD about the why and the what — leave the how to the people closest to it.
↳ in the wild
The 50-page PRD is usually a cover for skipped discovery — the PM didn't do the user research, so they pad with implementation detail to feel productive. The 2-page PRD with a clearly stated problem and outcome is the harder document.
Cagan's product brief
Marty Cagan (Inspired) advocates a even leaner version: a one-page product brief covering objective, key results, and the constraints. The implementation discovery happens collaboratively with engineering and design; the PRD isn't a hand-off document, it's a starting point.