Writing a product requirements document people read

A product requirements document, usually shortened to PRD, has a reputation. It is the long file that a founder writes, a team nods at and nobody opens again. The reputation is earned by a particular kind of PRD: one written to be approved rather than to be used.

A document people read is a different object. It is short enough to read in one sitting, specific enough to argue with and honest about what it does not know. This article gives a structure for that kind of document, an invented example and a few tests for whether yours works. It is written mainly for non-technical founders who need to brief engineers they may never meet in person, though a technical founder briefing a teammate faces the same problem.

What the document is for

A requirements document has one job: to let a person who was not in your head understand what you want built, why, and what you do not want built. Everything else is decoration.

That framing explains why length hurts. Each section you add is a section someone must read and keep consistent. Basecamp’s Shape Up describes a “pitch” with five named ingredients, which gives a useful skeleton: a handful of parts, each answering one question. You can borrow the shape without adopting the method.

It helps to name the readers before you write. An engineer reads to find out what to build and what to leave alone. A designer, if you have one, reads to learn who the screen is for. A teammate who joins later reads to find out why the product is the way it is. And you, in three months, read to remember what you agreed. Each reader needs the problem and the exclusions more than they need a long description of the solution, because the solution is the part they will refine with you in conversation.

A document also works best when it starts a conversation rather than ending one. Send it before a call, ask for the first thing that is unclear, and treat the answer as an edit to the page.

The five ingredients, and what each is for

Shape Up names the parts of a pitch. In its words, the problem is “the raw idea, a use case, or something we’ve seen that motivates us to work on this.” The appetite is “how much time we want to spend and how that constrains the solution.” The solution is “the core elements we came up with, presented in a form that’s easy for people to immediately understand.” Rabbit holes are “details about the solution worth calling out to avoid problems.” And no-gos are “anything specifically excluded from the concept: functionality or use cases we intentionally aren’t covering.”

Translate those into a PRD for a small software company and you get a structure you can fill in an afternoon.

Two of these deserve more comment, because they are the parts most often missing.

The appetite. Shape Up explains why a time limit belongs inside the document: “Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out.” A requirements document without a stated limit invites every reasonable addition. Stating an appetite, even a rough one, gives readers a way to say “that does not fit” without it becoming a personal disagreement. The article on estimating a first release is about the difference between an appetite and an estimate.

The no-gos. A list of exclusions does more work than most inclusions. If you write “no second user role in this release,” an engineer does not have to guess, and a customer request for a second role becomes a decision rather than a surprise.

Acceptance in the customer’s words

The acceptance section is where requirements become checkable. The UK Government Digital Service’s service manual describes writing user stories that “describe a user and the reason why they need to use the service you’re building,” and describes acceptance criteria as “a list of outcomes that you use as a checklist.” Both are cheap to write, and both change the conversation. A criterion such as “the receptionist can see all unconfirmed patients on one screen” can be tested by a person. A criterion such as “the list is intuitive” cannot.

Write each outcome so that a stranger could answer yes or no after trying it. If you find you cannot, the requirement is still a wish, and the useful next step is a conversation, not a longer document.

An invented example

The following is an illustration, not a client document. It shows the register and the length, and every detail is made up.

Notice that the problem paragraph says what was and was not measured. That sentence costs nothing and protects every reader from assuming you know more than you do.

Three tests before you share it

The read-aloud test. Read the document to a colleague in under five minutes, out loud. Where you stumble, a reader would too.

The stranger test. Ask someone outside the project what the document asks them to decide. If they cannot say, the decision line is not yet a decision line.

The change test. After the first build conversation, count how many sentences changed. A document that never changes is probably not being used. One that is rewritten each time is probably missing a no-go.

Keep it alive, and keep it small

A PRD that is not updated becomes a source of arguments about what was agreed. Put the date and a status line at the top. When a decision changes, change the sentence and note the date. If a part grows beyond a page, it is probably two documents. The Scrum Guide describes the product backlog as “an emergent, ordered list,” a useful reminder that the document describing a product is expected to change as you learn. If you would like a companion exercise, the one-page problem brief covers the problem section on its own, and the cut-line worksheet helps you fill in the no-gos. Terms used here are defined in the glossary.

What this article cannot tell you

The structure above is adapted from published practice and is not a standard. Basecamp describes its own pitch format, and the UK service manual describes user stories for government services; neither was designed for a small commercial software company, and neither tested whether a document of this shape produces better products. We make no such claim.

The article does not cover regulated products, where requirements documents may carry formal obligations, and it does not cover contracts with outside developers, where a requirements document may become part of the legal agreement. For those, ask your counsel and your delivery partner what the document must contain. It also cannot tell you whether the problem you chose is the right one, which only customers can.

In the data

These figures describe U.S. businesses in general, not WE’s results. Each one names its source.

Show the data as a table

Share of establishments that closed in 2023, by the age of the firm that owned them

Firm age	Establishment exit rate, 2023
Age 1	25.7%
Age 2	18.1%
Age 3	14.0%
Age 4	12.5%
Age 5	11.5%
Age 6 to 10	9.9%
Age 11 to 15	8.5%
Age 16 to 20	7.9%
Age 21 to 25	7.5%
Age 26 and older	7.1%

All U.S. employer firms in every sector. A closed location is not always a failed company: sales, mergers and planned closures count too.

Source: U.S. Census Bureau, Business Dynamics Statistics, firm age , 1978 to 2023

Retrieved 2026-10-16. Rates are the published establishment exit rates (exits in 2023 over the average count of establishments in 2022 and 2023), rounded to one decimal.

Sources

1. Shape Up, Chapter 6, Write the Pitch, Basecamp . Accessed October 10, 2026.
2. Shape Up, Chapter 2, Principles of Shaping, Basecamp . Accessed October 10, 2026.
3. Writing user stories, Government Digital Service, GOV.UK Service Manual . Accessed October 10, 2026.
4. The Scrum Guide, Ken Schwaber and Jeff Sutherland, scrumguides.org . Accessed October 10, 2026.

Spotted an error? Read how we handle corrections in our editorial policy.