PRD Generator for Product Requirements

Decide how much detail the work needs before you start. A one-page brief holds the problem, goals, up to six requirements, the non-goals and the open questions. The full version adds user flows, constraints, dependencies and risks. Write the full version when any of these is true:

• More than one team has to build or support it
• It touches payments, personal data or a contract
• The flow has many branches, or a mistake would be costly to undo

Even the short version has fixed parts. In Shape Up¹, Ryan Singer's book on how Basecamp plans product work, every pitch has the same five ingredients. They are the problem, the appetite (how much time it's worth), the solution, the rabbit holes to avoid and the no-gos.

Write the problem before any solution. Singer's advice is that the best problem definition is a single specific story that shows why the status quo doesn't work¹. Make it one real customer's story: what they were trying to do, and where it broke.

One story could be a fluke, so list the evidence that it isn't, each item with its source: support tickets, lost deals, usage numbers, interview notes. If your evidence is interview transcripts, first sort them into findings counted by how many people raised each one.

State the appetite too. A fix worth 2 weeks looks nothing like one worth a quarter, and Singer writes that stating the appetite prevents unproductive conversations¹.

Finish with goals: the number you expect to move, and where it stands today. If you don't know today's figure, write "baseline to confirm" instead of guessing.

Each requirement says what the product does for someone, never how to build it. Joel Spolsky, a former Microsoft program manager who later co-created Stack Overflow, drew this line in 2000. A functional spec, he wrote, describes how a product will work entirely from the user's perspective². Data structures, databases and tools belong in a separate technical spec.

Give each requirement one priority word that everyone reads the same way. The Agile Business Consortium's guide to MoSCoW prioritization has a sharp test for a Must: ask what happens if the requirement isn't met. If there's any way around it, even a manual and painful one³, it isn't a Must.

Keep the Musts lean. The same guide puts the safe level at 60% of the effort or less. Everything that isn't a Must is your room to cut when estimates slip.

Attach a test anyone could run: an action and the result they should see. Fast, easy and secure can't be tested until you trade them for a number or a visible outcome.

Non-goals settle scope arguments while they're still cheap. Spolsky's reason: everyone on a team tends to have pet features they just can't live without², and building them all would take forever. List what a reader might reasonably expect but won't get in this release, each with a one-line reason.

MoSCoW's Won't Have this time label does the same job. The Agile Business Consortium notes that recording these items stops them from being informally reintroduced later³.

Finally, note the constraints the team must work within, such as an existing sign-in system or a fixed launch date, and the teams or vendors you depend on.

Lay out the main path as short numbered steps, then each way it can fail: a wrong password, an expired link, a declined card. Spolsky points out that every error case is a decision somebody has to make². If nobody decides, nobody can write the code.

Changing a flow that already exists? A user flow and journey map shows the routes people actually take today, including steps nobody designed.

Then name the risks. Marty Cagan, who founded the Silicon Valley Product Group, sorts product risk into four kinds⁴. Write one line for each, with what you'll do about it:

• Value: will customers buy it, or users choose to use it?
• Usability: can people figure out how to use it?
• Feasibility: can engineers build it with the time, skills and technology you have?
• Business viability: does it work for sales, legal, finance and the rest of the business?

A first draft is full of guesses: who the users are, how many there will be, what security will allow. Label each one as an assumption so nobody mistakes it for a fact. Spolsky flagged open issues in a special style so he could search for them², and expected every one to be settled before programmers started.

Every open question needs an owner, by role if you don't have a name, and a deadline for the answer. Otherwise it tends to get answered in code, by whoever reaches it first.

Want to see a finished one first? The PRD template comes filled in with a worked example. Or describe your feature in the box at the top of this page, and River drafts the PRD with each assumption marked. Once it's agreed, turn the Musts into user stories with acceptance criteria.