Craft
PRD vs RFC vs Design Doc: Who Writes Which, and When
A PRD, an RFC and a design doc answer three different questions. Who writes each, the order they come in, and how to stop them restating each other.
Three documents, often written about the same feature within a few weeks of each other, by people who sit next to each other. They overlap enough that teams either merge them into one bloated spec, or write all three and let them contradict each other.
The cleaner way to hold them apart is by the question each one answers. The PRD answers what must be true. The RFC answers which way to go. The design doc answers how it will be built. Different authors, different readers, a natural order, and one rule that keeps them from drifting: each document links to the one before it instead of restating it.
This post covers the engineering side of the document family. If your question is about the business-side documents, PRD vs MRD vs BRD vs SRD covers those.
The three questions
| PRD | RFC | Design doc | |
|---|---|---|---|
| Question | What must be true for this to be right? | Which approach should we take, and what is wrong with it? | How exactly will we build the chosen approach? |
| Usually written by | Product manager | An engineer proposing a change | The engineer or tech lead who will build it |
| Main reader | Everyone who builds, tests or supports it | Engineers outside the team who might object | The team building it, and its reviewers |
| Posture | Specifies outcomes | Argues for an option | Plans the implementation |
| Done when | An engineer could build it without you | A decision is recorded | Someone could start coding from it |
| Typical failure | Prescribes the implementation | Reopens the requirements | Restates the PRD, then drifts from it |
Read across the question row and the boundaries mostly draw themselves. The PRD does not care whether exports run on a queue. The RFC does not get to decide that export links expire after seven days. The design doc does not get to decide whether exports should exist.
The PRD: what must be true
The product manager owns it, though owning it is not the same as writing every section. It states the problem, who has it, the scope and the exclusions, the states, the limits, and the criteria that decide whether the build is correct.
Its boundary on the technical side is observable behaviour. Anything a user or a consuming system could notice is a PRD decision; anything they could not is not. Writing a technical PRD works through that line in detail, including the cases where it looks blurry.
The RFC: which way, and what is wrong with it
The name is older than most software teams. The RFC series that documents the internet's protocols began in April 1969, and its own fiftieth-anniversary retrospective describes the early notes as requests for comments on ideas and proposals, meant to start conversations rather than to record a standard.
That posture is still the useful part. An internal RFC proposes a technical direction, lays out the alternatives, and asks people to find the problem before the work starts. Its readers are often outside the team: the owners of systems it touches, the people who will operate it, anyone whose earlier decision it would reverse.
An RFC earns its place when the approach is contested, expensive to reverse, or crosses team boundaries: a new datastore, a change to a shared service, a migration. When none of those holds, it is ceremony. The team picks an approach and writes it down in the design doc.
What an RFC should not do is reopen the requirements. If writing it surfaces a product question, such as whether a daily export would do instead of a real-time one at half the cost, that question goes back to the PRD owner as a proposed change. It does not go into the RFC as an assumption.
The design doc: how it will be built
Once the direction is settled, the design doc plans the implementation: components, data model, interfaces between services, failure handling, how it will be tested, how it will be rolled out and rolled back. It is what a reviewer reads to decide whether the plan is sound, and what a new engineer reads a year later to understand why the code is shaped the way it is.
Two terms tend to get attached here, and both cause confusion. ERD means different things depending on who says it: usually an entity-relationship diagram, which is a picture of the data model and belongs inside the design doc, and sometimes an engineering requirements document, which covers roughly what a design doc or SRD would. Neither replaces the PRD. "Product design document" sometimes means the PRD and sometimes means the designer's flows and screens. If your team uses the phrase, agree which one it is before anyone writes one.
The order they come in
The normal sequence is PRD, then RFC if one is needed, then design doc. Design work on flows and screens runs alongside the RFC, because both start from the same requirements.
It is not a strict waterfall. Two loops are normal and healthy:
Feasibility before the PRD settles. If nobody knows whether the thing is buildable at all, an engineer spikes it first. The finding goes into the PRD as a constraint, not into a separate document nobody on the product side will read.
Constraints discovered in the design doc. Planning the build regularly surfaces a limit the PRD did not anticipate: a rate cap on a vendor API, a data model that cannot express the permission rule. That is a mid-build change to the spec, and it belongs in the PRD the same day with a visible note, because the people reading the PRD will never read the design doc.
The order matters because each document's question depends on the answer above it. An RFC written before the requirements are settled argues about options for a problem nobody has framed. A design doc written before the approach is chosen is an RFC in disguise, and gets reviewed as one, slowly.
One requirement, three documents
An illustration. Say you are adding scheduled exports for workspace admins.
PRD (§3, R3.2) An admin can schedule a weekly export. The file is delivered
as a download link by email. Links expire after 7 days.
RFC Run scheduled exports on the existing job queue, or build a
scheduler service? Recommend the queue: no new infrastructure,
low volume. Objections by 24 Oct.
Design doc Schedules stored in export_schedules; a nightly job enqueues
due exports. Expiry enforced by a signed URL with a 7-day
lifetime (see PRD R3.2). Retries: 3, then notify the admin.
The design doc cites R3.2 for the seven days rather than restating where the number came from. If the PRD later moves the expiry to 30 days, the design doc's reference is still correct, and only one place holds the number.
Keeping them from overlapping
The rule from where a PRD should live, one canonical location per document and linked from everywhere else, applies across documents as well as within one.
Each document links upward. The RFC and the design doc link to the PRD and cite requirements by section or ID. They summarise in a sentence at most.
Each decision lives in one place. The expiry is a product decision, so it lives in the PRD. The signed URL is an engineering decision, so it lives in the design doc. When a decision is written in both, the copies drift, and nobody can tell from the outside which one is current.
Status at the top of each. A reader who lands on a design doc from search should see in the first line whether it is a proposal, accepted, or replaced by something newer.
When you need fewer than three
Most work does not need all three. A change with no contested technical choice skips the RFC. A small change whose build plan fits in a ticket skips the design doc. A chore or a bug with no product decisions in it skips the PRD.
The combination worth avoiding is the design doc with no PRD above it. It produces a well-planned build of whatever the engineer inferred the requirements to be, and the inference is invisible, because it is written as though it were settled. If the feature is an API or an integration, the Technical / API PRD template is shaped for the PRD half, so the design doc has something to cite.
FAQ
What is the difference between a PRD and an RFC? The PRD says what must be true; the RFC proposes how to get there and asks for objections.
Is a design doc the same as an RFC? No. The RFC argues for a direction; the design doc plans the build once it is chosen.
In what order are a PRD, RFC and design doc written? PRD, then an RFC if the approach is contested, then the design doc. Late constraints go back into the PRD.
What is the difference between a PRD and an ERD? An ERD describes the data model or the engineering side. It sits below the PRD, not in place of it.