How is a PRD different from a user story?

A story describes one change from the point of view of the person who wants it. A PRD holds the case for a body of work, the evidence behind it, and the measures that will tell you whether it worked. Most teams write one PRD and many stories underneath it.

Should a PRD contain designs?

Link to them rather than pasting them in. Designs change faster than the problem does, and a PRD carrying screenshots goes stale within a Sprint while its problem statement is still true.

Nobody, in the sense of a signature. The document is the agreement, so the useful test is whether the people named in it would describe the problem the same way. If they would not, it is not finished.

What happens to it after the work ships?

Fill in the measures once you have read them, then leave it alone. A PRD records what you believed at the time, and rewriting that afterwards makes it useless for learning.

Discovery

PRD, one page

Problem statement, supporting evidence, the proposed change, success measures, and an explicit list of what is out of scope. Fits on a single page.

What it is

A product requirements document states the problem a team is solving, the evidence that the problem is real, and how everyone will know whether the change worked. The one page version exists because the long form stopped being read. Once a document runs past ten pages it becomes a record of decisions rather than a way of making them, and the people who most need to agree with it are the least likely to reach the end.

Keeping it to a page forces the parts that matter. You cannot pad a problem statement and still have room for measures, so the problem has to be specific. You cannot list twenty things as out of scope, so you have to name the three a reader would otherwise assume were in.

Writing it is most of the value. A team that cannot fill the evidence section usually finds it has an assumption rather than a problem, and that is worth knowing before engineering starts.

When to use it

Work is starting that more than one team will touch, and you want the problem agreed before the solution is designed.
A stakeholder keeps adding to the scope and you need something that says what is out and why.
Engineering is asking what success looks like and the answer so far has been a feature list.
You are handing work to a team you do not sit with, and the context has to travel with it.

What is in it

Problem
Evidence
Proposed change
Success measures
Out of scope
Open questions and risks

The template

Owner [name] / Team [team] / Updated [date] / Status Draft, in review or agreed

Problem

One paragraph on what is not working today, written from the position of the person who runs into it. Name who they are, what they are trying to finish, and how often it happens.

For example, admins on accounts with more than fifty seats rebuild the same permission set by hand for every new starter, roughly forty times a month across our twenty largest customers.

Evidence

Two or three lines, each carrying a source and a date. If a line has no source it is an assumption, and it belongs under open questions instead.

[Metric, with the date it was pulled and the population it covers]
[Support or sales signal, with a volume rather than an impression]
[Research finding, with how many people it came from]

Proposed change

What the person in the problem statement will be able to do that they cannot do now. Describe the behaviour they will see. Leave the implementation to the team.

Success measures

One primary measure with a baseline, a target and the date you will read it. One guardrail that must not move while you chase the primary.

Measure	Baseline	Target	Read on
Median time to set up a new seat	6 minutes	Under 90 seconds	30 days after release
Support contacts tagged permissions	120 a month	No increase	30 days after release

Out of scope

Name the things a reader would reasonably expect to find here, and say why each one is out. This list is what holds the scope still when the document reaches its fourth reviewer.

[Thing that is out, and the reason it is out]
[Thing that is out, and the reason it is out]

Open questions and risks

Anything unresolved, each with the person resolving it and the date you need the answer. A question with no name against it will still be open at launch.

Question or risk	Owner	Answer needed by
Do enterprise groups need per entity permission sets	[name]	[date]

Questions people ask

How is a PRD different from a user story?: A story describes one change from the point of view of the person who wants it. A PRD holds the case for a body of work, the evidence behind it, and the measures that will tell you whether it worked. Most teams write one PRD and many stories underneath it.
Should a PRD contain designs?: Link to them rather than pasting them in. Designs change faster than the problem does, and a PRD carrying screenshots goes stale within a Sprint while its problem statement is still true.
Who approves it?: Nobody, in the sense of a signature. The document is the agreement, so the useful test is whether the people named in it would describe the problem the same way. If they would not, it is not finished.
What happens to it after the work ships?: Fill in the measures once you have read them, then leave it alone. A PRD records what you believed at the time, and rewriting that afterwards makes it useless for learning.