To write a PRD, work through six things in order: the problem, the users, the goals and non-goals, the user stories, the requirements, and the acceptance criteria. Then cut it down to the smallest first version and share it for feedback. That is the whole method. Everything below is how to do each step well.
This is the how-to in our AI PRDs guide. If you want the definition first, read what is a PRD. If you just want a template to fill in, grab the PRD template.
1. Start with the problem
Write the problem before anything else, in plain words. Not the solution — the problem. "People lose work when the app crashes because we don't autosave" is a problem. "Add autosave" is a solution you haven't earned yet.
A good problem statement is one or two sentences and passes a simple test: someone who has never seen the feature reads it and nods. If you can't write it clearly, you don't understand it yet, and no amount of feature detail will save you.
2. Name who has the problem
Say who this is for. Be specific. "Users" is not an answer; "people on a team plan who invite more than ten members" is. The narrower you can name the person, the sharper every decision after this gets.
If you have more than one type of user, list them and rank them. The primary user drives the design; the others are constraints.
3. Set goals and non-goals
Write what success looks like as a short list of goals. Then — and this is the part people skip — write the non-goals: the things you are deliberately not doing in this version.
Non-goals are where scope creep goes to die. "We are not building team-level permissions in v1" ends an argument before it starts. Every non-goal you write is a feature you don't have to build, review, or maintain. Write more of them than feels comfortable.
4. Write the user stories
Turn the feature into concrete stories, each with a who, a what, and a why:
As a team admin, I can remove a member so that someone who left the company loses access.
Stories keep you honest. If you can't phrase part of the feature as something a real person does for a real reason, question whether it belongs in this version. Aim for a handful of stories, not thirty — if you have thirty, your scope is too big.
5. List the requirements
Now get specific about what the thing must do. This is where you cover the boring, essential stuff:
- The happy path — the main thing the feature does.
- The edge cases — empty states, errors, permissions, limits.
- The constraints — anything it must or must not do (works offline, respects the existing role model, no new dependencies).
This is also the section where AI earns its place. Ask a model to "list the edge cases for this feature" and it will surface the empty states, the concurrent-edit problems, and the permission holes you'd otherwise find in code review. You still decide which ones matter — but you decide from a complete list.
6. Write concrete acceptance criteria
Acceptance criteria are the testable statements that tell you the feature is done. This is the most important section and the one people write worst.
The rule: could someone who isn't you verify it? Compare:
- Bad: "The export should be fast and easy to use."
- Good: "Clicking Export downloads a CSV containing every row currently visible in the table, within two seconds for up to 10,000 rows."
The good version is something a tester — or an AI coding agent — can check without asking you a single question. If your criteria need clarification, they aren't criteria yet.
7. Cut it down to the first version
You now have a complete PRD, and it is almost certainly too big. Cut it.
Ask of every requirement: does the first version fail without this? If it can ship without it, move it to a "later" list and leave it out. A PRD that tries to deliver everything ships nothing. The discipline of the scope cut is what separates a PRD that ships from a wish list that doesn't.
8. Share it and let it change
Send the PRD to the people building the feature before you're sure it's right. Engineers will catch impossible requirements; designers will push on the stories. That feedback is the point — it's cheaper to change a document than a build.
And keep changing it. A PRD is a living file. When you learn something mid-build, update the PRD so it still matches reality. The current version is the source of truth, not the version you wrote on day one.
Where AI fits in the process
AI helps at two ends of this. At the front, it drafts — give it the problem and the users and it writes a first pass of goals, stories, and edge cases in a minute. At the back, if your PRD is a file the agents can read, they execute it — picking up the work and checking their output against the acceptance criteria you wrote.
The judgment in the middle — deciding what to build and where the scope ends — stays yours. That's the healthy division: the AI drafts, you decide. The pillar guide covers the full AI-assisted workflow.
Where sfora fits
A PRD is only useful if the people building the feature can reach it — and increasingly some of those people are AI agents. sfora is a project workspace where humans and agents are members of the same team and everything is a markdown file, so the PRD you write lives right next to the tasks and the code.
You draft the spec, cut the scope, and drop the file in the workspace. An agent opens it over the filesystem, picks up the linked tasks, and builds against your acceptance criteria. The PRD stops being a document you hope someone reads and becomes the instruction the work runs on. See the docs for how agents read and write files.
- Need a starting point? Copy the PRD template.
- Want to see one filled in? Read the PRD examples.
- Building with agents? Read PRDs for AI coding agents.