BYD TechThe short answer
A product requirements document, or PRD, is a short written agreement about what you are building and why. A useful one names the user and their problem, states the goal and how you will measure it, lists what is in scope and what is not, and describes the main flows as user stories. Keep it to a few pages. Its job is to remove ambiguity, not to specify every screen.
Key points
- Start with the problem and the user. The solution comes second.
- One measurable goal beats a list of ten.
- The "out of scope" list is the most valuable part.
- Write flows as user stories with acceptance criteria.
- A PRD is a living page. Update it when decisions change.
What a PRD is for
A PRD exists so that the person paying, the person designing and the person coding all mean the same thing by "done". Most disappointing projects are not built badly. They are built to a different idea than the founder had in mind, because the idea was never written down.
Long specification documents went out of fashion for a good reason. Atlassian’s guidance on requirements describes the modern version as a single shared page that stays short and changes as the team learns. That is the kind worth writing.
What to include
| Section | What it answers |
|---|---|
| Problem | What is wrong today, for whom, and how do we know? |
| Users | Who are the one or two kinds of people this is for? |
| Goal and measure | What changes if this works, and what number shows it? |
| Scope | What is in this version? |
| Out of scope | What are we deliberately not doing yet? |
| User stories | What can a user do, step by step? |
| Constraints | Platforms, integrations, legal or data rules |
| Open questions | What is still undecided, and who decides? |
How to write user stories
A user story describes one thing a person can do and why. The common shape is: as a certain user, I want to do something, so that I get a result. Follow it with acceptance criteria, the plain checks that tell you it works.
- Story: As a clinic receptionist, I want to send an appointment reminder in one click, so that fewer patients miss their slot.
- Accepted when: the reminder goes to the patient’s phone, the appointment shows "reminded", and a failed message is flagged.
- Not a story: "The system shall have a robust notification engine." Nobody can test that.
Why "out of scope" matters most
Everything left unsaid will be assumed, and each person assumes something different. Writing "no mobile app in this version", "English only" or "refunds handled by hand" prevents the arguments that otherwise arrive late, when they are expensive.
It is also how a first version stays small. The discipline of cutting is described in How to build an MVP.
Common mistakes
- Describing the solution in detail and the problem in one line.
- No measure of success, so nobody can say whether it worked.
- Dictating technical choices that are better left to the people building.
- Writing it once and never updating it.
- Using it to replace conversation. A PRD records decisions. It does not make them.
Writing a PRD for AI coding tools
AI coding tools follow a clear PRD well and a vague one badly, which makes the same structure more useful, not less. Be explicit about the user, the flows, the acceptance checks and what is out of scope. Then have someone who can read code review what comes back, for the reasons in Vibe coding to production.
If you would rather not write it alone, this is what scoping produces in our MVP development work: a written plan in plain English and a clickable flow, before any code.
Sources
Checked when this guide was written.
