Writing a product requirements document people actually read

A product requirements document has one job: to get a group of people to agree on what is being built, for whom and why, before they spend weeks building it. Many fail at that job because nobody reads them. They run to twenty pages, mix settled decisions with open questions, and describe screens in detail while skipping the problem.

This guide shows how to write a requirements document, or a shorter one-page brief, that people read and use. It draws on Atlassian’s PRD guidance, Basecamp’s Shape Up pitch and Amazon’s working backwards practice.

What a PRD is, and what it is not

Wikipedia defines a product requirements document as a document containing the requirements for a product. It explains what the product should do and generally avoids saying how to build it, so designers and engineers can find the best solution. Technical design comes later, in a separate specification that responds to the PRD.

That split matters. A PRD that dictates database tables or button colours takes decisions away from the people best placed to make them. A good one sets the problem, the goal and the boundaries, then leaves room.

The sections that earn their place

Atlassian suggests a simple structure. Adapted slightly, these are the sections worth keeping:

1. Header. Owner, contributors, status (draft, in review, agreed) and target release. Put it at the top.
2. Problem and goal. What is wrong today, for whom, and what success looks like in numbers. Atlassian’s advice is to state goals clearly so nobody has room to make assumptions.
3. Background and fit. Why this, why now, and how it supports wider company goals.
4. Assumptions. What you believe about users, technology or the business that has not been proven. Atlassian notes that stating assumptions clearly helps identify risks and areas needing validation.
5. User stories or scenarios. The situations the product must handle, with links to interview notes and data.
6. Design. Links to sketches or prototypes once they exist. Do not paste large images in.
7. Open questions. A table of things still to decide, with an owner for each.
8. Not doing. What is out of scope. Atlassian calls this out so the team stays focused, and flags that excluded items may return later.

Atlassian also says never to write a PRD alone. Draft it with the designer and engineers, not for them.

The one-page alternative

For most features in a small company, a full PRD is too much. A one-page brief covers the same ground faster. Basecamp’s book Shape Up describes a short document called a pitch with five ingredients:

• Problem: the raw idea or use case that motivates the work, ideally one specific story.
• Appetite: how much time the team wants to spend, as opposed to an estimate of how long it will take.
• Solution: the core elements, in a form people can grasp at a glance, often rough sketches.
• Rabbit holes: details worth calling out to avoid problems.
• No-gos: anything specifically excluded.

Appetite is the most useful idea here. Saying “this is worth two weeks, no more” changes the conversation from “how long will this take?” to “what is the best version we can build in two weeks?” That keeps scope in check better than any estimate.

Writing it from the customer backwards

Amazon takes a different route to the same goal. Its working backwards process starts by writing a press release for the finished product, kept to under one page, followed by a set of frequently asked questions of five pages or less. The team writes as if the product already exists, which forces clarity about who it is for and why they would care. Amazon notes that most of these documents never become products, and treats that as the process working.

You do not need to copy the format. The useful habit is to write the customer-facing explanation first. If you cannot describe the benefit in plain words a customer would understand, the requirements beneath it are not ready.

A worked one-page brief

An example (illustration only). An online shop selling handmade jewellery in the UK and India wants to reduce support emails about delivery.

• Problem: About a third of support emails ask “where is my order?” Customers get a dispatch email with no tracking link, so they write in. Each reply takes the owner a few minutes.
• Goal: Halve “where is my order?” emails within two months of release.
• Appetite: One week of developer time.
• Solution: Add the courier tracking link to the dispatch email and to the order page in the customer’s account.
• Assumptions: Both couriers the shop uses provide a tracking URL per parcel. Customers open dispatch emails.
• Rabbit holes: Live tracking inside the shop’s own site. Linking to the courier’s page is enough.
• Not doing: SMS notifications, delivery date estimates.
• Open question: What to show for orders sent by untracked post? Owner: shop owner, by Friday.

That fits on one page, and anyone joining the conversation can see what is agreed and what is not.

Common mistakes

• Starting with the solution. If the first heading is “Features”, the problem has probably not been written down.
• No success measure. Without a number, nobody can say later whether it worked.
• Specifying how instead of what. Leave implementation to the people building it.
• Hiding open questions. Mixing undecided points with agreed ones makes the whole document feel uncertain.
• Letting it go stale. Atlassian warns that documentation can drift. Update status and decisions as they change, or mark the document as superseded.
• Writing for approval rather than understanding. Length does not signal rigour. Amazon’s guidance puts it bluntly: there are no awards for extra pages.

When to write which

Use a one-page brief for most features, fixes and experiments, especially in teams of under twenty people. Use a fuller PRD when several teams or outside suppliers are involved, when there are legal or compliance requirements to record, or when the work will run for months and people will join partway through. In either case, the test is the same: could a new engineer read it in ten minutes and explain back what is being built and why?