How to Write a Product Requirements Document
A product requirements document, or PRD, is where a fuzzy idea becomes something your team can build, test and ship. You do not need a twenty-page spec. You need a clear, shared page that explains the problem, who it is for, what is in and out of scope and how you will know it worked. Here is how to write one that people actually read.
Key takeaways
- A PRD explains why you are building something, for whom, and what success looks like, before anyone writes code.
- Lead with the problem and the user, not the solution. Requirements should describe outcomes, not pixel-level designs.
- Write down what is out of scope. It prevents more arguments than any other section.
- Keep it short, link to designs and research, and treat it as a living document until launch.
In a small startup, it is tempting to skip documentation entirely. The founder explains the idea in a stand-up, a developer starts building, and three weeks later everyone discovers they had a different feature in mind. A PRD fixes that for the cost of an hour or two of writing.
It also helps you think. Writing "the problem we are solving" in plain sentences often reveals that you are not sure what the problem is yet. That is a great discovery to make before you spend a sprint on it.
What a PRD is, and what it is not
A product requirements document describes a feature or product from the user's point of view: the problem, the goals, the requirements and the measures of success. It is the shared reference for product, design, engineering, marketing and support.
It is not a technical design document. How the system will be built, which database to use and how services talk to each other belong in a separate engineering doc that responds to the PRD. It is also not a business plan or a roadmap. A roadmap shows the order of many initiatives, while a PRD goes deep on one.
When you need one
- New features that take more than a few days or touch several people.
- Changes with risk, such as pricing, permissions, billing or anything involving customer data.
- Work with outside help, such as an agency or freelance developer, where unclear scope costs real money.
- Anything a customer was promised, so the commitment is written down accurately.
Small bug fixes and quick experiments rarely need a full PRD. A short ticket with a clear description is enough.
Pro tip
Match the length of the PRD to the size of the risk. A one-week feature might need a single page. A new product line might need several pages plus linked research. If nobody would read it, it is too long.
The sections every PRD should include
Different teams use different formats, but strong PRDs tend to share the same core sections.
1. Overview and owner
A two or three sentence summary, the document owner, the status (draft, in review, approved, shipped) and the date of the last update. Anyone landing on the page should know in ten seconds what it is about and who to ask.
2. Problem statement
Describe the user's problem in their language, with evidence. Quote customer interviews, support tickets, sales notes or usage data. Explain why solving it matters now.
3. Users and use cases
Who has this problem? Name the primary user type and any secondary ones. Then write the key use cases or user stories, such as "As a shop owner, I want to see which products are low in stock so I can reorder before I sell out."
4. Goals and success metrics
What will be true when this works? Pick one or two measurable outcomes and a target. If your company uses OKRs, which are Objectives and Key Results typically set quarterly, link the PRD to the relevant objective so everyone sees how this work moves the bigger goal.
5. Requirements
List what the product must do, grouped by priority. A simple must have, should have and nice to have split works well. Each requirement should be testable: someone should be able to say yes or no to whether it was met.
6. Out of scope
Spell out what you are deliberately not doing in this version. This protects the team from scope creep and sets honest expectations with stakeholders.
7. Design, open questions and launch notes
Link wireframes or mockups, list unresolved questions with an owner for each, and note anything launch-related: support articles, pricing changes, customer communication and any legal or privacy review.
Common mistake
Writing the solution into the problem statement. "Users need a dashboard" is a solution. "Users cannot tell which orders are late until a customer complains" is a problem. Start with the problem and you leave room for a better solution than the first one you thought of.
How to write your PRD step by step
Here is a practical process that works for small teams and solo founders alike.
- Gather the evidence. Pull together interview notes, support tickets, feature requests and any usage data. Highlight direct quotes that describe the pain.
- Write the problem and the user first. Draft these two sections before anything else, then share them with one or two teammates to check you agree.
- Set the goal and metric. Decide how you will measure success and what result would make the work worthwhile.
- List requirements as outcomes. Describe what the user can do, not how the screen looks. Keep each requirement short and testable.
- Cut the scope. Move anything that is not essential for the first release into out of scope or a later phase.
- Review with engineering and design. Ask what is unclear, what is risky and what is harder than it looks. Update the PRD with their answers.
- Get sign-off and keep it current. Mark the status as approved, then update it whenever a decision changes so the PRD never goes stale.
A copyable PRD requirements template
The requirements table is the heart of most PRDs. Copy these columns into your doc or spreadsheet. The rows below are made-up examples for an imaginary inventory feature.
| ID | User story | Priority | Acceptance criteria | Notes or open questions |
|---|---|---|---|---|
| R1 | As a shop owner, I want to see products below a stock level I set, so I can reorder in time. | Must have | Owner can set a level per product; low items appear in a list on the home screen. | Default level? Ask 5 customers. |
| R2 | As a shop owner, I want an email when an item drops below its level. | Should have | Email sent within one hour of the change; owner can turn it off. | Check email consent wording. |
| R3 | As a shop owner, I want to create a purchase order from the low stock list. | Nice to have | One click creates a draft order with suggested quantities. | Likely phase 2. |
Good acceptance criteria let a tester, or you on a Friday afternoon, check each requirement without guessing what "done" means.
Hypothetical example
Imagine Sam, the founder of a two-person software startup selling to independent shops. Customers keep asking for "inventory alerts." Instead of building straight away, Sam writes a one-page PRD. The problem statement, based on six support emails, reads: "Shop owners run out of best sellers because they only notice low stock when a customer asks." The goal is that owners using the feature have fewer out-of-stock complaints within two months. Out of scope: supplier integrations and automatic reordering. The developer reviews it, points out that emails need a consent check for UK and EU users, and the team ships a focused first version in two weeks instead of a sprawling one in two months.
Writing tips that make PRDs easy to use
A PRD only helps if people read it and refer back to it. These habits make that far more likely.
- Use plain language. Write for a new teammate who knows nothing about the project. Define any acronyms on first use.
- Lead with the summary. Busy readers may only read the top. Make sure it answers what, why and for whom.
- Prefer lists and tables over long paragraphs for requirements, risks and open questions.
- Link instead of pasting. Link to designs, research notes and data dashboards rather than copying them in.
- Name owners. Every open question and launch task should have a person attached.
- Keep a change log. A short dated list of decisions at the bottom saves you from re-arguing settled points.
Where to write and store your PRD
Use whatever tool your team already opens every day. Knowledge base tools such as Notion, Confluence, Slite and Guru work well because they support comments, links and version history. For early discovery, an online whiteboard such as Miro, Mural, FigJam or Microsoft Whiteboard is handy for mapping user journeys before you write. Check current features, pricing and privacy policies before you choose, especially if the PRD includes customer quotes or data.
Using AI to help draft
AI writing tools such as ChatGPT, Claude or Gemini can help turn rough notes into a first draft, suggest edge cases or tighten wording. Treat the output as a starting point, check every claim against your real evidence, and do not paste confidential customer data into tools unless your company's policy allows it.
Pro tip
Hold a 30-minute PRD review rather than collecting comments for a week. Read the problem and goals aloud, then ask each person for the biggest risk they see. You will surface more useful feedback in half an hour than in days of scattered comments.
Common PRD problems and how to fix them
- Too long. Move background research to an appendix or a linked page and keep the main document focused on decisions.
- Too vague. If two people could read a requirement and build different things, rewrite it with clearer acceptance criteria.
- No metric. Without a success measure, you cannot tell whether the work was worth it. Add even a simple one.
- Out of date. A PRD that no longer matches what is being built is worse than none. Update it whenever a decision changes, or mark it as archived.
- Written alone. PRDs written in isolation miss technical constraints. Involve engineering and design early.
Your PRD checklist
- Collect evidence: interviews, tickets, requests and usage data
- Write a short summary with owner, status and date
- State the problem in the user's words, without a solution
- Name the primary users and write the key user stories
- Set one or two success metrics with targets
- List requirements by priority with testable acceptance criteria
- Write an out of scope section
- Link designs and list open questions with owners
- Review with engineering and design, then mark as approved
- Keep a change log until launch
Frequently asked questions
How long should a product requirements document be?
As short as possible while still being clear. Many small features fit on one or two pages. Bigger initiatives may need more, but move background detail into linked pages so the main document stays readable.
Who should write the PRD?
Usually the product manager, or the founder in an early startup. The best PRDs are written by one owner but shaped by input from engineering, design, sales and support.
Do agile teams still need PRDs?
Many do, in a lighter form. A short PRD gives context and goals, while the detailed work lives in tickets and sprints. The PRD answers why and what, and the backlog handles how and when.
Related reading
The bottom line
A product requirements document is a simple tool that saves a lot of wasted effort. Start with the problem and the user, set a clear goal, list testable requirements by priority, and write down what you will not build. Then review it with your team and keep it up to date until launch.
Pick the next feature on your list and draft a one-page PRD this week using the template above. You may be surprised how many questions it answers before a single line of code is written.
