The Five Things Every PRD Needs

1. The problem statement. One paragraph describing who has this problem, what the problem is, and why it matters now. If you can't write this paragraph without ambiguity, you're not ready to write the rest of the document.

Good: "Operations managers at logistics companies currently export shipping data to Excel to create custom reports. This takes 2–4 hours per week per manager and produces static reports that are outdated within 24 hours."

Bad: "We want to improve the reporting experience for users."

2. Success metrics. How will you know this feature worked? Name specific, measurable outcomes. "Users who interact with the new dashboard at least once per week" is a metric. "Better user experience" is not.

3. Scope: what's in, what's out. Explicitly naming what this version does not include is as valuable as naming what it does. "Out of scope: custom report templates, scheduled email delivery, PDF export." This prevents scope creep during development and misaligned expectations at review.

4. User stories or jobs to be done. How users will interact with the feature, in their words and their context. "As an operations manager, I need to filter shipments by carrier so I can identify which carriers are causing delays." Not every story needs to be in the PRD, but the two or three critical paths should be.

5. Open questions and decisions. A PRD written before any design or implementation will have unresolved questions. List them explicitly. "Open: do we support multiple simultaneous filter selections, or single-select only?" An open question listed is a decision that gets made once, intentionally. An open question not listed is a decision made by whoever is coding that day.

What to Leave Out

Implementation details. The PRD describes what needs to happen, not how to make it happen. "The filter should respond within 200ms" is a valid constraint. "Use debouncing with a 300ms delay on the search input" is an implementation decision for the engineer.

Wireframes as requirements. Including wireframes in a PRD is fine for context, but make clear they represent intent, not specification. If engineering can't build exactly the wireframe due to technical constraints, the product goal should still be achievable. The wireframe is a hypothesis, not a contract.

Everything. The biggest mistake in PRDs is comprehensiveness. An 8-page PRD has a much lower chance of being read than a 2-page PRD. Write the minimum context that allows engineers to make good decisions. Add detail only where ambiguity would cause rework.

The Habits That Make PRDs Work

Write the PRD before you're in the sprint. A PRD written during sprint planning is written in a hurry and reviewed by nobody. Write it 2–3 sprints ahead and share it for async review. The feedback will improve the spec and surface misalignments before they cost engineering time.

Review with engineers, not just product and design. Engineers reviewing a PRD before development starts are the best quality gate you have. They'll ask the questions about edge cases, performance, and technical feasibility that nobody else thinks to ask.

Update it as you learn. A PRD is not a historical artifact — it's a living document. When requirements change (and they will), update the PRD and note the change. This keeps the spec accurate and gives future team members context for why decisions were made.

Keep it in one place. The worst thing you can do is have the PRD in Notion, the design in Figma, the tickets in Linear, and the discussion in Slack — with no connection between them. Link everything from the PRD. It becomes the anchor document that connects all other artifacts.

A good PRD doesn't guarantee a successful feature. But a bad PRD — or no PRD — guarantees that at least some of what gets built will need to be rebuilt. The hour spent writing a clear spec is almost always recovered during development.