Product Requirements Document (PRD)
A short document that defines what you’re building, who it’s for, what “done” looks like, and what’s explicitly out of scope — written before any code exists.
What is a PRD?
A PRD is a contract with yourself (and your team, and your AI agent) about what you’re building and why. It’s not a technical document — it describes the problem and the desired outcome in language a non-engineer would understand. It does NOT specify how to build it. That’s the job of a technical-specification.
Most software projects fail not because of bad code, but because of unclear intent. The PRD is the first line of defence against building the wrong thing.
A good PRD is short — 2 to 4 pages. If it’s longer, it’s trying to be a spec. If it’s shorter, it’s probably missing something important.
In plain terms
A PRD is like a project brief for a builder. Before constructing a house, you write down: who will live there, how many rooms, what’s the budget, and — critically — what you’re NOT building (no swimming pool, no third floor). The builder doesn’t need to decide where the plumbing goes yet. That comes later. First, everyone agrees on what “done” looks like.
At a glance
The document chain — where the PRD fits (click to expand)
graph TD A["Rough idea"] --> B["PRD"] B --> C["Technical Spec"] C --> D["Implementation Plan"] D --> E["Tasks"] E --> F["Code"] style B fill:#4a9ede,color:#fffThe PRD is the second step. It takes a rough idea and turns it into a clear, bounded description of what to build. Everything downstream (spec, plan, tasks, code) traces back to the PRD.
How does a PRD work?
A PRD has seven core sections. Each one answers a specific question that, if left unanswered, will cause problems later.
1. Problem statement
What pain exists? Describe the problem you’re solving in plain language. Not the solution — the problem. This keeps you honest about why the project exists.
Example
“Small nonprofit organisations waste 30-40% of staff time on administrative tasks that could be automated, but lack the technical skills or budget to adopt existing tools.”
2. Target users
Who specifically? Not “everyone.” Not “users.” Name the people and describe their situation, skills, and constraints.
Example
“Nonprofit staff members (5-20 person organisations) with no dedicated IT person. Varying digital literacy. Using scattered tools (Google Docs, WhatsApp, spreadsheets). Budget under CHF 500/month for tools.”
3. Success metrics
How do we know it works? Define measurable outcomes — not activities (“we shipped features”) but results (“users can do X”).
Think of it like...
A doctor doesn’t measure success by “number of prescriptions written.” They measure “did the patient get better?” Your metrics should measure the outcome, not the output.
Example
- “A user can find any federal instrument in their language within 3 clicks”
- “80% of test users can explain what a petition requires after reading the instrument page”
4. Core user flows
What does the user actually do? Walk through the main journeys step by step. This exposes assumptions and reveals what needs to be built.
Example
“User opens the site → selects their language → browses instruments by level → selects ‘Petition’ → reads the requirements, timeline, and process steps → follows the action guide”
Concept to explore
See user-stories for how to formalise user flows into testable stories with acceptance criteria.
5. Scope — must-haves
What’s in this version? List only what must ship for the product to be useful. Be ruthless. Every item here is a commitment.
6. Out of scope
What’s explicitly NOT in this version? This is the most valuable section in the entire PRD. It prevents scope creep before it starts. If something isn’t listed as in-scope or out-of-scope, it’s ambiguous — and ambiguity is where projects go wrong.
Why "Out of Scope" matters
Without this section, every conversation becomes “should we also add…?” With it, the answer is clear: “That’s out of scope for this version. We can revisit in the next PRD.”
For AI-assisted development, this is critical. Without boundaries, an AI agent will happily build features you didn’t ask for, adding complexity and technical debt.
7. Constraints
What’s non-negotiable? Requirements that constrain every decision — technical, legal, ethical, or practical.
Example
- “Anonymous — no user accounts, no tracking”
- “Data must stay in Switzerland”
- “Must work on mobile devices”
- “Must support 4 languages from day one”
Why do we use PRDs?
Four problems a PRD solves
1. Building the wrong thing. Without a PRD, you build what feels right in the moment. With one, you build what was agreed.
2. Scope creep. Features expand silently. The “Out of Scope” section is the brake pedal.
3. Misaligned expectations. You think “done” means X, your collaborator (or AI agent) thinks “done” means Y. The PRD aligns everyone before work starts.
4. Wasted iteration. Without a PRD, AI agents guess at requirements and you spend cycles correcting them. With a PRD, the agent has a reference point. GitHub’s Spec Kit team: “Write a 1-page PRD before you vibe code anything.”
When do we use PRDs?
- When starting a new project or a new major phase of a project
- When the scope is unclear or ambitious and needs bounding
- When working with AI coding agents that need a reference for what “done” looks like
- When multiple people (or multiple sessions) will contribute to the same project
- Before writing a technical-specification — the PRD informs the spec
Rule of thumb
If you can describe the entire task in one sentence and finish it in one session, you don’t need a PRD. For anything bigger, write one — even if it’s just half a page.
How can I think about PRDs?
The travel itinerary
A PRD is like a travel itinerary before a trip.
- Problem: “We need a holiday” (why are we doing this?)
- Target users: “Family of four, kids aged 8 and 12”
- Success metrics: “Everyone has fun, budget stays under CHF 3,000”
- Core flow: “Fly to Barcelona → 3 nights hotel → beach + city → fly home”
- Scope: “Barcelona only. Beach, Sagrada Familia, local food”
- Out of scope: “Not visiting Madrid. Not renting a car. Not doing a road trip”
- Constraints: “Must fly direct. Hotel must have pool. No more than 5 days”
Without the itinerary, day 2 becomes “should we also visit Madrid?” and the budget doubles. The “out of scope” section is what keeps the trip on track.
The recipe card
A PRD is like choosing a recipe before cooking.
- You decide what dish to make (problem + goal)
- You check who’s eating and their dietary needs (target users)
- You define “done” (a dish that tastes good and feeds four)
- You list the ingredients and steps at a high level (scope)
- You explicitly decide what you’re NOT making (no dessert tonight)
- You note constraints (vegetarian, ready by 7pm, using what’s in the fridge)
The recipe card doesn’t tell you the exact temperature for the oven — that’s the technical-specification. It tells you what you’re cooking and why.
PRD vs Technical Specification
This distinction trips people up, so it’s worth its own section.
| PRD | Technical Specification | |
|---|---|---|
| Answers | What and why? | How exactly? |
| Language | Plain language, non-technical | Precise: inputs, outputs, error cases |
| Audience | You, stakeholders, anyone | You + the AI agent / developer |
| Example | ”Users can browse instruments" | "GET /api/instruments returns JSON array, sorted by name, paginated at 20” |
| Changes | Rarely (goals are stable) | Often (implementation details evolve) |
| Length | 2-4 pages | Varies per feature |
The handoff
The PRD says “what does the restaurant serve?” The spec says “here’s the recipe for each dish.” You need the menu before you write recipes.
Concepts to explore next
| Concept | What it covers | Status |
|---|---|---|
| technical-specification | How to define exact behaviour for AI agents | complete |
| architecture-decision-records | How to record the “why” behind choices | complete |
| user-stories | How to formalise user flows into testable stories | complete |
| acceptance-criteria | How to define binary “done” conditions | stub |
| scope-management | How to manage scope and prevent creep | complete |
Some of these cards don't exist yet
They’ll be created as the knowledge system grows. A broken link is a placeholder for future learning, not an error.
Check your understanding
Test yourself (click to expand)
- Explain what a PRD is to someone who has never built software. Use the travel itinerary or recipe analogy.
- Name the seven sections of a PRD and describe what question each one answers.
- Distinguish between a PRD and a technical specification — give an example of a statement that belongs in each.
- Interpret this scenario: you’re building a mobile app and halfway through, someone says “let’s also add a desktop version.” What section of the PRD helps you respond?
- Connect this concept: why does spec-driven-development start with a PRD before writing any specs?
Where this concept fits
Position in the knowledge graph
graph TD SD[Software Development] --> PR[Product Requirements] PR --> PRD[PRD] PR --> TS[Technical Specification] PR --> ADR[Architecture Decision Records] PRD --> US[User Stories] PRD --> AC[Acceptance Criteria] PRD --> SM[Scope Management] style PRD fill:#4a9ede,color:#fffRelated concepts:
- technical-specification — the PRD says what, the spec says how. The PRD feeds directly into the spec.
- architecture-decision-records — capture the why behind choices made while implementing the PRD
- spec-driven-development — the methodology that uses PRDs and specs as the source of truth
- vibe-coding — building without a PRD is the most common cause of drift in AI-assisted development
Further reading
Resources
- How to Write a PRD in 2026 (That AI Tools Can Follow) — The 13-section template for the AI coding era
- PRD Template 2026: A Practical Guide with Real Examples — Short, opinionated PRDs (2-4 pages) with worked examples
- How to Write a PRD: Step-by-Step Guide — ChatPRD’s comprehensive walkthrough for product managers
- How to Write a PRD in the AI Era — Discovery-first PRD process, what AI changes
- The Product Requirements Document Is Not Dead — Why PRDs matter more than ever, with engineering perspective
- PRDs Engineering Teams Love — How to write PRDs that actually get read