PRD template
The short answer
A PRD (product requirements document) sets out what to build and why. A PRD template gives you the sections: the problem in the customer's words, the evidence, what becomes true, what is in and out, how you will know it is done, and what is still open. This one is short enough for a person and exact enough for a coding agent. Annsa keeps the same parts on every priority.
A PRD (product requirements document) is a document that sets out what to build and why: the problem, who has it, what becomes true and how you will know it is done. A PRD template gives you those sections to fill in, before anyone builds.
TL;DR
- Start from the problem in the customer's own words, with who said it.
- Say what becomes true, what is in, and what is not.
- Write Done When lines that someone (or an agent) can check, one by one.
- Keep open questions and decisions on the page. A guess hidden in a PRD gets built.
When to use it: a new capability, a change several people or agents will touch, or anything where the decision is not settled. When not: a bug, a copy fix or a small clear change. A one-paragraph spec is enough there (see below).
This is a short template. For what a PRD is and how it differs from a spec, read How to write a product requirements document. This page is the part you paste.
A PRD template to paste
Copy it, fill the brackets, delete what you do not need. Keep the headings: they are what a person scans and what an agent finds.
# <Title: what becomes true, in a customer's words>
## Problem
<1-2 sentences. What hurts, for whom.>
> "<their exact words>" (<name or account>, <where, when>)
## Evidence
- <account or person> (<plan or revenue>): <source>
- How many in the last <period>: <number>
## The bet it serves
<which goal this moves>
## What becomes true
<The outcome, present tense. Then the direction in a line.>
## In scope
- <item>
## Not in scope
- <near neighbor you will not build>
## Done When
- Given <state>, when <act>, then <something checkable>.
- Given <state>, when <act>, then <something checkable>.
## Already decided
- <decision> because <reason in a few words>
## Open questions
- <question> (<who answers>, <by when>). If you reach this while building, stop and ask.
## Where to look
- <file or area> (only if you know)
- Rules: AGENTS.md
What goes in each part?
Title. Say what becomes true, in words a customer would use: "Pause a subscription instead of canceling". Not "Subscription pause v2".
Problem, in their words. One or two sentences, then a quote. A quote keeps you honest: it is what was said, not what you remember. If you have no quote, say so. That is useful to know.
Evidence. Names or accounts, with how many and what they pay if you know. One loud user and five quiet ones are different jobs. This is the line that tells you whether the work is worth doing.
The bet it serves. Which of your goals this moves. If it serves none, that is your answer. (In Annsa a bet is a goal you set and order; priorities are ranked inside it.)
What becomes true. The outcome, in the present tense, for the customer or for you. Direction after outcome: "Customers can pause for up to three months, and billing stops while paused."
In scope and not in scope. The not-in-scope list does the most work. Every line you write there is a build an agent will not wander into. Name the near neighbors, not far-off ideas.
Done When. Each line is a check someone can run: "Given a paying customer, when they choose Pause for 2 months, then no invoice is created for those 2 months." Avoid "works well" and "is fast". One line, one check. These are what acceptance criteria look like for an agent.
Already decided. The calls you have made, so nobody reopens them mid-build. Include the reason in a few words.
Open questions. What you do not know yet, and who will answer. If an agent hits one, it should stop and ask, not guess.
Where to look. The files or areas of the code you already know are involved, and the rules file (AGENTS.md) to read first. Skip it if you do not know. A wrong path is worse than none.
An example, filled in
This is an example, made up to show the level of detail. It is not a real Annsa feature.
Pause a subscription instead of canceling
Problem. Customers who leave for a quiet few months have only one option: cancel and sign up again later, which loses their settings. "We're slow until March. I don't want to cancel and lose everything." (Dana, Northbeam Studio, support chat, 3 Oct)
Evidence. Three accounts in five weeks: Northbeam Studio ($49 a month), Fieldnote ($99) and Tallow & Co ($49). Two others canceled in the same period and gave "seasonal" as the reason. Source: the support inbox and two cancel surveys.
Bet it serves. Keep the customers we already have.
What becomes true. A customer can pause for 1 to 3 months. Billing stops while paused, their data stays, and the account comes back by itself on the date they chose.
In scope. A Pause button in billing settings. A chosen return date. A reminder email 3 days before the account resumes.
Not in scope. Partial refunds. Pausing individual seats. Pausing annual plans. Changing the cancel flow.
Done When.
- Given a customer on a monthly plan, when they choose Pause for 2 months, then no invoice is created for those 2 months.
- Given a paused account, when a member signs in, then they can see their data and a banner with the return date, and cannot create new items.
- Given a pause that ends today, when the daily billing job runs, then the account is active again and billed once.
- Given a customer who pauses, when 3 days remain, then one reminder email is sent to the account owner.
- Given a customer on an annual plan, when they open billing settings, then there is no Pause button.
Already decided. Maximum 3 months, because longer pauses were not asked for. No fee, because a fee would send people to cancel.
Open questions. Does a paused account count toward a seat limit? (Cat, before build starts.)
Where to look. billing settings page and the daily billing job. Rules are in AGENTS.md.
Notice what is missing: no personas, no timeline, no mock-ups. If the job needed them, they would be here. If it did not, they are noise.
When is a PRD overkill?
Often. A PRD is for a decision. If the decision is already made, you need a spec, not a PRD.
Use a paragraph when:
- It is a bug, a copy change or a small, clear improvement.
- One person or one agent will do it.
- You could explain it in a message.
A paragraph that works: "Customers on annual plans see a Pause button that does nothing. Hide it for annual plans. Done when an annual customer opens billing settings and sees no Pause button, and a monthly customer still does." That is a spec: the problem, the outcome and a check. See what a product spec is and writing a spec.
Use the full template when the answer to "what should we do?" is still open, when it will take more than a few days, or when people and agents will each take a piece.
Does it work when an agent reads it?
Yes, if you write it so a reader with no memory of your last conversation could act on it. Four habits help:
- Done When lines it can check. Not "good performance". A number, a state, a result.
- Not in scope, written out. An agent that is not told where the edge is will cross it.
- Open questions marked. Say "stop and ask if you reach this".
- Where the rules live. Point to AGENTS.md. The PRD says what to build; the rules file says how your team builds.
There is more on this in How to write a PRD for Claude Code and giving agents product context.
How does Annsa help?
Annsa is the source of direction for your agents, and every priority carries the parts of this template.
- Problem and evidence. Requests come in from Slack, Intercom, call transcripts, surveys, CSV and Google Sheets imports, GitHub, the API or by hand. Each keeps the customer behind it, their exact words, the account and its revenue, and matching requests are grouped.
- The bet. You set your bets and their order. Annsa ranks priorities inside them: what a person marked broken first, then what customers asked for, then ideas. You choose; Annsa never decides for you.
- The spec. It holds the why, the evidence and Done When lines. You write it, your agent writes it over MCP, or Ask writes it.
- Done When, checked. Claude Code, Cursor, Codex and Grok connect over MCP, read the spec and record evidence against each Done When line.
- Telling people. When the job ships, Share Back drafts a note to each person who asked. You send it.
See the spec and priorities.
Sources: Product requirements document, Wikipedia. PRD template, HashiCorp, an example of a problem-first template used inside a company.