Product Requirements Document (PRD)
Define product requirements, user needs, and success metrics with PRDs
Product Requirements Document (PRD)
PRDs are product-oriented documents that describe what is being built and why, written primarily by technical product managers to align engineering, design, and leadership before a feature is built.
What is a PRD?
A Product Requirements Document is a document that:
- Defines the product or feature being built
- Articulates the user problem and target persona
- Specifies functional and non-functional requirements
- Captures success metrics so the team knows when it's working
- Frames scope, milestones, and open questions
PRDs sit "above" engineering documents like Design Docs and ADRs — a single PRD often spawns one or more Design Docs and ADRs that describe how to build what the PRD calls for.
When to Write a PRD
Write a PRD when:
- ✅ Kicking off a new product, feature, or major initiative
- ✅ The work spans multiple teams (eng, design, data, GTM)
- ✅ Requirements need stakeholder sign-off before engineering invests
- ✅ Success needs to be measured against explicit metrics
- ✅ User-facing behavior, scope, or KPIs are likely to be debated
Skip a PRD (or use a lighter doc) when:
- ❌ The work is purely an internal technical decision → use an ADR
- ❌ You're proposing a process or standard change → use an RFC
- ❌ You already have a PRD and just need the implementation plan → use a Design Doc
PRD Structure
A solid PRD includes:
Title & Metadata
- Product or feature name
- Author (PM) and reviewers (eng lead, design lead, etc.)
- Status and target release
Overview
A one-paragraph summary of what's being built and why it matters.
Problem Statement
Describe the user or business problem. Quantify the pain where possible (support tickets, lost revenue, time spent, etc.).
Goals & Non-Goals
- Goals: outcomes you commit to achieving
- Non-goals: explicitly out of scope so reviewers can't expand the surface area mid-flight
Target Users & Personas
Which user segments are affected and what their key jobs-to-be-done are.
User Stories
Concrete As a … I want … so that … statements that drive acceptance.
Requirements
- Functional requirements: capabilities the product must have
- Non-functional requirements: performance, accessibility, security, compliance, etc.
Success Metrics
How will we know this worked? Each metric should be measurable and tied to either a leading or lagging indicator.
Scope & Milestones
Phased delivery plan, dependencies, and target dates.
Open Questions
Decisions that are unresolved. Linking the relevant Design Doc, RFC, or ADR is encouraged once those exist (use the Linked Documents panel on the document page).
Appendix
Mockups, research links, competitive analysis, related documents.
Example PRD Skeleton
# PRD: Real-time Collaboration in the Document Editor
**Author**: Jane PM
**Reviewers**: John (Eng Lead), Sarah (Design)
**Status**: In Progress
**Target Release**: Q3
## Overview
Allow multiple teammates to edit the same document at the same time
so technical specs no longer get blocked on a single editor.
## Problem Statement
Today only one user can edit a document at a time, leading to merge
conflicts and a 32% drop-off when teammates need to review live.
## Goals
- Multiple teammates can edit the same document concurrently
- Presence and cursor indicators are visible to all editors
## Non-Goals
- Offline editing
- Mobile collaboration UX
## Target Users
Engineering teams that co-author RFCs and Design Docs.
## User Stories
- As an engineer, I want to see who else is in the doc so I don't
overwrite their changes.
- As a reviewer, I want my cursor visible so authors know where I'm
reading.
## Requirements
### Functional
- Two or more users can edit simultaneously
- Avatars of active editors render in the document header
### Non-Functional
- < 200 ms perceived latency for remote edits
- All collaboration traffic encrypted in transit
## Success Metrics
- ≥ 40% of multi-author documents see ≥ 2 concurrent editors per week
- 0 reports of lost edits in the first 30 days post-launch
## Scope & Milestones
- Phase 1: Presence + cursor indicators (Sprint 1-2)
- Phase 2: Concurrent edits via CRDT (Sprint 3-4)
- Phase 3: GA + telemetry (Sprint 5)
## Open Questions
- Should we surface a per-user "view-only" mode?
- How do we price this on the Free tier?Best Practices
Anchor Every Requirement to a User Outcome
Avoid feature lists with no "so that …". If you can't tie it to a user or business outcome, cut it or move it to the appendix.
Make Success Measurable
Vague metrics ("users will love it") let teams declare victory without evidence. Pick metrics with explicit thresholds.
Keep Engineering Detail Out
A PRD describes what and why. Push how down into a Design Doc or ADR. Use the Linked Documents panel on the document page to keep the trail navigable.
Get Sign-off Before Build
Use the sign-off workflow to record explicit approval from engineering, design, and leadership before kickoff.
Treat It as Living
Update the PRD as scope shifts. The version history makes it safe to evolve in place rather than spinning up a v2 doc.
Creating a PRD in ArchDoc
- Navigate to Dashboard > Documents
- Click New Document
- Select Product Requirements Document (PRD) as the document type
- Enter a descriptive title (e.g. "PRD: Real-time Collaboration")
- Fill in the pre-populated PRD template
- Use the Linked Documents panel on the document page to attach related Design Docs, RFCs, and ADRs as they appear
- Request sign-offs from engineering, design, and leadership
- Update throughout discovery and delivery