How to write a PRD that ships instead of stalls

TL;DR. A PRD is one short doc about what a product change is for — the problem, the user, the shape of the fix, the constraints, the success measure, and what’s out of scope. Written as a one-page pitch first, expanded to a working doc only if engineering asks. Two pages, not ten. Owned by one named PM through the review loop. Lives in the wiki, next to the feature spec it spawns and the team charter it serves. Most teams ship the wrong artifact at the wrong length; the working shape ships at the length engineering will actually read.

Most PRDs read like a contract between a Product Manager and their own anxiety. (Whiskers, our PM, has a folder called “PRDs (drafts)” with thirty-eight files in it. The folder called “PRDs (shipped)” has four. He’s working on the math.) The good news about how to write a PRD is that the working shape has been roughly the same since IBM wrote down the first one in the seventies: problem, audience, fix, constraints, success measure, out-of-scope. The bad news is that twenty years of process tooling have inflated the artifact into a ten-section template that takes three weeks to draft and nobody reads. The rest of this post is the short shape, the distinction between the PRD and the four artifacts it gets confused with, who owns it through review, and where it lives between the day you write it and the day the feature ships.

A PRD is one short doc about what a product change is for

A PRD — product requirements document — is a written artifact that answers, before engineering starts work, “what are we building, for whom, and how will we know it worked?” The audience is the team that will build the thing: engineering, design, QA, and whoever needs to know enough to commit. The PRD is not a contract with the customer, not a design of the feature, not a project plan for the build. It’s the upstream document the others depend on.

A PRD succeeds when:

An engineer who joins the project halfway through can read it cold and understand what they’re being asked to build and why.
The team disagrees about how to build it after reading the PRD — but agrees about what and why.
The PRD has a named author, a date, and a next-review trigger; nothing in it is older than the most recent product decision it depends on.
The doc is short enough that the engineers who read it finish reading it. Two pages is the working bar; four pages is the absolute ceiling.

Anything shorter is a Slack message; anything longer is a white paper. Two pages is the right length for a PRD the way 200–600 words is the right length for a runbook: the constraint forces the writer to make decisions instead of describing them.

PRD vs feature spec vs design doc vs ADR — what goes where

The four artifacts get confused and shouldn’t. Each one answers a different question; the team that writes one artifact when they meant another wastes a week. The split that survives contact with a real engineering team:

Artifact	Question it answers	Audience	Owner	Length
PRD	What are we building, for whom, and why?	Eng + Design + QA + PM	Product manager	1–2 pages
Feature spec	Exactly what does the feature do, edge cases included?	Engineering	Engineering lead	2–5 pages
Design doc	How are we going to build it technically?	Engineering	Tech lead / staff engineer	3–8 pages
ADR (decision record)	What specific choice did we make and why, for the future?	Eng + future joiners	Whoever made the call	1 page

A PRD describes the user-facing problem and the shape of the fix. A feature spec describes the behaviour the engineers build. A design doc describes the technical approach. An ADR describes the specific decision and the alternatives that lost.

A working example, in order: “We want users to recover a deleted page in one click within seven days.” That’s a PRD line. “The recover-page endpoint accepts a soft-deleted page-id, validates the seven-day window, restores the row, and returns the new revision.” That’s the feature spec. “We’ll use a deleted_at timestamp and a daily cleanup job that hard-deletes anything past the window.” That’s the design doc. “We chose deleted_at over a separate deleted-pages table because the JOIN cost is lower and the soft-delete is rarer than the read.” That’s the ADR.

If you’re writing one and reaching for another’s content, you’re writing the wrong artifact. Four documents. Different owners. Same wiki.

The seven sections every PRD needs

A working PRD is a single short doc with seven sections, in this order. Same headings every time; the engineer reading the PRD doesn’t have to learn a new format per feature.

Section	What it answers	Length
Title + author + date	What is this, who wrote it, when	One line
Problem	What user pain are we solving, with evidence	1–2 paragraphs
Audience	Who specifically is affected (segment, scale)	1 paragraph
The shape of the fix	What the change looks like, at a high level	2–4 paragraphs
Success measure	The single number that will tell us it worked	A line and a target
Constraints + out of scope	What we’re explicitly not doing	A short list
Open questions	What still needs answers before engineering starts	A list with owners

The Problem row is the load-bearing one. Not “users want to recover deleted pages” — “users have lost three workshop write-ups in the last month to accidental deletion, and two of them filed support tickets we couldn’t resolve.” Evidence is load-bearing; vibes are not. If the problem doesn’t cite a specific signal (a ticket, a survey datapoint, a session recording, a churn note), the PRD is upstream of the work it should be downstream of.

The Audience row is who specifically. Not “users” — “Free-tier admins on teams of three to five engineers who manage the only shared wiki for the team.” Audience-shaped specificity is what lets engineering reject the wrong optimisation a month from now.

The Shape of the fix row is the part that gets oversold across the PRD genre. A PRD is not a design — it describes the shape of the fix at a level the team can debate. “A trash-bin pattern with a seven-day window and a single recover button” is shape. “A modal that pops at 12px font with a confirm dialog and a soft-pink primary CTA” is design, which belongs in a Figma file linked from the PRD, not in the PRD itself.

The Success measure row is one number with a target. Not five KPIs and an OKR table. “Reduce support tickets tagged recovery to under 5 per month within 60 days of ship.” That’s a measure. “Improve user satisfaction” is a wish.

The Open questions row is what protects the PRD from shipping at the wrong moment. Every open question has a name beside it. “Should this apply to comments too? — Maple, 2026-05-18.” When the question gets an answer, the question moves into the body; the Open questions row should be empty by the time engineering starts work.

Start with the one-page pitch

The single biggest move that separates a useful PRD from a counter-productive one is starting short. Most PMs write the ten-page PRD first and try to defend it to engineering. The working pattern is the opposite: write the one-page pitch first, sit with whichever engineer cares, see if the pitch holds. The full PRD is the second draft — what survives the pitch.

Marty Cagan’s “PRDs are dead” critique from 2007 is now PM-canon: the heavy PRD is a relic of waterfall, and the modern team is better served by a one-page pitch + a real feature spec. The take is right enough to take seriously and wrong enough to need a counter: some teams genuinely benefit from the formal artifact (regulated industries; teams with weak product-engineering trust; multi-team features where who agreed to what matters six months later). The honest posture is write the lightest PRD that gets the feature built right — sometimes that’s a Slack thread plus a design doc, sometimes it’s a two-page PRD with the seven sections, sometimes it’s the heavier version with appendices. The constraint that prevents bloat is the audience: if the engineer who builds this won’t finish reading the doc, the doc is too long.

Two practical rules for keeping PRDs short:

Cut every paragraph that explains why a feature is important without naming evidence. “Users will love this” is filler; “three customers asked for it on this quarter’s QBR calls” is evidence.
Cut every section that’s already in another doc. The PRD does not need to repeat the team charter, the SLO targets, or the QBR strategy. Link them. The PRD is the new writing for this feature, not a re-statement of context engineering already has.

For a working short-PRD template you can copy into your wiki and adapt per feature, the Feature Specification template is the closest importable shape — it doubles as a PRD with the Problem and Audience sections filled, or as the downstream spec once engineering picks up the build.

Who owns the PRD across drafts and review

This is the part the long-form SERP guides gesture at and don’t operationalise. The PRD is a cross-functional artifact that touches engineering, design, QA, support, and sometimes legal — and cross-functional artifact is the polite name for document owned by nobody. The result is a PRD that goes through nine reviewers and stalls at the tenth.

The working pattern, after watching teams stall and unstall:

One named owner per PRD. The PM. Not a team alias, not the product org. The owner is who you ping when the doc hasn’t moved in two business days. The PRD a PM can’t name is a PRD nobody is steering.
A clear review lane. Design + Engineering lead review the draft → PM revises → Eng team comments → PM ships v1. Three rounds, not nine. Named reviewers, named days. Most PRDs stall on trying to reach consensus with the whole org; the lane is what protects against that.
An SLA per round. “Design + Eng lead: 3 business days. Team comment round: 2 business days. PM revision: same day.” If anyone exceeds the SLA, the PM re-routes.
Tracked-changes mode is the working mode. Comments and suggestions on the doc itself — not Slack threads, not meetings, not parallel email chains. Comments leave a trail the future joiner can read.
The PRD is not a meeting. The kickoff meeting is after the PRD is at v1. PRDs that die in committee die because they got written in committee.

A short rule that survives most teams: PRDs ship when one person owns the next move at every moment. Two co-owners is no owner; “the team owns it” is no owner. PRDs are not the exception to product accountability — they are where you discover whether your accountability shape works at all.

Where the PRD lives between sprints

The standard answer is “in Google Docs”, and it’s wrong in the same way “runbooks live in Google Docs” is wrong: the doc has a home before launch, and a different home after. What the top-3 SERP guides skip is that the PRD has three phases — draft, ratified, in-flight — and each phase has a different reader.

The right home for a PRD in each phase:

Draft phase — in the wiki, with comments open. The PRD is in the same workspace as the team charter and the case studies. The audience is the review lane; comments are the working mode. Pages load in 50–150ms on Raccoon Page — which is the load profile a reviewer scrolling through a doc with twenty inline comments actually has.
Ratified phase — in the wiki, frozen. Once the PRD has shipped v1, it’s pinned (not edited) and the next changes live in a separate Change log section at the bottom. The frozen body is what the engineer who joins the project on day 45 reads cold. The change log is what they read second.
In-flight phase — linked from the engineering doc. The PRD is now upstream of the feature spec, the design doc, and the decision records the engineers are writing. The PRD does not move; the docs downstream of it move. The PRD is the receipt of why this work was committed to.

The PRD index — a single page that lists every active and shipped PRD in reverse chronological order with the Problem sentence visible — is the actual artifact of your product discipline; the individual docs are the receipts. Sub-second loads, keyboard-first is the same operational bar as everywhere else, and uniquely uncomfortable when the doc you want to find is the document six PRDs ago with the answer to the question the new joiner just asked.

The PRD that shipped: one canon example

The patron PRD of Raccoon Corp doesn’t exist as a doc. The origin story is that Chrome Claw, sometime around 04:11 PST one Tuesday in January 2026, told Zyberion Glitchpaw he was going to build a faster wiki before the coffee finished brewing. That sentence is the one-page pitch — user (internal engineers), problem (Confabula loads in 11 seconds), shape of the fix (Postgres + Dapper + Vite), success measure (under a second), constraint (before the coffee finishes). By the time the coffee was ready — 04:22 — the first page rendered in 87ms. The proper PRD didn’t get written for another quarter, and it got written after the feature spec and the design doc, because by then the question was no longer “should we?” but “what exactly are we shipping next?”

The lesson isn’t don’t write PRDs — Raccoon Corp’s product canon now has a long list of formal PRDs, all of them referencing back to the original pitch. The lesson is write the shortest thing that aligns the team, then write the longer thing only if the team asks for it. The patron PRD has six words and a coffee timer; most PRDs you’ll write will have more than six words. They don’t all need to have more than two pages.

The opinion this post stands behind: a PRD is scaffolding, not finished work. The PRD that’s exactly the shape that made the team agree to build the thing is the right PRD — not the longest one, not the prettiest one, and not the one with the most appendices. The team that ships writes PRDs the length the team will actually read.

Things people actually ask

What is a PRD, in one sentence? A short written document that names the problem, the audience, the shape of the fix, the success measure, the constraints, and the out-of-scope — written by the PM, reviewed by engineering and design, and shipped before the build starts.

What’s the difference between a PRD and a feature spec? Scope. A PRD describes what we’re building and why; a feature spec describes exactly what the feature does, edge cases included. The PRD is upstream; the feature spec is downstream. The PM owns the PRD; the engineering lead owns the spec.

How long should a PRD be? One to two pages. Four pages is the absolute ceiling. A PRD the engineering team won’t finish reading is a PRD that won’t ship. Write the one-page pitch first; expand only if the team asks for the longer version.

Who writes the PRD? The product manager who owns the feature. Not the engineering lead; not the designer; not the AE. The PM holds the audience and the problem definition; the spec and the design come after.

What goes in a PRD that doesn’t belong? Anything technical (it belongs in the design doc), anything visual (it belongs in Figma linked from the PRD), anything contractual (it belongs in the SLA), and most of the why-this-is-strategically-important paragraph (it belongs in the team charter the PRD links to).

Are PRDs dead? The heavy waterfall PRD — fifteen sections, three appendices, six approvals — is mostly dead, and Marty Cagan called it in 2007. The one-page pitch + working short PRD + downstream feature spec is alive and well; it’s the shape most modern teams use, even when they call the artifacts different things.

How does a PRD evolve after the feature ships? It doesn’t, mostly. The PRD freezes at v1; the change log section at the bottom captures any deltas as the work unfolds. If the product direction changes substantially mid-flight, you don’t update the PRD — you archive it and write a new one, because “the team agreed to X” and “the team later agreed to Y” are two different decisions worth two different documents.

Where should the PRD live? In a wiki, in the same workspace as the team charter, the SLO doc, the case studies, and the runbooks. PRDs that live in personal Google Drives are PRDs that get re-found at the worst possible moment by the worst possible person.

Should the PRD include a timeline? Generally no. Timelines live in the project plan; the PRD describes the what and why of the work. A target launch window (a quarter, not a date) is fine; a Gantt chart is a project plan in a costume.

If your last PRD is currently a six-page Google Doc with sixteen unresolved comments and a four-month-old thread on “are we still doing this?”, the upgrade isn’t a longer PRD — it’s a two-page version with a single owner, a three-round review lane, and a wiki page the engineering lead can find. Try the Free tier on the PRD you’ve been meaning to ship; three users, one space, a hundred pages, no card. For PMs who already have more PRDs than the team can read, the Team tier at $8/user/month is the honest math. If the next engineer can’t find the PRD that explains what they’re building, write to us; we want to know which folder it lived in.