How to write a product requirements document (PRD).
A PRD defines what you're building, who it's for, and how it should behave — the single source of truth that aligns product, design and engineering. Here's what goes in one, a template you can copy, and how PRDs are changing now that AI coding agents read them too.
What is a product requirements document?
A product requirements document (PRD) is a structured document that defines a product's purpose, features, user needs and success criteria — the single source of truth that keeps designers, developers and stakeholders aligned through development. It captures what to build and why, while leaving how to the team.
Living, not locked
Modern PRDs are lightweight and updated as you learn — not 40-page specs signed off before any work starts. Agile teams favour 'just enough' context and shared understanding over exhaustive detail.
Answers four questions
A good PRD makes four things unambiguous: what are we building, who is it for, why now, and what does 'done' look like.
Distinct from a BRD or a spec
A BRD captures the company-level why. An engineering spec details the technical how. The PRD sits in the middle — defining the product and the user need.
The eight sections of a modern PRD.
A consistent structure makes a PRD scannable and reviewable. Adapt it to the work — not every project needs every section.
Overview
Product name, a one-line description and the target release. Scannable in five seconds.
Problem & goals
The problem, who has it, why now, and the measurable business objectives this work serves.
Target users
Two or three personas — role, behaviours, pain points and current tools — to keep the team focused on real humans.
Success metrics
The KPIs that define 'done'. If you can't measure it, you can't tell the team — or an AI — what success looks like.
User stories
'As a [user], I want to [action] so that [benefit].' Each one testable, with clear acceptance criteria.
Functional requirements
Features tiered P0 / P1 / P2 so scope is explicit and the most important work ships first.
Design & interaction
Key screens, flows and the visual system. For AI coding tools, describing the system in words beats attaching wireframes.
Out of scope & open questions
What you're deliberately not building, plus the decisions still to be made. Prevents scope creep and silent assumptions.
The PRD now has a second reader: your AI coding agent.
Tools like Cursor and Claude Code produce dramatically better output from structured requirements — and guess when they don't. That's pushed the PRD from a static doc toward a spec an agent can act on. The catch: a hand-written PRD goes stale the moment the codebase moves, and it doesn't know your file paths, conventions or tests. Here's how a traditional PRD compares to a codebase-aware spec.
| Circuit spec | Traditional PRD | AI PRD / doc writer | |
|---|---|---|---|
| Defines intent, scope & success criteria | |||
| Written as testable acceptance criteria | Partial | Partial | |
| Grounded in your actual codebase (files, conventions, tests) | — | — | |
| Prioritized by customer & revenue impact | Partial | — | |
| Drops straight into Cursor & Claude Code (MCP) | — | — | |
| Stays current as the product ships | — | — | |
| Closes the loop back to the customer who asked | — | — |
Defines intent, scope & success criteria
Written as testable acceptance criteria
Grounded in your actual codebase (files, conventions, tests)
Prioritized by customer & revenue impact
Drops straight into Cursor & Claude Code (MCP)
Stays current as the product ships
Closes the loop back to the customer who asked
Where the PRD fits Circuit's loop.
Circuit doesn't replace the thinking a PRD captures — it grounds that intent in your product and carries it through to shipped code. The PRD's intent flows through all three suites.
The PRD's inputs, decided by data.
The problem statement writes itself
Feedback from Slack, support, calls and surveys lands in one pipeline — deduplicated and classified — so the 'problem & goals' section starts from evidence, not a hunch.
Priorities ranked by truth, not volume
Scoring across urgency, revenue impact and sentiment decides what's worth a PRD next — so an enterprise blocker doesn't get buried under fifty free-tier asks.
The PRD, written as a buildable spec.
Specs grounded in your codebase
Circuit reads your GitHub repo — real file paths, conventions and tests — and outputs specs your coding agent can act on, not pseudocode a human still has to translate.
Ships where you build, then closes the loop
Specs deliver natively into Cursor and Claude Code over MCP, and the moment a request ships, the customers who asked are notified automatically — in their own words.
A PRD that never goes stale.
Every ship sharpens the next spec
Static documents decay the moment the product moves. Circuit learns from every ship and correction, so each cycle's priorities and specs are better than the last.
Ask your product anything
Instead of scrolling dashboards, ask in plain language — answered and cited from your own feedback, specs and ships, with Radar surfacing what's rising on its own.
PRD questions, answered.
What is a product requirements document (PRD)?
A PRD is a structured document that defines a product's purpose, features, user needs and success criteria. It's the single source of truth that aligns designers, developers and stakeholders, capturing what to build and why while leaving the technical how to the team.
What's the difference between a PRD, a BRD and a spec?
A BRD captures business requirements — the company-level why. A PRD defines the product — the what and for whom. An engineering spec details the technical how. The PRD sits in the middle and is usually the working document for a feature or release.
What should a PRD include?
A modern PRD typically covers eight things: an overview, the problem and goals, target users, success metrics, user stories, functional requirements (tiered by priority), design and interaction, and what's explicitly out of scope.
How do you write a PRD for AI coding tools like Cursor and Claude Code?
Make every requirement explicit and testable, tier features P0/P1/P2, and describe the design system in words — AI agents follow structured specs and guess at vague ones. Better still, generate the spec from your codebase so it carries real file paths and conventions, which is what Circuit does over MCP.
What is spec-driven development?
Spec-driven development means defining requirements, constraints and acceptance criteria up front, then using AI to generate code against that shared spec — aligning first instead of prompting and fixing later. Circuit turns scored customer priorities into codebase-aware specs that drop straight into your coding agent.
Does Circuit replace the PRD?
Circuit replaces the stale, hand-maintained parts. You still decide intent and scope; Circuit grounds that intent in your codebase, ranks it by customer and revenue impact, ships it to Cursor and Claude Code, and notifies the customers who asked when it lands.