Blog · Product requirements
How to write a product requirements document (PRD).
To write a PRD, start with the problem and who has it, then state the goal and the metric that shows it moved. List each requirement as a testable line tiered P0, P1 or P2, say what is out of scope, and keep the evidence next to each requirement.
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 product, design and engineering 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. Teams building with agents favor 'just enough' context: a short spec every agent reads beats 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.
A PRD template: the eight sections of a modern PRD.
Copy this PRD template as your starting structure. A consistent shape makes the document scannable and reviewable, and gives a coding agent something predictable to read. 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, behaviors, 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.
A short PRD to copy.
Here is a made-up example in the five sections Annsa uses for a spec: Problem, Evidence and direction, What to build, Files to touch and Done When. You, your agent or Ask writes it. Copy it and swap in your own work.
Late invoice reminders (example) Problem Owners send an invoice, then chase late payers by hand. Some forget, and the money arrives late. Evidence and direction Support requests keep asking how to chase a late payer. Start with one automatic reminder before building anything for accountants. What to build Send one reminder email three days after the due date if the invoice is still unpaid. The owner can turn reminders off for any invoice. Files to touch src/jobs/sendReminders.ts (new) src/invoices/invoice.ts src/email/templates/reminder.tsx Done When - An unpaid invoice three days past due gets exactly one reminder. - A paid invoice gets none. - Turning reminders off for one invoice stops them for that invoice only.
The PRD now has a second reader: your AI coding agent.
Coding agents such as Claude Code and Cursor do better work from structured requirements, and guess when they don't get them. 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.
| Annsa spec | Traditional PRD | AI PRD / doc writer | |
|---|---|---|---|
| Defines intent, scope & success criteria | |||
| Written as testable acceptance criteria | Partial | Partial | |
| Grounded in your codebase when Ask or your agent writes it | No | Partial | |
| Prioritized by customer & revenue impact | Partial | No | |
| Read by Claude Code, Cursor, Codex & Grok over MCP | No | Partial | |
| Keeps the customer evidence next to the spec | Partial | No | |
| Drafts a note to the customers who asked | No | No |
Defines intent, scope & success criteria
Written as testable acceptance criteria
Grounded in your codebase when Ask or your agent writes it
Prioritized by customer & revenue impact
Read by Claude Code, Cursor, Codex & Grok over MCP
Keeps the customer evidence next to the spec
Drafts a note to the customers who asked
Where the PRD fits Annsa's loop.
Annsa doesn't replace the thinking a PRD captures. It ranks what the PRD should be about, keeps the evidence next to the spec and shows you who to tell when it ships. You make the call at each step.
The PRD's inputs, ranked by evidence.
The problem statement starts from evidence
Your customers, your roadmap, your ideas and what your agents find land in one list, deduplicated and classified, so the 'problem & goals' section starts from evidence, not a hunch.
Priorities ranked by evidence, not volume
Annsa ranks broken things first, then what customers asked for, then ideas, and inside each by how many companies asked, then revenue, then urgency. It shows the evidence, so an enterprise blocker doesn't wait behind fifty free-tier wishes.
The PRD, written as a buildable spec.
Codebase-aware specs when you ask
Ask Annsa for a spec and it reads your connected GitHub repo (real file paths, conventions and tests), so your coding agent gets something it can act on, not pseudocode a human still has to translate. Or your agent writes it over MCP.
Ships where you build, then drafts the follow-up
Every agent reads the spec over MCP (Claude Code, Cursor, Codex and Grok), and when a request ships, Annsa drafts a note to the customers who asked. You review and send it.
A PRD that keeps up.
What shipped stays on the record
Static documents decay the moment the product moves. Annsa keeps what shipped and the principles you set, so the next spec starts from what the last one taught.
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 the team building it, capturing what to build and why while leaving the technical how to engineering.
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.
What are product requirements?
Product requirements are the individual statements of what the product must do, for whom, and how you will know it works. They are the contents; the PRD is the container. A requirement names one behavior, the user it serves and the condition that proves it, "a team admin can revoke a seat, and the seat frees within one billing cycle". Anything that cannot be tested is a preference rather than a requirement, and it is the first thing to argue about in review.
How to write product requirements
Write each one as a testable statement rather than a description. Name the user, the behavior and the condition that proves it, keep one requirement to one sentence, and tier it P0, P1 or P2 so the order survives a deadline. Avoid adjectives, fast, intuitive and simple cannot be verified, while "loads in under 400ms" can. The evidence behind the requirement belongs next to it, so the reader can see which customer asked and why it ranks where it does.
How to write a product requirements document
Work outward from the problem rather than inward from the feature. Open with the problem and who has it, state the goal and the metric that will show it moved, then list the requirements tiered by priority, then name what is explicitly out of scope. The out-of-scope section does more work than any other: it is what stops the document growing every time someone reads it. Write it to be cut from, not added to, and keep the evidence for each requirement attached so the reasoning survives the handoff.
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, write it with the codebase open so it carries real file paths and conventions. With Annsa, your agent writes it over MCP, or Ask writes it from your connected repo when you ask.
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. With Annsa, you, your agent or Ask writes the spec from a ranked priority, and Claude Code, Cursor, Codex and Grok read it over MCP.
Does Annsa replace the PRD?
Annsa replaces the stale, hand-maintained parts. You still decide intent and scope; Annsa ranks it by customer and revenue impact, you, your agent or Ask writes the spec against your codebase, Claude Code, Cursor, Codex and Grok build from it, and Share Back drafts a note to the customers who asked when it lands.