PRD vs Spec vs RFC: Which Doc Do You Need?

A PRD (product requirements document) says what to build and why, for the people deciding and paying. A spec says exactly how the thing will behave, for the people building and testing it. An RFC (request for comments) proposes a change and invites objections before anyone commits. Most small teams need a PRD for every product, a spec for anything with edge cases, and an RFC only when a decision is hard to reverse.

That is the short answer. The longer one is about audiences, timing, and a change that arrived in the last two years: the first reader of these documents is often now an AI agent, and that shifts what a good one looks like.

The three documents side by side

	PRD	Spec	RFC
Answers	What are we building, for whom, and why?	How exactly does it behave?	Should we make this change at all?
Written by	Product owner, founder, PM	Engineer or designer closest to the work	Whoever proposes the change
Read by	Founders, clients, engineers, marketing	Engineers, QA, the agent writing code	Everyone affected, before a decision
Lives	For the life of the product	For the life of the feature	Until the decision is made, then archived
Length	2 to 6 pages	As long as the behaviour needs	1 to 3 pages plus comments
Changes	Through a baseline and change notes	Freely, until the feature ships	Rarely; a new RFC supersedes it
Fails when	It lists features without a problem	It describes intent instead of behaviour	It is written after the decision

The rows that matter most are the first and the last. Each document answers one question, and each has a characteristic way of going wrong.

What a PRD is for

A product requirements document exists so that everyone who touches the product agrees on the problem and the boundaries before anyone opens an editor. The glossary entry on PRDs covers the full anatomy; the parts that earn their place are:

The problem in one paragraph, with who has it and how you know.
Goals and non-goals. Non-goals are the more useful half. "We will not support offline editing in v1" prevents a month of argument.
Numbered requirements with a stable identifier (REQ-007), a priority, and acceptance criteria you could hand to a tester.
Open questions that are still open, dated.

A PRD is the document a client signs off on and the one a requirements audit later checks the build against. For that to work, it needs identifiers that do not change and a frozen copy at sign-off. A PRD that is rewritten in place every week cannot be audited against, because nobody can say what was agreed.

What a PRD is not: a list of screens, a database schema, or a technical design. The moment it says "store this in a JSONB column", it has become a spec wearing the wrong hat.

If you write one from scratch, the PRD template has the sections in this order, and the earlier post on writing a PRD with AI walks through filling it in.

What a spec is for

A spec (functional spec, technical spec, design doc; the names blur) translates a requirement into behaviour precise enough to build and test. Where the PRD says "customers can export their data", the spec says which formats, what the file is named, what happens to attachments over 25 MB, whether the export runs in the background, and what the person sees while it does.

A good spec has a different shape from a PRD:

One requirement or feature per spec. Specs that cover the whole product are PRDs with too much detail.
States and transitions, not prose. A table of "when the user does X in state Y, Z happens" catches more bugs than paragraphs do.
Edge cases listed explicitly: empty, maximum, concurrent, offline, permission denied.
Interfaces: the API shape, the event names, the fields and their types.
What is out of scope for this version, so nobody builds it by accident.

Specs are allowed to change often, right up to the moment the feature ships. They are a working document for the people building, so version history matters more than sign-off. In a team of five, the spec is often a page under the project with the PRD, edited by the engineer as they go, with the PM commenting rather than rewriting.

The distinction between a product spec and a technical spec is mostly about who writes the edge cases. A product spec lists what the person sees in every state; a technical spec lists how the system gets there. Small teams usually merge them into one document with two sections, and that is fine.

What an RFC is for

An RFC proposes a change that is expensive to undo and asks the people affected to object now rather than later. Examples from running a small company on these tools: switching from per-project to workspace-wide permissions, moving billing from one provider to another, adopting a monorepo, or dropping a language from the marketing site.

The form is simple and has been stable since the 1960s, when the first internet RFCs were literally memos asking for comments:

Context: what is true today and why it is a problem.
Proposal: the change, concretely.
Alternatives considered, with the reason each was rejected. This section is what separates an RFC from an announcement.
Consequences: what gets harder, not just what gets easier.
Open period: a date by which comments are due, and who decides.

An RFC is read by more people than will ever act on it. It is the one document of the three that is finished when the comments stop, not when the code ships. Once decided, it should be marked accepted or rejected and left alone; a later change gets its own RFC that references the first. Some teams call these decision records or ADRs; the mechanics are the same.

The classic failure is the RFC written after the decision, to give it a paper trail. People can tell, and they stop commenting on the next one.

Which document do you need right now?

Work through these questions in order.

Is there a product or a feature that does not exist yet, and more than one person needs to agree on what it is? Write a PRD. If it is a feature inside an existing product, add it to the product's PRD as a new numbered requirement rather than starting a separate document.
Is there a requirement with more than two or three edge cases, or an interface someone else will build against? Write a spec for that requirement. Link it from the requirement.
Is there a change that touches more than one team, costs more than a week, or is hard to reverse? Write an RFC and give it a closing date.
Is it none of these? Write an issue with acceptance criteria and skip the document. A two-day task does not need a PRD.

A team of six building a client product will typically have one PRD, three to ten specs over the life of the project, and one or two RFCs a year. If you have more RFCs than specs, you are debating more than building.

The 2026 twist: agents read these documents first

Two years ago, the first reader of a spec was a developer. Today it is often a coding agent, a planning agent inside your workspace, or an assistant connected over MCP. That changes what a good document looks like in a few practical ways.

Structure beats prose. An agent given a PRD with numbered requirements and acceptance criteria can plan issues against them and report coverage. Given four pages of narrative, it will summarise them and lose the boundaries. Headings, identifiers and tables are no longer style preferences; they are the interface.

Non-goals are read literally. A human skims "we are not doing offline in v1" and remembers it. An agent planning work will respect it only if it is in the document it was given. State the non-goals in the PRD, not in a chat thread.

The baseline matters more. When an agent writes requirements and another agent plans issues from them, drift becomes easy: a requirement is softened in one pass and nobody notices. Freezing the PRD at sign-off and comparing later versions against it is how you catch that. In Atrix, the agent's Develop run writes a requirements document from a brief, the requirements can be frozen as a baseline, and a requirements audit shows coverage and drift against that baseline. It does not scan code; it compares records.

Specs become the test plan. If the spec is a table of states and expected behaviour, a coding agent can turn each row into a test. If it is intent in paragraphs, it cannot.

RFCs stay human. The decision in an RFC is a judgement about trade-offs the organisation is willing to make. An agent can draft the alternatives section well and summarise comments. It should not be the one deciding.

Keeping the three in one place

Where the documents live matters more than it used to, because an agent can only read what it can reach. A PRD in a Google Doc, a spec in a wiki and an RFC in a pull request description means three permissions, three search boxes and no links between them.

What has worked for us: a page tree per product. The PRD is the top page, each spec is a child page linked from its requirement, and RFCs sit in a workspace-level folder with a status in the title. Roadmap items link back to requirements, so when a roadmap item slips, the requirement it serves is one click away. The product roadmap template is built on that link.

Atrix is one way to get this, with pages that nest under a project, live co-editing, version history and Markdown export; its MCP server also lets an outside assistant read the same pages. Notion and Confluence do the nesting and history too. The property that matters is that all three documents are addressable by the same tool, with the same permissions.

FAQ

What is the difference between a PRD and a spec?

A PRD says what to build and why, at the level of numbered requirements with acceptance criteria. A spec says how one of those requirements behaves in every state, precisely enough to build and test. The PRD is signed off and then frozen; the spec changes until the feature ships.

Is an RFC the same as a design doc?

Not quite. A design doc explains how something will be built; an RFC asks whether a change should be made and invites objections before a decision. Many design docs include an RFC-style "alternatives considered" section, and some teams use the names interchangeably, but the RFC's defining feature is the comment period and the decision at the end.

Do startups need PRDs?

A team of two building its first version can get by with a one-page problem statement and a list of issues. From the first time a client, investor or new hire needs to know what was agreed, a PRD with numbered requirements pays for itself. The trigger is more than one person needing to agree, not company size.

Who writes the spec, the PM or the engineer?

Usually the engineer or designer closest to the work, with the PM reviewing. The PRD is the PM's document; the spec is the builder's. In a team without a PM, the founder writes the PRD and whoever builds the feature writes the spec.

Should a PRD contain technical details?

No. Architecture, schemas and API shapes belong in a spec or a technical design. A PRD that specifies implementation locks in decisions the builders should make, and it goes stale the first time an engineer picks a different approach.

Can an AI agent write these documents?

It can draft all three, and it drafts PRDs and specs well when given a clear brief and the existing pages as context. The parts to keep human are the problem statement in the PRD, the decision in an RFC, and the sign-off that turns requirements into a baseline.

Next step

If you are starting a product, write the PRD first; the PRD template is a Markdown page with the sections above in order. Once the requirements exist, the product roadmap template links each roadmap item back to the requirement it serves, which is the link an audit later depends on. For how the documents work inside a workspace with an agent, see docs and whiteboards and the AI agent page.

PRD vs spec vs RFC: three documents, three audiences, and which one to write first