What is a PRD? How to write a one-page requirements doc

The situation: a fifteen-page document and the same questions again

You have been a PO for a few weeks. Your first feature lets customers change their delivery address after placing an order. Wanting to do it properly, you write a fifteen-page document: market background, twelve user stories, screen sketches, a list of data fields, even an FAQ section.

One sprint later, an engineer asks: “If the order is already packed, can they still change it?” The answer is on page nine. The designer built the screen a different way because there was only time to read the first two pages. Customer support never opened the document. You wrote everything down, yet the team still asks about each point.

This is an illustrative situation, not the story of a particular team. This article shows another way: a one-page requirements document, or short PRD. It does not replace user stories or acceptance criteria. It is the first page anyone can read in a few minutes to understand why the work matters, how far it goes, and what is still unclear.

Why is writing requirements hard for a new PO?

PRD stands for product requirements document. Some teams call it a spec. The hard part is not knowing which sections a PRD has. There are plenty of templates online. The hard part is choosing what to write and what to leave out.

• Long feels thorough. When you are new, writing a lot feels safe: if something goes wrong, at least it was written down. But readers do not have time to read it all, so what matters gets buried among what does not.
• You fear questions you cannot answer. It is tempting to answer every possible question in advance, including ones nobody has data for yet. The document fills up with guesses that look like facts.
• You are not sure which parts belong to the team. Layout, data storage and API design are areas where designers and engineers know more than the PO. Writing them in advance takes away the team's room to contribute, and the document goes stale quickly.
• You write alone, then send. A document shared only when finished turns readers into approvers, not people thinking it through with you.

Atlassian lists anti-patterns for agile requirements, including a project that is spec'd out in great detail before any engineering work begins, and a product owner who writes requirements without the team. The Scrum Guide describes adding detail to backlog items as an ongoing activity called refinement, not a one-time task done up front.

So the aim of one page is not to write less to save time. The aim is to record what the whole team must understand the same way, and to leave clearly marked gaps for what still needs to be worked out together.

What goes into a one-page PRD?

One page can hold seven parts in four groups. This is also a good order for writing: understand the problem first, then move to the solution and its limits.

Each part should answer the following:

• Problem: one to three sentences on what is happening, in the words of the people affected. No solution here.
• Users: who has the problem and in what situation. If there are several groups, say which one this release serves.
• Goal and measure: the intended result and one metric to check after launch, with its data source. If there is no baseline yet, say that it needs measuring first.
• Scope and out of scope: what is in this release and what is deliberately left for later. Atlassian calls this section “what we're not doing”, and it can head off many arguments later.
• Key flows: the few steps a user goes through, the happy path plus one or two blocked cases. No screens here, just a link to the designs when they exist.
• Open questions: what needs deciding or researching, with who will answer and by when. This is where you are allowed to say “we don't know yet”.
• Risks and dependencies: what could make the result go wrong, and which teams or systems this work relies on.

Any part can be a few lines. If one part grows beyond half a page, that is a sign to move it into its own document and leave a link.

How do you write a one-page PRD, step by step?

One page is quicker to write than fifteen, but it is not written in a single pass. One way to do it is in four steps.

• Step 1: draft the problem and users first. If you cannot state the problem in three sentences without mentioning a solution, go back to the person who asked. The feature request article linked below has a set of questions for this step.
• Step 2: agree the goal and measure with whoever owns the numbers. Ask the team holding the data whether the metric can be measured, where it comes from, and what it is today. A goal you cannot measure cannot be checked after launch.
• Step 3: sit with the designer and engineers for about thirty minutes and read the scope, key flows and open questions together. They can spot risks you had not thought of, such as old data, permissions or external systems.
• Step 4: share it with stakeholders and keep it alive. When an open question is answered, move the answer into the right part and note the date. Once the page stops being true, the team stops reading it.

Only after step 3 do you split the work into user stories and write acceptance criteria for each. The one-pager answers “why and how far”. User stories and acceptance criteria answer “what exactly, and what counts as done”. Link them back to this page so anyone opening a story can find the context.

• How to handle a feature request
• How to write user stories as a beginner

Example: from a vague message to a clear page

Back to the opening situation, applied to a fictional online ceramics shop called Gốm Mộc. The customer support lead writes: “Let customers fix their address in the app, they're calling the hotline too much.” The table shows how that message turns into each part of the page. Every number in the table is assumed for illustration.

Notice a few things. The goal has a current number, a target and a concrete measurement source that support already uses, so anyone can check it after four weeks. The out-of-scope part gives a reason, so when someone asks “why not allow another province?”, the answer is already on the page. Each open question names who will answer it, so it does not hang.

The page has no screens, no field names and no API design. That is for the designer and engineers to propose after reading. Specific acceptance criteria, such as how quickly the notification appears or what counts as a valid address, live in each user story.

• Acceptance criteria you can actually test

When do you need a full spec instead of one page?

One page suits many small and medium features, but not all of them. Use the filter below to decide. If you answer “yes” to all four questions, one page is enough.

Even when you need a long spec, one page still helps as the first thing people read. Readers skim it for context, then open only the detail relevant to their own work. Atlassian also describes the requirements page as a “landing page” for everything related, using links to lead readers to detail when they need it.

The “Working Backwards” approach Werner Vogels described at Amazon shares the same spirit: write from the customer's side first, as a launch press release and FAQ, then work back to the technology needed. You do not have to use that exact format. What is worth borrowing is starting from the user and the result, not from a list of features.

A one-page PRD template you can use today

Copy the template into your team's document tool, such as Confluence, Notion or Google Docs. Keep the headings and replace the parts in square brackets. Anything you cannot answer yet goes into open questions instead of a guess.

Feature: [short name]
Owner: [PO] | Team: [design, engineering, QA, operations]
Status: [draft / clarifying / agreed] | Updated: [date]

1. Problem
[1 to 3 sentences: what is happening, in the words of the people affected. No solution yet.]

2. Users
[Who has the problem, in what situation. Which group this release serves.]

3. Goal and measure
Intended result: [what changes]
Metric: [name] | Today: [number, source] | Target: [number] after [time]

4. Scope
In this release:
- [ ]
Not in this release (and why):
- [ ]

5. Key flows
Happy path: [step 1] > [step 2] > [step 3]
Blocked case: [when, what the user sees]
Designs: [link]

6. Open questions
- [Question] | Answered by: [name] | By: [date]

7. Risks and dependencies
Risks: [what could go wrong, how to reduce it]
Dependencies: [teams, systems, partners]

Detail links: [user stories] | [acceptance criteria] | [other docs]

Before you share it, reread it and ask: could someone new to the team read this in five minutes and restate the problem, the goal and what is out of scope? If not, the page is either missing something or still too long.

Common mistakes with short PRDs

• Starting with the solution. A problem section that reads “Add a change-address button” describes a solution. Rewrite it as what users are going through.
• A goal you cannot measure. “Improve the customer experience” cannot be checked after launch. You need a metric, a data source and a time frame.
• Leaving out of scope empty. Without it, everyone reads the scope their own way, and the argument surfaces at acceptance.
• Copying detail in instead of linking. Pasting all the acceptance criteria or design images into the page makes it long again, and the two copies drift apart.
• Hiding open questions. Writing guesses as facts so the page looks complete. An open question with an owner and a date is more trustworthy than a guessed answer.
• Writing it once and leaving it. If the page is not updated when decisions change, the team goes back to asking in chat, and the page stops being the entry point.

Summary

• A one-page PRD records what the whole team must understand the same way: problem, users, goal and measure, scope and out of scope, key flows, open questions, risks and dependencies.
• Write in order: problem first, solution later. Read it with the designer and engineers before splitting the work into user stories.
• Out of scope and open questions can head off many misunderstandings later. Do not leave them empty.
• Detail lives in user stories, acceptance criteria and designs, linked from the page rather than copied into it.
• For payments, legal rules, personal data or multi-team integration, add detailed documents, but keep one page as the entry point.

I am writing more PO situations in this same format, with templates you can use straight away. If you would like the next one by email, subscribe to the newsletter below.

• Get new articles by email

Frequently asked questions

What is a PRD?

A PRD (product requirements document) explains why a feature is being built, for whom, the intended result and the scope. It helps designers, engineers and stakeholders share one understanding before the work is split into user stories.

What goes into a one-page PRD?

Seven parts: problem, users, goal and how to measure it, scope and out of scope, key flows, open questions, and risks and dependencies. Detail such as acceptance criteria or designs is linked from the page, not copied into it.

When is one page not enough?

When the feature touches payments, legal rules or personal data, when several teams must integrate, or when the business rules are long. Keep the one page as the entry point and move the detail into separate linked documents.

Sources to check

• Atlassian: How to create a product requirements document
• Scrum Guide 2020: Product Owner and Product Backlog
• All Things Distributed: Working Backwards

Related articles

• What is a user story? How to write one, with examples: The “As a…, I want…, so that…” template is the easy part. This article shows how to pick a real user, a real problem and a small enough slice, with before and after examples.
• What are acceptance criteria? Writing them so QA can test: How to write acceptance criteria clear enough that QA knows exactly what to test, with a coupon example and ready-to-use templates.
• Prioritising the backlog when everything is urgent: How to choose between value vs effort, MoSCoW and RICE, separate real deadlines from felt urgency, and send stakeholders a one-page priority note.
• How to say no to your manager and stakeholders: Three ways to say no instead of a flat “no”, how to handle it when the request comes from your manager or CEO, when to escalate, with a sample dialogue and messages for each level.