PRD vs RFC
When to write a Product Requirements Doc vs an engineering Request for Comments.
Why
PRDs and RFCs solve different problems and using the wrong one wastes everyone's time. A PRD answers 'what should we build and why for the user?' — it's product-owned and user-outcome-focused. An RFC answers 'how should we build this technically?' — it's engineering-owned and architecture-focused. Writing an RFC for a product question produces a technical doc that ignores user value; writing a PRD for a technical question produces a spec that prescribes implementation the PM shouldn't own. Knowing which to reach for prevents the common failure of PMs writing technical PRDs and engineers writing product-y RFCs.
When
PRD when the question is about user value/behavior; RFC when the question is about architecture/implementation. Takes 10 min to decide which. Use both in sequence for big features.
How
1. Ask: "Is the unknown about WHAT users need or HOW to build it?" - WHAT → PRD (product owns, user outcome) - HOW → RFC (engineering owns, technical design) 2. For large features, use both in sequence: a. PRD first — defines what and why; gets stakeholder sign-off b. RFC second — proposes technical approach to meet the PRD; gets eng sign-off c. ADR captures the RFC's accepted decision 3. Keep them separate documents that link to each other - PRD should NOT prescribe "use Kafka"; RFC should NOT define "signup conversion target" 4. The PRD is the input to the RFC, not the other way around
Example
Feature: real-time collaboration on release notes PRD (product-owned): - Problem: two PMs edit the same release notes, last-save-wins loses work - Requirement: concurrent edits merge without data loss - Metric: zero "where did my edit go" support tickets RFC (engineering-owned, links to PRD): - Proposes: CRDT-based editor (Yjs) vs OT (ShareDB) vs last-write-wins + diff - Trade-offs: Yjs (complex, no server auth) vs ShareDB (needs server, simpler) - Recommends: ShareDB — fits our auth model, team has OT experience ADR-0015: Adopt ShareDB for collaborative editing (links PRD + RFC)
Common Problems
- ⚠Writing one mega-doc that mixes product and technical concerns — it's too long for anyone to read and ownership is unclear.
Best Practices
- ✓Link the PRD and RFC bidirectionally so a reader can follow the chain from user problem to technical decision.
- ✓Time-box the RFC review to 1 week; RFCs that linger for a month lose momentum and the technical context changes under them.