RFC vs PRD vs Living Spec: Who Does What

An RFC settles a contested technical approach at a single point in time; a PRD defines what to build and why before anyone commits code; a living spec carries both — the enduring what-and-why plus the decisions an RFC produced — through the entire build. Use the wrong one and you start the wrong argument in the wrong room.

Quick answer: RFC = debate the how when the technical approach is genuinely contested. PRD = define the what and why before build starts. Living spec = that same what-and-why, kept current and merged with RFC decisions, all the way through ship.

The Core Distinction: Three Documents, Three Questions

Each artifact answers a different question for a different audience. An RFC asks engineers "which technical approach should we take?" A PRD asks stakeholders "what are we building, for whom, and why does it matter?" A living spec asks the whole team, continuously, "what did we actually decide, and does the build still match it?"

Confuse the questions and you get the wrong meeting. Teams debate database indexing strategy inside a PRD review (that's an RFC's job) or argue about market priority inside a technical design doc (that's a PRD's job). Neither group leaves satisfied, because the document in the room wasn't built to answer the question being asked.

Document	Core question	Primary audience	Typical lifespan	Usual owner
`RFC`	Which technical approach should we take?	Engineers, architects, tech leads	Days to a few weeks, until a decision is made	Senior engineer or tech lead
`PRD`	What are we building, for whom, and why?	Cross-functional stakeholders, leadership	Weeks, often frozen at kickoff	Product manager
Living spec	What did we decide, and does the build match it?	Everyone touching the build, ongoing	The life of the project	PM and engineering, jointly

That third row is the one most orgs skip, which is exactly why specs and reality drift apart by week four of a build.

What an RFC Is Actually For

An RFC (Request for Comments) exists to resolve a contested technical decision — schema design, API contract, caching strategy, build-vs-buy — by putting a concrete proposal in front of the engineers accountable for it and forcing disagreement onto the record before code gets written. It is not a place to relitigate scope or priority.

The format traces back to the IETF, which coined "RFC" in 1969 (Steve Crocker's original memo) to let a distributed group of engineers argue out internet protocols in writing rather than in person. The culture that survived — "rough consensus and running code" — is why good RFCs still read like arguments, not announcements. Since then the IETF alone has published more than 9,000 numbered RFCs, and the format's basic shape barely changed.

A strong RFC generally contains:

A narrowly scoped problem — narrow enough that reviewers can actually decide something in one sitting, not a re-litigation of the whole project.
A recommended approach, not just a menu of three options. An RFC with no recommendation invites bikeshedding instead of resolving it.
Alternatives considered, and specifically why each was rejected — this is what makes the eventual decision defensible later.
Blast radius — which services, teams, and data break if this ships, and who needs to sign off.
Open questions the author explicitly can't resolve alone, flagged rather than papered over.

Once the RFC resolves, many eng orgs record the outcome as a permanent, short-form entry — the Architecture Decision Record (ADR) pattern that Michael Nygard formalized in 2011: one page per decision, stating context, decision, and consequences, filed where future engineers will actually find it instead of buried in a closed pull request thread.

When an RFC Is the Right Tool

Reach for one when the technical approach is genuinely contested among engineers arguing in good faith, when the decision is expensive to reverse (a schema, a protocol, a vendor), or when more than one team is affected by the outcome. Skip it when the real disagreement is about priority or scope — that argument belongs in a PRD, not a design doc.

Surveys of engineering practice at large tech organizations — including reporting from Gergely Orosz's The Pragmatic Engineer newsletter on how big tech teams actually ship — consistently find that some form of written design doc or RFC review is standard practice before major technical work starts at most large-scale engineering orgs. The label varies (design doc, tech spec, RFC), but the job is the same: surface disagreement in writing before it becomes a rewrite.

What a PRD Is Actually For

A PRD (Product Requirements Document) exists to establish what problem is worth solving, for whom, and what "done" looks like — before engineering time gets spent debating how. It defends against scope creep and ambiguous acceptance criteria; it is not the artifact that resolves a technical dispute.

The discipline behind a good PRD traces to requirements-engineering writing more broadly — Karl Wiegers' long-standing distinction between business requirements, user requirements, and functional requirements (from his book Software Requirements) still holds up as the backbone of what a PRD should actually separate out, rather than blending "why" and "what" into one undifferentiated wall of prose.

A working PRD usually covers:

The problem statement and the job the user is hiring the product to do
The target user or segment, specific enough to exclude someone
Success metrics — what changes if this ships, and how you'll know
Scope and explicit non-goals, which prevent the slow scope creep that kills timelines
Acceptance criteria precise enough that "done" isn't a debate at handoff

Where PRDs consistently fail is staleness. Marty Cagan and the Silicon Valley Product Group have argued for years that a heavyweight PRD, written once and frozen at kickoff, is a poor substitute for continuous discovery — requirements get clarified through prototyping and testing, not settled in advance by a single document. The failure mode isn't the PRD itself; it's treating it as a plaque instead of a draft.

A PRD that never changes after kickoff isn't stable — it's just wrong for longer.

Where the Living Spec Picks Up

A living spec isn't a fourth category competing with RFC and PRD — it's the PRD's requirements kept current, merged with whatever decisions an RFC produces, so that six weeks into a build the document in front of the team still matches what's actually shipping. Our complete guide to living specs covers the format in full; the short version is that it treats a spec as a living artifact, not a milestone deliverable.

Two mechanics make that possible in practice. First, section-level maturity tracks which parts of the document are still draft, which are decided, and which have actually been built — so "is this spec done?" becomes a per-section question instead of an all-or-nothing one. Second, PR-style spec diffs let reviewers see exactly what changed and why, the same way engineers review a code change, instead of re-reading the whole document hunting for what's different.

That second mechanic is precisely how a living spec absorbs an RFC's output. When the RFC resolves — say, engineering picks event sourcing over a simple CRUD model — that decision doesn't stay trapped in a closed design-doc thread. It becomes a diff against the living spec's technical section: what changed, why, and what it implies for the requirements the PRD originally set. Even Malte Ubl's widely read essay on design-doc culture at Google notes that a design doc's job effectively ends once its decisions are made — the ongoing source of truth has to live somewhere else. A living spec is that somewhere else.

Decision Table: Which Document to Reach For

Reach for an RFC when engineers disagree about implementation and the cost of being wrong is high. Reach for a PRD when the risk is in requirements — you genuinely don't yet know what "done" means. Reach for a living spec whenever a project runs long enough that decisions will keep landing after kickoff, which is most real projects.

Scenario	Where the real risk sits	Document to write
Two senior engineers disagree on sync vs. async architecture	Technical (the how)	RFC
Sales hears customers want X; support hears they want Y	Requirements (the what)	PRD
Migrating a datastore with many downstream consumers	Technical, high blast radius	RFC, then an ADR of the outcome
A feature spanning several sprints with shifting stakeholder input	Requirements drifting over time	Living spec
A narrow, one-week API contract dispute between two backend engineers	Technical, narrow scope	RFC
A multi-quarter platform overhaul, both architecture and scope evolving	Both, simultaneously	PRD to start, living spec absorbing RFC decisions as it runs

In practice, mature teams run these in parallel rather than in strict sequence. The PRD justifies why the project exists; an RFC resolves whichever technical fork the project surfaces along the way. Judging when each phase of a project is actually ready to start versus ready to ship depends on knowing which of these two questions — requirements or approach — is still genuinely open.

Common Failure Patterns Behind the Confusion

Most teams don't fail because they're missing a document type — they fail because they use the right document for the wrong job, or let it go stale the moment the room stops agreeing. Four patterns account for nearly all of it, and each one is a symptom of a document answering a question it was never built to answer.

The RFC-as-PRD. No PRD exists yet, so engineers write a "technical RFC" that quietly also has to justify the business case. Reviewers end up arguing about market fit inside a document meant to settle a schema decision, and neither question gets a clean answer.
The PRD-as-contract. A PM writes an exhaustive PRD, "freezes" it at kickoff, and treats every later change request as scope creep to resist rather than a requirement being discovered. Amazon's PR/FAQ process — the internal "working backwards" practice popularized by early Amazon product leaders — instead revises its draft press release and FAQ repeatedly before a line of code is written, precisely to avoid this freeze.
Dueling RFCs, no referee. Two engineers write competing RFCs for the same problem because no PRD exists to establish which business outcome actually matters, so the debate has no way to resolve on merit — it resolves on seniority or stamina instead.
The living spec that isn't living. A team calls a wiki page a "living spec" but nobody prunes it, so it becomes a historical record instead of a current one — the exact failure a living spec exists to prevent, recreated under a different name because section-level maturity and diff-based review were never actually enforced.

Each pattern has the same fix: name which question is actually open — the how or the what — and route it to the document built to answer it.

How the Three Documents Hand Off in a Real Build

In a healthy workflow, discovery informs the PRD, the PRD triggers an RFC only where the technical approach is actually contested, and the living spec absorbs both outputs so the team never has to reconstruct "why did we build it this way" from Slack archaeology.

A typical sequence looks like this:

Discovery surfaces the job to be done. Framing the problem through Jobs to Be Done and mapping the customer journey reveals what's actually broken for the user, before anyone writes a requirement.
The PM drafts the PRD — problem, target user, success metric, scope, non-goals.
If engineering flags a contested technical approach, an RFC spins up alongside the PRD, scoped to that one decision, not the whole project.
The RFC's outcome gets folded into the living spec's technical section — the chosen approach, the alternatives rejected, and why — rather than left to live only in a closed thread nobody revisits.
The living spec carries both documents' conclusions forward through diff-based review and readiness gates, so the shipped feature and the document describing it don't quietly diverge.

The failure pattern this prevents is familiar to anyone who has inherited a project: the PRD says one thing, the RFC decided something else three weeks later, and the actual shipped code reflects a third, undocumented compromise made in a stand-up. None of the three documents were wrong individually — nothing was carrying the merge.

Where Prodinja Fits

This is the specific job Prodinja's Spec Studio is designed around: a living PRD meant to hold the enduring what-and-why through build, with section-level readiness and PR-style diffs so it can absorb decisions as they land — complementing an engineering RFC that settles the how at a point in time, not replacing it. The RFC still does the technical debate; the living spec is designed to be where that debate's outcome goes to stay findable.

Key Takeaways

An RFC resolves a contested technical approach; it's scoped narrowly, owned by engineering, and mostly finished once the decision lands.
A PRD defines what to build, for whom, and why; its biggest risk is staleness once a heavyweight version gets frozen at kickoff.
A living spec isn't a competing document — it's the PRD's requirements kept current, merged with whatever an RFC decides, through the whole build.
Match the document to the actual risk: technical disagreement needs an RFC; unclear requirements need a PRD or living spec; both need both, run in parallel.
Section-level maturity and PR-style diffs are what let a living spec absorb decisions without becoming a wall of stale prose nobody re-reads.
The failure mode isn't having three documents — it's having none of them actually talk to each other once a decision lands mid-build.

Frequently Asked Questions

Is a living spec just a PRD that never gets closed?

Not quite — a living spec keeps the PRD's what-and-why alive, but it also actively absorbs technical decisions from RFCs and reflects build status section by section. A PRD that's merely "not closed" is just stale; a living spec is designed to be actively updated as a matter of process.

What's the difference between an RFC and a design doc?

In practice, very little — most teams use "RFC" and "design doc" interchangeably to mean a written technical proposal that invites structured dissent before code gets written. Some orgs reserve "RFC" for changes crossing team boundaries and "design doc" for single-team decisions, but the core job — resolving a contested how — is identical either way.

Do technical PMs need to write RFCs themselves?

Usually no — the RFC is an engineering-owned artifact because it resolves an engineering question, but a strong technical PM reads every RFC that touches their PRD's scope and makes sure its outcome gets reflected back into the spec. Writing one yourself is rare unless you're deeply hands-on technically.

What happens to the RFC after the decision is made?

It's typically archived or closed once consensus is reached, sometimes distilled into a short-form ADR for future reference. Its conclusion should get folded into the living spec's technical section — leaving the RFC as the historical record of why, and the living spec as the current record of what's true now.

How many documents does one project actually need?

It depends on where the risk sits: a project with settled requirements but a contested build approach needs only an RFC; one with unclear requirements but an obvious technical path needs only a PRD or living spec. Most non-trivial, multi-sprint projects end up needing both, run in parallel rather than sequentially.

Can a living spec replace engineering RFCs entirely?

No — a living spec is designed to hold and absorb decisions, not to be the forum where a contested technical debate actually gets argued out. Engineers still need a dedicated space, like an RFC, to hash out competing approaches before the living spec records what was decided.