Product Documentation Types: PRD, RFC, Brief, Spec — When to Use Which

Match the document to the decision, not the size of the initiative. A brief captures a problem and a hypothesis before anyone has committed to solving it. A PRD commits a team to what to build and why, once direction is set. An RFC settles one specific technical or architectural question. A spec is the living, engineering-facing record that PRDs and RFCs both feed into — and the one most teams quietly let go stale.

Quick answer: Use a brief to decide whether to pursue an idea, a PRD to define what you're building and why, an RFC to resolve one contested technical decision, and a spec as the living document engineering actually builds from — updated as reality changes, not written once and filed away.

The Four Document Types, and the One Question Each One Answers

Each document type exists to answer one distinct question, at one point in the decision, for one primary audience. A brief answers "should we pursue this at all." A PRD answers "what are we building, and why." An RFC answers "how do we solve this specific technical problem." A spec answers "what is actually true about this feature right now."

Teams that skip this distinction tend to make one of two mistakes. They either write PRD-length documents for ideas that haven't earned that investment, burning days of writing and review on something a two-paragraph brief would have killed just as fast. Or they treat a shipped feature's original PRD as permanently accurate, discovering months later that the document and the product describe two different things.

The pattern underneath the table matters more than any single row: document weight should scale with how much is still unknown or contested, not with how important a feature feels. A high-conviction, low-ambiguity feature might only need a thin PRD. A small feature with a genuinely contested technical approach might still deserve a full RFC despite its size.

Brief vs. PRD: The Line Most Teams Blur

A brief precedes a PRD and exists to kill weak ideas cheaply, before a team invests real time. A PRD assumes the idea survived that triage and now needs enough detail for a cross-functional team to build against it with confidence. Collapsing the two either burns PRD-level effort validating ideas that should have died in triage, or ships a brief's thin reasoning as though it were a build-ready contract.

A good brief does three things in under a page: names the problem in the customer's terms, states a testable hypothesis for why solving it matters now, and flags what would have to be true for this to be worth a PRD. Framing the problem through Jobs to Be Done — what job the customer is hiring this for, and what they're firing today — keeps a brief anchored in a real customer need instead of a stakeholder's pet request.

Mapping that same problem against a customer journey is often what separates a brief that's genuinely diagnosing friction at a specific moment in the experience from one that's just a feature request wearing a template.

Where a brief stays deliberately underspecified, a PRD earns its extra length by resolving that ambiguity. It should cover:

1. Problem and goals — restated with more precision than the brief that spawned it.
2. Target user and use case — specific enough that an edge case can be tested against it.
3. Scope, including what's explicitly out of scope — the section most likely to get skipped and most likely to cause rework later.
4. Success metrics — defined before launch, not reverse-engineered from whatever data happens to be easy to pull afterward.
5. Data requirements — often the section that ages worst, since it's written before real schema constraints surface.

If you're unsure how much detail belongs in that data section versus what's engineering's job to define, our guide to writing data requirements inside a PRD walks through where the PM's responsibility ends and the schema begins. For the fuller mechanics of writing a PRD itself — structure, section-by-section guidance, and how AI tools change (and don't change) the job — see our PRD writing masterclass for the AI era.

Signs you wrote the wrong one

A few tells show up reliably when a team picked the wrong document weight for the decision in front of it:

• A brief has scope, success metrics, and edge cases in it. That's PRD content wearing a brief's label — it means the "quick check" quietly turned into a week of work nobody signed up for.
• A PRD gets rewritten twice before a line of code ships. That usually means the underlying idea hadn't survived triage yet and needed a brief first.
• Engineering keeps asking questions the PRD should already answer. Scope or success metrics were probably left vague to avoid a hard conversation, not because they were genuinely undecided.
• Nobody can say who approved the current scope. A sign the document was never actually reviewed — just written and assumed.

RFCs: For Technical Decisions, Not Product Scope

An RFC — request for comments — exists to settle one specific, contestable technical or architectural decision, not to describe a feature's product scope or user experience. It names a problem, proposes one option among several defensible ones, and invites structured disagreement before the decision is locked. That pattern is borrowed directly from the IETF's RFC process, which has shaped how technical organizations write and debate proposals since 1969.

A well-scoped RFC follows a tight shape: context and constraints, the options actually considered (not a strawman list built to justify a foregone conclusion), a recommendation with its tradeoffs stated plainly, and an explicit decision date. Software architect Michael Nygard's widely cited 2011 write-up on Architecture Decision Records popularized a lighter-weight sibling of the same idea: capture why a technical decision was made, not just what was decided, so the reasoning survives the person who wrote it.

RFCs earn their overhead specifically when a decision is both consequential and genuinely contested among competent engineers — not every technical choice needs one. A handful of situations that typically qualify:

• A new service boundary or a change to how systems own data.
• An authentication or authorization approach with real security tradeoffs.
• A database or platform migration with a meaningful rollback cost.
• Any decision where two senior engineers, given the same constraints, would defensibly land on different answers.

A straightforward implementation of an already-agreed PRD usually isn't one of them. Because architectural choices ripple through a system in ways that are easy to underestimate at decision time, it helps to reason in terms of feedback loops and second-order effects rather than just the immediate change — our guide to applying systems thinking to product decisions covers that ripple effect in more depth.

Spec: The Living Document Engineering Actually Builds From

A spec isn't a fifth, separate document — it's what a PRD becomes once a team commits to building it: the same underlying content, but versioned, commentable, and expected to keep changing as engineering discovers real constraints. Treating a PRD as a one-time deliverable, written once and filed away, is exactly how the spec and the shipped product quietly diverge within a single sprint.

Product veteran Marty Cagan has argued for years, through the Silicon Valley Product Group community, that traditional static PRDs fail at precisely this moment. They're written before the hardest problems surface, and then nobody goes back to reconcile the document once engineering, design, and real user feedback change the plan. The PRD isn't wrong when it's written; it's wrong by the time someone opens it during an incident six months later.

Some specs are naturally decision-heavy rather than purely descriptive. A spec that has to explicitly decide how far a feature goes toward matching a competitor versus building something genuinely differentiated is its own kind of document, with its own failure modes — see our breakdown of writing a competitor parity vs. differentiation spec for that specific case.

Where drift actually comes from

Drift rarely happens as one dramatic rewrite. It happens in small increments that each look harmless on their own:

1. An engineer makes a reasonable judgment call mid-build that never makes it into the PRD.
2. Design tweaks a flow during implementation and nobody backports the change to the doc.
3. A scope cut gets decided in a stand-up and lives only in a Slack thread.
4. Support quietly writes their own tribal-knowledge doc because the "official" spec is six months stale.

Compounded over a few sprints, the document and the shipped product describe two different features — which is exactly the gap a living document is built to catch.

This is the specific failure mode Prodinja's Spec Studio is built around. Instead of a static doc that quietly stops matching reality, a spec lives as structured sections with inline comments; changes surface as PR-style diffs you explicitly approve or reject, gated behind readiness checks before an engineering hand-off export goes out. Drift becomes a reviewable change instead of a surprise discovered mid-incident.

A Decision Framework: Match Document Weight to Reversibility

The right document weight tracks how reversible and risky a decision is, not how large the initiative feels on a roadmap. Amazon's well-known one-way-door/two-way-door framing, detailed by former Amazon executives Colin Bryar and Bill Carr in Working Backwards, is a useful proxy: two-way doors — decisions that are cheap to reverse — rarely deserve more than a brief, while one-way doors — decisions that are expensive or impossible to reverse — earn a full PRD, an RFC, or both.

Read this table as a floor, not a ceiling. A team under real deadline pressure can always choose to write less, but reversibility is the honest test for whether that shortcut is actually safe. A pricing change and a button-color test are not the same kind of decision, even when both show up as a single line on the same roadmap.

A fast gut-check before you start writing

Three questions usually settle which document a decision needs, before anyone opens a blank doc:

1. Can we undo this in a day if it's wrong? If yes, a full PRD is probably overkill — write a brief, or just ship it and watch the data.
2. Is there one clearly correct technical approach, or several defensible ones? Several defensible ones is the actual trigger for an RFC — not team size, not feature size.
3. Will this document still need to be accurate three sprints from now? If yes, it needs to live as a spec, not sit as a static file nobody revisits.

Where Documentation Drifts — and How to Prevent It

Documentation drifts when it's treated as a one-time artifact instead of a running record: a decision changes mid-build, nobody updates the source document, and within a sprint the doc and the shipped product describe two different things. The fix isn't more upfront detail — more detail written once just drifts from a higher starting point — it's a lighter-weight habit of capturing changes as they happen.

Three habits catch most drift before it compounds:

• Version, don't overwrite. Keep a visible changelog inside the document itself so a reader can see what changed and why, not just the current state.
• Route changes through review, not Slack. A scope change discussed only in a thread is a change nobody downstream will ever see or be able to challenge.
• Set a readiness gate before hand-off. Engineering shouldn't start building against a document that hasn't been explicitly marked ready — informal "good enough" hand-offs are where the earliest drift usually starts.

None of this requires exotic tooling. A disciplined team can do it in a shared doc with a changelog section and a strict review habit. What dedicated tooling buys back is that discipline surviving deadline pressure — a changelog is usually the first thing to get skipped when a release date is close.

Key Takeaways

• Match document weight to decision risk, not initiative size — a small, contested technical choice can deserve an RFC; a large but obvious feature might only need a thin PRD.
• A brief exists to kill weak ideas cheaply, before a team invests PRD-level time validating something that shouldn't have survived triage.
• A PRD answers what and why — treat sections like data requirements and success metrics as first-class, not afterthoughts filled in at the end.
• An RFC is for genuinely contested technical decisions, not a restatement of product scope — borrow the discipline of naming the options actually considered.
• A spec is a living document, not a PRD's final form — version it, review changes through structured comments, and gate hand-off on explicit readiness.
• Drift compounds in small increments — an unlogged judgment call here, a Slack-only scope cut there — so catch changes as they happen rather than reconciling everything after an incident.