📝Writing PRDs (Product Requirement Docs)
The PRD isn't a spec — it's a tool for alignment. Modern PRDs are 1-2 pages, opinionated, and focused on the user problem.
The PRD is the single most-used PM artifact. A great PRD aligns engineering, design, and stakeholders in 10 minutes of reading; a bad one creates weeks of confusion. The format has evolved — most modern PRDs look nothing like the 30-page waterfall specs of 2005.
A modern PRD answers five questions: (1) What user problem are we solving? (2) Who specifically? (3) Why is it worth doing now? (4) What are we building? (5) How will we know it worked? Keep it short, opinionated, and updated as you learn. The PRD is a living conversation, not a contract.
The modern PRD format
1. TL;DR (3-5 sentences). What you're building, for whom, why, by when. This is the only section many readers will read.
2. Problem. The user problem. Quote real users if possible. What's broken today, who feels it, how often, how badly. Include evidence — support tickets, interview clips, data.
3. Why now. Why this is the right thing to build this quarter vs other competing priorities. Tie to strategy.
4. Goals & non-goals. What success looks like and — equally important — what this PRD explicitly isn't trying to solve. Non-goals prevent scope creep.
5. Success metrics. Primary metric (1), guardrail metrics (2-3), tracking plan. Define before you ship.
6. Solution overview. What you're building, at a high level. Link to designs, mocks, or prototypes.
7. Open questions / risks. What you don't know yet. What could go wrong. Where you need help.
8. Rollout plan. Phased launch? Feature flag? Beta cohort? Marketing?
9. Appendix. Detailed specs, edge cases, technical considerations — but only if they exist and the engineers want them in the doc.
What modern PRDs don't have
- 30 pages of edge cases. Push those to the technical spec the engineers own.
- Detailed UX prescription. Link to Figma; let designers design.
- Promises about timeline before the team has estimated.
- Project management content (Gantt charts, dependencies). Live in your project tracker.
The before/after rule
Before you write a PRD, you should be able to answer: "if a senior engineer reads this in 10 minutes, will they know what to build and why?" If no, the PRD isn't ready.
After the team has shipped, the PRD should be updated to reflect what was actually built and what was learned. PRDs that go stale are useless. PRDs that compound over time become the team's product memory.
AI-era PRDs (2025+)
Most PMs are now using ChatGPT, Claude, or ChatPRD to draft PRDs. The pattern: PM writes the bullet points and customer evidence, AI expands into prose, PM edits and adds judgment. The risk: AI-generated PRDs often miss the why now and the strategic context — those still require human judgment. AI gets you to 60%; you do the last 40%.
Modern AI-era PRDs are also shorter than 2020-era PRDs, because the cost of generating prose is near-zero and the constraint has shifted to what's worth reading.
Key frameworks
Instead of a PRD, write the launch press release and an FAQ. Forces clarity on the customer benefit and the most likely objections.
Single-page PRD with: problem, solution, metrics, risks. Force-fits the doc to the most important content.
Engineering-led format that lets the team debate the proposal asynchronously. Good for cross-team or platform work.
Real-world examples
Amazon famously writes the press release and FAQ *before* the product is built. The PM drafts what the launch announcement would say — and if it doesn't sound exciting to a customer, the team rethinks the product before writing a line of code.
Figma PMs are known for short, living PRDs that get updated weekly during the build. The doc is treated as a conversation, not a contract — and the version history is the project's memory.
Common pitfalls
- ⚠Writing the PRD before talking to users — you'll spec the wrong thing eloquently.
- ⚠Treating the PRD as a contract — engineers stop pushing back, you stop learning.
- ⚠Forgetting the success metric — you'll ship and have no idea if it worked.
- ⚠Letting the PRD go stale post-launch.
Go deeper — recommended reading
Interview questions (3)
Q1Walk me through how you'd write a PRD for a new feature.executionmid▼
Six steps:
- Talk to users first. Don't write anything until you've heard the problem in their words. 5-10 interviews is the minimum.
- Draft the TL;DR. Three sentences. What, who, why. If you can't write the TL;DR clearly, you don't understand the problem yet.
- Define success metrics. Primary metric, guardrails. This forces clarity on what "done" means.
- Write the problem and solution sections. Keep it short — the goal is to be readable in 10 minutes.
- Review with the team. Engineering, design, support. Their pushback usually reveals what the PRD is missing.
- Live with it. Update as you learn during the build. The PRD post-launch should reflect what was actually built, not the original plan.
I keep my PRDs to 1-2 pages and link out to detailed specs or designs. The PRD is for alignment, not for prescription.
Q2What separates a great PRD from a mediocre one?executionmid▼
Three things:
- Clarity on the user problem. Mediocre PRDs start with the solution. Great PRDs start with a real, specific, evidence-backed problem.
- Crisp success metrics. Mediocre PRDs say 'increase engagement.' Great PRDs say 'move D7 retention for new signups from 32% to 40% within 90 days, with no degradation in checkout conversion.'
- Honest risk section. Mediocre PRDs are optimistic. Great PRDs name the two or three things that could make this launch fail and what the team will do if they happen.
The fourth, subtler thing: great PRDs are short. The constraint of writing only what's worth reading forces the PM to make real decisions instead of hiding behind comprehensive prose.
Q3How has the PRD changed with AI?executionsenior▼
Three shifts.
First, first-draft prose is essentially free now. PMs draft bullet points, hand them to ChatGPT or Claude, and get a polished doc back. The constraint has shifted from 'time to write' to 'time to think.'
Second, the PRD is getting shorter, not longer. Because prose is cheap, what's valuable is judgment and crispness. Long PRDs were partly a flex; with AI, they're just clutter.
Third, prompts and example prompts now belong in the PRD itself. For AI features, the PRD includes the system prompt, sample user inputs, expected outputs, and eval criteria. This is a new section that didn't exist three years ago.
The risk: AI-drafted PRDs can sound plausible but lack the why now and strategic context. The PM still has to do the thinking — AI just removes the typing.