How do you write a good PRD?

A good PRD answers three questions before anyone writes a line of code: what problem are we solving, who has it badly enough that they'd switch products to fix it, and how will we know we won because of this feature and not something else. Everything else in the document is either supporting evidence for those answers or a decision-forcing mechanism that stops the wrong work from starting.

Start with the problem, not the solution

Most PRDs read like feature announcements. They open with what you're building — a new dashboard, a redesigned onboarding flow, a notification system — and bury the reason three paragraphs in, if it appears at all. That order is backwards, and it has real consequences: engineers optimize for the described interface rather than the underlying need, and when real users behave differently than expected, there's no shared reference point for deciding what to change.

The first section of your PRD should be a tight problem statement. One paragraph, no solution language. Describe the user, the situation they're in, and what goes wrong. If you can quote a specific support ticket, sales call, or user interview — with identifying details stripped — do it. Concrete evidence of a real complaint is worth more than a polished problem statement you wrote in a conference room.

The discipline of writing the problem first also surfaces whether you actually understand it. Founders frequently discover mid-draft that they're solving a symptom rather than the root cause. That's a good discovery to have before sprint planning, not after launch.

Define the scope with hard edges, not soft goals

A PRD that says 'improve user retention' as its success condition is not a PRD — it's a wish. Good requirements create a boundary between what's in scope and what's not, specific enough that any engineer on the team could make the same call independently when an edge case appears at 11pm.

For each feature, write an explicit 'not doing' list. This sounds defensive but it's actually one of the most useful things you can put in a spec. Stakeholders read 'notifications' and imagine push, email, in-app banners, digest summaries, and user preferences. Your engineer reads it and builds one thing. The explicit scope gap causes a rewrite or a political negotiation at demo time. Writing 'V1: in-app only, no email, no user controls for frequency' up front eliminates that entirely.

The same logic applies to success metrics. Choose one or two numbers that would move if the feature worked, and define the measurement window. 'Activation rate for new users in the first 7 days, measured as completion of the core workflow at least once' is a metric. 'Engagement' is not. If you ship the feature and the metric doesn't move, you need to know that clearly enough to kill the feature or change it — not be able to argue that a different proxy metric looked encouraging.

Write for the builder, not for the presentation

Garry Tan's approach to technical communication — 'lead with the point, be concrete, tie technical choices to user outcomes' — applies directly to PRD writing. A requirements doc written for a board deck uses passive voice, hedges on specifics, and avoids hard trade-offs. A requirements doc written for the person who has to build the thing names the exact state changes, the failure cases, and what a broken implementation looks like to a real user.

Practically: when you describe a user flow, walk through it as a sequence of states, not a narrative. What does the user see? What can they click? What happens if the data is missing? What happens if they're on a slow connection? These aren't edge cases to defer — they're the cases where your design decisions actually matter, because the happy path mostly builds itself.

Avoid any language that requires the reader to do interpretive work: words like 'seamless,' 'intuitive,' 'fast,' or 'simple' tell an engineer nothing actionable. Replace them with the observable outcome: 'loads in under 400ms on a 4G connection,' 'completes in three taps with no account creation,' or 'error messages include a specific recovery action, not a generic retry prompt.' Concrete descriptions survive handoffs. Abstract ones don't.

Front-load the decisions you've already made

One underrated function of a PRD is to record decisions that were made before the document existed — in hallway conversations, in a founders' call, during a user research debrief — so they don't get relitigated during build. Teams waste enormous time re-arguing things that were already settled, usually because the settlement was verbal and the engineer who missed the meeting has legitimate questions.

Add a 'decisions made and why' section. Keep it short. Each entry should be one sentence of what was decided and one sentence of why. 'We're using email confirmation instead of SMS because our user base is 40% international and SMS costs are unpredictable at scale.' That's it. Anyone reading the doc now knows not to re-open that question, and they know the reasoning well enough to apply it to adjacent decisions.

Also flag decisions that are explicitly still open. If you don't know whether the feature will be gated to paid users, say so, name who owns that call, and give a date by which it needs to be resolved. Open questions that aren't tracked become implicit assumptions that become bugs.

Treat the PRD as a living checkpoint, not a deliverable

The mistake teams make with PRDs is treating them as a handoff artifact — something that gets written, reviewed, and then filed. A document that was right at planning time is often wrong at build time, because real implementation surfaces information that wasn't available during spec. If the PRD doesn't change during a build, it's probably not being used.

Build a lightweight update process: any time a spec assumption is invalidated — by a technical constraint, a user test, a scope negotiation — whoever discovers it updates the relevant section with a timestamp and a one-line explanation of what changed and why. This isn't bureaucracy; it takes two minutes. What it prevents is the team silently building against an outdated spec while assuming everyone else is working off the same shared understanding.

The final PRD, after shipping, is also your post-mortem input. If you wrote 'users will complete onboarding in under two minutes' and your analytics show five, that gap is the first conversation to have. The discipline of writing specific, falsifiable requirements pays its full dividend when you're deciding what to fix in V2.

“Lead with the point. Say what it does, why it matters, and what changes for the builder.”

— Garry Tan, source

The one thing to do

Write your problem statement in one paragraph before touching any other section — if you can't do that cleanly, you're not ready to spec the feature.

Frequently asked questions

How long should a PRD be?

Long enough to answer every question an engineer would reasonably ask before starting, short enough that they'll actually read it. For most features, that's one to three pages. A five-page PRD that's read beats a ten-page PRD that's skimmed.

Who should write the PRD — the founder, PM, or engineer?

Whoever owns the decision about what gets built should own the PRD. In early-stage startups that's usually a founder or a founding PM. Engineers should be consulted on feasibility before the spec is finalized, not handed a finished document and asked to estimate.

What's the most common mistake founders make in PRDs?

Writing the solution before they've validated the problem statement. If you can't describe the user's situation and the failure mode in one paragraph without mentioning your product, you don't yet have a spec — you have a roadmap item dressed up as a requirement.

Do you need a PRD for small features?

You need something that records the problem, the decision, and the success metric — even if it's three bullet points in a Notion doc. The format doesn't matter. What matters is that the information exists somewhere other than one person's head before build starts.

Sources

More playbook answers · Growth Prophet home