Here is a PRD template you can copy and use today. A PRD — a product requirements document — is a short markdown file that answers three things: what problem you are solving, what you are going to build, and how you will know it worked. This template gives you seven sections in that order: problem, goals, non-goals, user stories, requirements, success metrics, and rollout. Copy the block below, fill it in, delete the notes in italics.
This is the template article in our AI PRDs guide. For a worked, filled-in version, jump to PRD examples. For how to write one an AI coding agent can execute, see PRDs for AI coding agents.
The template
Copy everything in this block into a new .md file and start editing.
# PRD: <feature name>
**Author:** <you>
**Status:** Draft · In review · Approved · Shipped
**Last updated:** <date>
## Problem
<One paragraph. What is broken or missing today, and for whom? Use a real
example, not an abstraction. If you can't name who hurts and how, stop here —
you don't have a problem yet.>
## Goals
<What does success look like? Two to four bullets, each a single outcome.>
- <e.g. A person can export their data in under 10 seconds>
- <e.g. Support stops fielding "where's my export" tickets>
## Non-goals
<What you are deliberately NOT doing in this piece of work. This is the most
useful section and the one people skip. It kills scope creep before it starts.>
- <e.g. Scheduled or recurring exports — later>
- <e.g. Exporting other people's data — out of scope>
## User stories
<Who does what, and why. One line each. Keep them small.>
- As a <role>, I want to <action> so that <outcome>.
- As a <role>, I want to <action> so that <outcome>.
## Requirements
<The actual behavior to build. Number them so you can reference them in review
and in tickets. Split must-have from nice-to-have.>
**Must have**
1. <Precise, testable statement. "The export button is disabled while an export
is running," not "handle concurrent exports gracefully.">
2. <...>
**Nice to have**
- <...>
## Success metrics
<How you'll know it worked, in numbers, after it ships. Name the metric and the
target. If you can't measure it, say how you'll judge it instead.>
- <e.g. 80% of exports complete in under 10s>
- <e.g. Export-related support tickets drop by half within a month>
## Rollout
<How this reaches people. Flag, phased, all at once? What has to be true before
you ship, and what's the plan if it goes wrong?>
- **Ship behind:** <feature flag / percentage rollout / straight to everyone>
- **Before launch:** <docs, migration, comms>
- **Rollback:** <how you turn it off>How to fill each section
The template is only as good as what you put in it. Here is what each section is really asking for.
Problem. Write this first and write it about a person. "Sarah exports her report every Monday and it takes four minutes and times out half the time." That's a problem. "Improve export performance" is a wish. If you can't name who hurts, you're not ready to build.
Goals and non-goals. Goals are outcomes, not features. "Exports finish in under ten seconds" is a goal; "add a progress bar" is a feature that might serve it. Non-goals are where you win. Every "we are not doing X right now" is a fight you don't have to have later. Spend real time here.
User stories. Keep them tiny. One role, one action, one reason. If a story needs three clauses, it's two stories. These become your test cases, so make them concrete.
Requirements. This is the build list, and it's where vagueness costs you. Write each requirement so someone could tell you pass or fail without asking a question. "The button is disabled while an export runs" is testable. "Handle concurrency gracefully" is not — graceful how? Number them so a ticket can say "implements requirement 3."
Success metrics. Pick numbers you'll actually check after launch. A metric with no target is a decoration. If a thing genuinely can't be measured, say how you'll judge it by eye and who decides.
Rollout. Say how it ships and how you turn it off. Most features should go out behind a flag so you can roll back without a deploy. Note anything that has to happen first — a migration, a docs update, a heads-up to support.
A few rules that keep PRDs useful
- Short beats complete. One to three pages. If it's longer, you're solving too much at once.
- Write non-goals before requirements. Deciding what you won't do sharpens what you will.
- Make every requirement testable. If you can't write a pass/fail check for it, it's not a requirement yet.
- It's a living doc. Update the status line and requirements as you learn. A PRD that's frozen at "draft" is a PRD nobody read.
Where sfora fits
In sfora, this template isn't a file that dies in a folder — it's a live document your team and your AI agents both work from. Everything in sfora is markdown, so you paste this template in as-is. A person can read it, comment on it, and turn its requirements into tasks. And because agents are equal members of the same workspace, an AI agent can read the same PRD, pick up the requirements, and start executing against them — under the same permissions and review as anyone else.
That last part changes how you write the requirements section. When a coding agent might be the one implementing requirement 3, precision stops being polish and starts being the thing that makes it runnable. That's the subject of PRDs for AI coding agents. To see the template filled in, read PRD examples.