Skip to main content
Ask ten product managers what a PRD is and you’ll get ten different answers. Ask them to show you the last one they wrote and half will go quiet. The other half will share a 40-page Google Doc that nobody read past page three 😅 I’ve been on both sides of that story.

​
What is a PRD?

A Product Requirements Document is a written description of what a product or feature needs to do - and why. It’s the artifact that bridges discovery and delivery: it captures the problem you’re solving, the context behind it, and the requirements your solution needs to meet. The key word there is why. A PRD that only describes what to build is just a spec. A good PRD explains the reasoning - the customer problem, the business opportunity, the assumptions you’re making - so that the team can make good decisions when reality doesn’t match the plan (and it never does).

​
Why bother writing one?

There’s a popular counter-argument in agile circles: PRDs are waterfall thinking. Just write user stories and get on with it. I’ve tried that. What you get is a team that builds quickly in six slightly different directions - or worse, falls into what Melissa Perri calls the build trap in Escaping The Build Trap: busy shipping features, with no idea whether any of it matters. The value of a PRD isn’t the document - it’s the thinking it forces. Writing down why you’re building something surfaces assumptions. Defining success criteria before you start means you’re not inventing them post-launch to explain why the numbers are low. Aligning stakeholders on scope upfront saves you the painful “I thought this would also include…” conversation three weeks into the sprint. Lesson learned: the teams that skip the PRD don’t skip the thinking - they just do it later, under pressure, when it’s more expensive to change course.

​
What goes in a PRD?

There’s no universal template, but a solid PRD covers: Problem statement - What customer problem are you solving? Be specific. “Users struggle with X when they try to Y” is better than “improve the onboarding experience”. Background and context - Why now? What research, data, or customer interviews led you here? This is where your Opportunity-Solution Tree evidence lives. Goals and success metrics - How will you know it worked? Define your north star metric and the secondary signals you’ll watch. If you can’t define success before you build, you won’t be able to measure it after. Josh Seiden’s Outcomes Over Output is a short, sharp read if you want to sharpen your thinking here. Scope - What’s in, what’s out, and what’s explicitly a future consideration. The “out of scope” section is often the most important part. Requirements - Functional requirements (what it does) and non-functional requirements (performance, security, accessibility). Keep these outcome-focused where possible - describe the behaviour, not the implementation. Open questions - The things you don’t know yet. A good PRD is honest about its assumptions and flags what still needs answering before or during build. Stakeholders - Who needs to be informed, consulted, or has sign-off. Saves a lot of “why wasn’t I involved?” conversations later.

​
How long should it be?

As long as it needs to be and no longer. A one-page PRD for a small feature is fine. A ten-page PRD for a major platform change is fine. A forty-page PRD that covers every edge case before you’ve validated the core value proposition is a red flag - it usually means someone is trying to avoid the uncertainty of building by over-planning instead. A useful rule: if you can’t summarise the problem and goal in two sentences, you don’t understand it well enough yet. Write those two sentences first. Everything else follows from there.

​
Living document vs. snapshot

One thing worth deciding upfront: is your PRD a living document that evolves as you learn, or a signed-off snapshot that represents a point-in-time decision? Both are valid. The living document approach works well for longer initiatives where the team needs a single source of truth. The snapshot approach is better for audit trails and stakeholder alignment - you can always see what was agreed and when. Just be explicit about which one you’re doing. A “living document” that nobody updates is just an outdated spec with good intentions.