Product Requirements Document (PRD): A Template for Teams Using AI Agents

A product requirements document records the problem, who has it, what will change, and how the team will know the change worked. People read it before design and code start, so engineers, designers and stakeholders end up building the same thing. This page gives you a reusable PRD template, a filled example, and the rules for keeping the agreement useful after the first sprint.

What a product requirements document includes

A product requirements document is a decision record. It says why the work exists, who it is for, what is in and out of scope, and which signals will count as success. It does not replace a design file, a technical design, or the tickets people pull into a cycle.

Teams that skip it pay later. Scope shows up in review, two people argue about whether an edge case was "obvious," and an engineer ships a clever path that solves a different problem. The document moves those arguments to a point where changing a paragraph is still cheap.

Write one when more than one person will touch the work, when building the wrong thing is expensive, or when an agent will plan from the brief. A copy fix needs a one-line ticket. A multi-week change, or anything touching billing, permissions or data, needs the longer form.

Who writes it

The person accountable for the outcome writes the first draft. On a small team that is often the founder; on a larger team it is the product manager for that area. Engineering and design comment before anyone calls it ready, but one owner stays responsible for the final wording, because shared docs with no owner drift.

Who reads it

Engineers read the constraints and non-goals. Designers read the job to be done rather than a widget list. Stakeholders read the problem, the success measures and the out-of-scope list. An agent should get the same text a new teammate would. If a new hire can't tell what done means from the document plus the tickets, the document isn't finished.

When you need one, and when a ticket is enough

Use a full document when any of these are true:

• The work spans more than one cycle, or more than one system.
• Failure has a real cost: wrong charges, lost data, broken permissions, a public API change.
• Several teams must agree before anyone starts.
• You expect an agent to draft a plan or a pull request from the brief.
• You cannot state the user and the success check in two sentences.

A ticket is enough when the change is local, reversible, and already covered by an existing decision. "Rename the export button" does not need a new document; link the ticket to the older decision if there is one. Medium-sized work can get by with five sections on one page: problem, user, scope, out of scope, acceptance examples. Save the full template below for work you can't afford to have reinterpreted halfway through the build.

A PRD template you can reuse

Copy this product requirements template into your doc tool or tracker. Delete the sections that don't apply, and say why you deleted them. An empty "security" section tells the next reader nothing, while "No new auth surface; uses existing session checks" tells them a lot.

Section	What to write	Done when
Header	Title, owner, status, date, reviewers	A person and a status are named
Problem	Who hurts, how often, what they do today	A stranger can retell the pain
Outcome	The change in user or business behavior	You can measure it without a new debate
Users and context	Primary user, secondary users, constraints	You know who you will disappoint on purpose
Scope	Behaviors the release must include	Each line can become a ticket
Out of scope	Attractive work you will not do now	Reviewers have signed the no
Stories and rules	User stories plus business rules	Rules cover the awkward cases
Acceptance examples	Concrete inputs and expected results	QA or an agent can test from them
UX notes	Flows, states, copy constraints	Empty, loading, error and success exist
Technical constraints	Systems, data, latency, compatibility	Engineers can name the touch points
Analytics	Events, properties, where they are reviewed	Someone owns the readout
Rollout	Flag, audience, rollback	You can turn it off
Open questions	Unknowns with an owner and a date	No question is anonymous

Put the status in the header: draft, in review, approved, building, shipped, superseded. Approved work can still change, but the status tells a reader whether they are looking at a proposal or at the agreement.

How to write each section

Problem

Describe the problem as something a specific person cannot do, along with their workaround and why it fails. Leave the solution out. If your first sentence names your feature, you have written a pitch.

Weak: "We need a CSV export for cycle reports." Stronger: "Leads paste cycle status into a slide every Monday because nothing they can send a director keeps the percentiles. The paste takes about half an hour, and the director's questions still send them back to the board."

Use numbers you measured, or label them as guesses. A made-up precise percentage helps no one.

Outcome and success checks

State the behavior you want after launch, the threshold you will watch, the date you will look, and what you will do if you miss. One primary measure is enough; anything extra is diagnostic.

A usable check: "Four weeks after rollout, at least three of the five leads who asked have downloaded a report without asking support, and support has no ticket caused by a wrong total." "Improve visibility" doesn't qualify.

Users, scope and non-goals

Name the primary user in one line, and say who isn't served yet. Write scope lines as behaviors. "A lead can download the current cycle as CSV" can become a ticket. "Build the export service" can't, because nobody can tell when it's done.

Non-goals save more wasted work than any other section. Write down the ideas people will suggest in review and mark them out. If a follow-up is likely, say "later" and point to a placeholder, so the idea isn't lost and doesn't get smuggled into this release.

Stories, rules and acceptance examples

A story is one sentence: as a [role], I want [capability], so that [outcome]. Stories on their own are too vague to build from, so add rules and acceptance examples under each one.

A rule holds regardless of the screen: "Rolled-over tickets stay in the file and are marked yes." An example is a tiny scenario with inputs and expected rows. Write out the unhappy paths too: an empty cycle, permission denied, a ticket that moved mid-export. When acceptance covers only the happy path, edge cases turn into production bugs.

UX, technical constraints, analytics, rollout

UX notes name the flows and the required states (empty, loading, error, no-permission, success). They don't lock in the visual design.

Technical constraints set boundaries: which system owns the data, what must stay compatible, what latency is unacceptable. The solution design is a separate note that engineering can own.

Analytics lists the events you need to run the success check. If you can't observe the outcome, you're only hoping it happened. Rollout says who sees the change first, how you turn it off, and what "bad" looks like on day one. A flag nobody owns won't get turned off when it should.

Open questions

Every open question needs an owner and a date, or it will block the build in week three. If a question doesn't change scope, acceptance or architecture, settle it in a comment.

A worked example

The example below is illustrative. The product is a small internal delivery tracker, and the numbers are the team's own targets for this exercise, not industry benchmarks.

Header. Title: Cycle report CSV for team leads. Owner: product. Status: approved. Reviewers: engineering, design, the support lead who handles "can you pull this number" requests.

Problem. Five team leads rebuild a Monday status slide by hand. They copy cycle name, ticket counts and a rough "are we on track" line into a deck. Percentiles and rollover notes get lost. A director replies with questions the slide cannot answer, and the lead spends another sitting in the tracker. Support receives a few of these requests each month when a director asks a lead who is out.

Outcome. Leads download one CSV for the current cycle and send that, or paste from it, instead of rebuilding the slide from memory. Success check: four weeks after rollout, at least three of the five leads have exported a cycle without filing a support request, and no support ticket reports a wrong total. If the check fails, the owner interviews the five leads before any second export format is considered.

Users. Primary: a team lead who already runs a cycle in the tracker and reports up once a week. Secondary: a director who will open the file and does not have a login. Not served: customers outside the company, and leads who want a slide deck generated for them.

Scope.

• From a cycle page, a lead with access can download a CSV of that cycle.
• Columns: ticket id, title, type, stage, owner, cycle day entered, rolled over (yes/no).
• The file includes tickets in the cycle at the moment of download.
• The filename contains the cycle name and the download date.
• A lead without access sees the existing no-access state, not a broken button.

Out of scope. PDF, slide export, scheduled email, historical comparison across cycles, charts, and any edit of ticket data from the file. A later idea, "email me this every Monday," is parked as its own backlog item and is not part of this release.

Story and rules. As a team lead, I want a CSV of the current cycle so that I can answer a director without retyping the board.

Rules: rolled-over tickets stay in the file and are marked yes. Tickets added after the cycle start are included and keep their real entry day. The export does not change ticket stage. The download is a snapshot, not a live link.

Acceptance examples.

1. Cycle "March 2" has 12 tickets, 3 of them rolled. The CSV has 12 data rows, 3 with rolled over = yes, and a header row in the column order above.
2. The same cycle has 0 tickets. The CSV contains only the header row. The button does not hide.
3. A member without lead access requests the URL directly. They receive the standard no-access response. No file is created.
4. A ticket moves stage while the file is generating. The row matches the stage at the start of the export. The file does not contain a duplicate row.

UX notes. The action sits with the other cycle actions and is labeled "Download CSV." While the file is built, the button shows a busy state and cannot be double-fired. Failure shows a short message and leaves the board usable. No new empty state is required beyond the header-only file.

Technical constraints. Read from the same cycle membership the board uses. Do not introduce a second definition of "in this cycle." The file is generated on demand. No new public API. Existing permission checks apply.

Analytics. Event cycle_csv_downloaded with cycle id, row count and whether the actor is a lead. The owner reads it weekly for four weeks. Support tags any "wrong total" ticket with the cycle id.

Rollout. Ship behind a flag to the five leads on day one. If any of them reports a wrong total, turn the flag off the same day. The engineering owner of the flag is named in the ticket. Expand to all leads only after the first week has no wrong-total report.

Open questions. None left at approval. An earlier question, "Do directors get a login?", was resolved: no, the file is the share.

That document runs to about one page, and it is specific enough to split into tickets: permission check, snapshot query, CSV shape, button states, flag, event. Each ticket can quote the acceptance example it covers. A definition of ready then decides when those tickets can enter a cycle, and a definition of done decides when each one is finished, including the flag and the event.

From document to tickets

A PRD that never turns into tickets is just a memo. Split the scope lines into the smallest stories that still ship a behavior you can check, carry the acceptance examples onto the tickets, and link every ticket back to the section it implements.

Keep a simple trace of section, ticket id and test. A five-ticket change doesn't need a heavy matrix, but you do need one when the work is audited or when many teams implement one policy. The requirements traceability matrix is the stricter form.

Put non-goals into the tracker as deferred items so they don't come back as surprise scope. If the document and the tickets disagree, the tickets are what will ship, so update the document the same day.

Confluence, Notion, Google Docs, Linear, Jira or a Markdown file in the repo can all hold the text. Pick a place reviewers will actually open. The editor matters much less than having a single source of truth.

Falrow keeps that narrative on the work itself, with ticket types, stages and triage, so a request can't skip the agreement and land straight in build. A well-kept board in another tracker does the same job if someone owns the rule.

PRD, spec, design and the agent brief

People use "PRD," "spec" and "one-pager" as if they were the same file, but each one does a different job.

The PRD document says why and what must be true. A product specification describes how the product behaves in more detail: fields, states, validation, edge cases. A technical design says how the system will implement that behavior. A design file shows layout and interaction. A ticket is the unit someone finishes inside a cycle.

If you only have time for one, write the PRD and put the acceptance examples in it. Add a product spec when the behavior is too dense for the narrative, such as billing rules or a public API. What goes where is covered in product specification vs PRD, and annotated samples of full documents are in PRD examples.

What changes when an agent will write the code

Agents follow what is written, and they also fill gaps. Every gap a model fills is a product decision you didn't make.

Before you hand a document to an agent, check four things: the out-of-scope list is explicit, the acceptance examples include at least one failure case, state names match the words already used in the product, and the constraints say which existing code or policy must not be reinvented.

Give the agent the document plus the repository, and tell it which sections may become a plan. A vague goal pasted into a prompt rarely produces a plan that matches your intent. Ask for a plan that quotes the acceptance example each task covers, and reject plans that add a non-goal because it was "easy."

Review the plan the way you would review a junior teammate's. Version the write-up when scope changes, so the agent isn't implementing last Tuesday's draft. Falrow runs that pattern inside the delivery loop: planning agents read the repo under the team's workflow rules, and writes are version-checked, which matters once the brief and the code can drift apart. The same discipline works in any setup where a human approves the plan before the agent edits code. How that loop runs is specific to Falrow, but the approval habit carries over anywhere.

How to review and approve

Review the document on screen in a meeting, or in an async pass with a deadline. Invite the engineer who knows the data, the designer who owns the flow, and the stakeholder who can expand scope. Useful comments point out a contradiction; "LGTM" doesn't move the document forward.

Run this checklist before status moves to approved:

• Problem names a person, a workaround and a cost.
• One primary success check has a date and a miss plan.
• Every scope line can become a ticket with a test.
• Non-goals include the ideas you are most tempted to add.
• Acceptance examples cover empty, forbidden and at least one race or partial failure.
• Rollout names a flag owner and a rollback trigger.
• Open questions are empty, or each has an owner and a date that falls before build.

Approval means "we will build this unless we change the document." The document isn't frozen after that; any change to it just has to be visible.

Keeping it true during the build

When scope changes, strike the old line, add the new one, and note the date and reason instead of rewriting history. When a ticket shows that a rule is wrong, stop, because either the ticket or the document is wrong. Fix the source before more tickets copy it. If this happens mid-cycle, move the corrected work into a reviewed rollover rather than quietly widening the current cycle.

After launch, record whether you hit the target, missed it, or couldn't measure it, plus what you did next. Mark a replaced file superseded and link the new one. Teams that delete old decisions tend to repeat them.

The usual failures are a solution pitch in the problem section, every line marked priority one, examples that only work in a demo, three copies of the rules, and no owner after kickoff. Fix those when you see them. A small team can keep each section short, write the failure examples with engineering, split tickets the same day, and approve on a deadline. If a rule matters, a test or a monitored event should mention it. Put debt in constraints or non-goals; a silent cleanup inside the feature is how scope explodes.

FAQ

How long should a product requirements document be?

One to three pages covers most product changes. A single cycle of well-understood work can fit on one page if the acceptance examples are concrete. Multi-team or regulated work runs longer because the rules and the trace are longer, not because the vision section grew. Past three pages, move exploration and meeting notes to an appendix and keep the decision up front.

What is the difference between a PRD and a product requirements template?

A product requirements template is the empty structure: the sections, the prompts and the checklist. A PRD is a filled document for one effort, with a named owner, a status and decisions. Reuse the template, but don't reuse an old PRD by search-and-replace. Its old non-goals and success checks will contradict the new problem, and reviewers will trust them because they look finished.

Who approves the PRD?

The owner approves it after the people who could break the plan have reviewed their sections. Engineering signs off on feasibility and constraints. Design confirms the flows and states are specified well enough to start. The stakeholder who controls scope approves the outcome and the non-goals. A single "approved by leadership" line with no functional review is how impossible commitments get into the cycle.

Should engineering start before the PRD is approved?

Engineers can spike unknowns that block the document, such as whether a query is affordable or whether an API already returns a field. They shouldn't build the release against a draft that is still changing scope. Label spikes as spikes, time-box them, and write the answer back into the open questions. Starting the full implementation early feels faster until the first contradiction shows up in review.

Where should the document live?

Put it where the people building will see it on the day they start, and link it from every ticket it spawns. A Markdown file in the repo works well when agents and humans both read the repo. A tracker description works when the work is small. A wiki page works when many non-engineering reviewers comment. Whatever you pick, keep one current copy and duplicate the link, not the text.