A product requirements document (PRD) is a short document that says what you are building and why, before anyone starts building it. It captures the problem, who has it, what success looks like, the scope of the first version, and the acceptance criteria that tell you the feature is done. It is the shared source of truth that keeps a whole team — product, design, engineering — pointed at the same outcome.
This is the definition article in our AI PRDs guide. If you want the bigger picture — writing one with AI, and making it something your agents can execute — start with the pillar. This page answers the narrow question: what actually is a PRD?
The definition, unpacked
A PRD answers a handful of questions, in order:
- What problem are we solving? The reason this work exists.
- Who has the problem? The people you are building for.
- What does success look like? The goals, and just as important, the non-goals — what you are deliberately not doing.
- What must it do? The requirements and user stories.
- How do we know it is done? The acceptance criteria — concrete, testable statements.
Put those together and you get the defining property of a PRD: it aligns a team on what and why before anyone argues about how. That is its whole job.
What a PRD is not
The word "requirements" scares people into writing a hundred-page contract. A PRD is not that. It helps to be clear about what it is not:
- Not a technical spec. The spec says how to build it — architecture, data model, APIs. That comes later and is engineering's document. The PRD stays on the product side: what and why, not how.
- Not a project plan. Timelines, milestones, and who does what live in your project tracker, not the PRD.
- Not a design mockup. The PRD can link to designs, but it is words, not screens. It describes the outcome; the design shows it.
- Not set in stone. A PRD is a living document. When you learn something, you change it. The current version is the truth.
Keeping the PRD to what and why is what keeps it short enough that people actually read it.
What goes in one
A good PRD has a predictable shape. Here are the sections most PRDs include:
| Section | What it answers |
|---|---|
| Problem | Why are we doing this? |
| Goals / non-goals | What is success, and what are we not doing? |
| Users | Who is this for? |
| User stories | What can someone do when it ships? |
| Requirements | What the thing must do |
| Acceptance criteria | How do we know it is done? |
| Design notes | Links to mockups and constraints |
| Open questions | What we still need to figure out |
You do not need every section for every feature. A small change might be a problem, three user stories, and acceptance criteria. A big launch needs the whole thing. Our PRD template gives you a copy-paste version, and how to write a PRD walks through filling each section.
Who writes the PRD
On most teams the product manager owns the PRD. But "owns" does not mean "writes alone." The best PRDs are drafted by one person and shaped by everyone building the feature — engineers catch missing edge cases, designers push on the user stories, the owner makes the final calls on scope.
On a small team there may be no PM at all. Then the PRD belongs to whoever owns the feature: a founder, a lead engineer, a designer. The role matters less than the rule — one accountable owner, one document everyone agrees on.
Why the PRD matters more now, not less
You might expect that in a world of fast AI coding, a written spec matters less — just tell the AI what you want and go. The opposite is true.
When an AI agent is building the feature, the PRD is the instruction. An agent cannot read your mind or catch you in the hallway to clarify. It reads what you wrote. A vague PRD produces a vague feature; a clear one, with concrete acceptance criteria, produces something you can actually check. The written spec is more load-bearing when a machine is reading it, not less.
That is the version sfora is built for: a workspace where the PRD is a markdown file your agents can open and act on. To write one that holds up, continue to how to write a PRD.