A PRD template you can copy, in four formats.
Classic
[Feature name]
Author · Date · Status: draft / in review / approved
1. Problem
What is broken today, for whom, and how often. One paragraph. If you cannot name the person who has this problem, stop writing and go find them.
2. Customer evidence
Quotes, ticket counts, survey verbatims. Group them into themes and count each theme. This is the section that turns the rest of the document from an opinion into a decision.
3. Proposed solution
What you will build, described closely enough that an engineer can picture it. Cover the happy path and the one edge case that actually matters.
4. Success metric
One number, its value today, and the value that would make this worth building. "More engagement" is not a metric.
5. Scope
What ships in the first release. A list, not a paragraph.
6. Non-goals
What you are deliberately not doing, and why. This section prevents more rework than any other.
7. Open questions
What you still do not know, who will answer it, and by when.
Lean one-pager
[Feature name]: one-pager
Problem
One sentence. Who is stuck, and on what.
Evidence
Two or three lines. A count, a quote, a number from your own data.
Solution
Two or three sentences. What changes for the user.
Success metric
One number and the threshold that makes this worth doing.
Not doing
Three bullets. The things a reader would otherwise assume are included.
Amazon PR/FAQ
[Product name]
Press release
Headline
One line a customer would understand without context.
Sub-heading
Who it is for and what it lets them do.
The problem
A paragraph describing the world before this exists.
The solution
A paragraph describing how it works, in plain language.
Customer quote
What a real user would say after using it. If you cannot write one that sounds like a person, the value is not clear enough yet.
Getting started
The first thing a customer does.
Customer FAQ
The questions a user will ask. Pricing, limits, migration, privacy.
Internal FAQ
The questions your own team will ask. Cost, risk, what happens if adoption is low, what we are betting on.
For AI coding agents
[Task]
Context
What exists today, and where in the codebase. Name files and modules, not concepts.
Acceptance criteria
A numbered list of statements that are either true or false when the work is done. No adjectives.
Out of scope
What the agent must not touch. Be specific: this is the section that prevents a 40-file diff.
Files and interfaces
The files expected to change, and any public signature that must not break.
Verification
The exact command that proves it works, and what passing output looks like.
What a product requirements document is for
A product requirements document states what you are building, who it is for, and how you will know it worked. It exists so that engineering, design and leadership can disagree on a written page instead of discovering the disagreement three weeks into the build.
A PRD is not a spec and not a project plan. It does not describe implementation, and it does not hold dates. Keep it to the decision and the evidence behind it; the ticket tracker holds the rest.
The length that works is shorter than most people expect. A classic PRD runs 800 to 1,500 words. A lean one-pager runs 300 to 500. If yours is longer, the extra words are usually implementation detail that belongs in a ticket, or hedging that belongs in Open questions.
Which PRD template to use when
Pick the variant that matches the size of the decision, not the size of the feature. A change two people already agree on needs a one-pager. A change that reshapes pricing or onboarding needs the classic format, because Non-goals and Open questions are where that argument gets settled.
Copy the template above and fill it top to bottom. The order matters: problem before solution, evidence before scope. Writing the solution first is how teams end up with a document that justifies a decision already made.
| Variant | Length | Audience | Use it when |
|---|---|---|---|
| Classic | 800–1,500 words | Engineering, design, leadership | The decision is contested, or the work spans more than one team |
| Lean one-pager | 300–500 words | Your immediate team | Everyone already agrees and you need the scope written down |
| Amazon PR/FAQ | 600–1,200 words | Leadership, go-to-market | You are testing whether the value is explainable before building it |
| For AI coding agents | 200–600 words | Cursor, Claude Code, Codex | You want an agent to implement it without inventing scope |
The section most PRDs get wrong
Customer evidence is the section that decides whether the document is worth reading, and it is the one most templates leave as a single empty heading.
Evidence is not "customers have asked for this". Evidence is a count, a segment and a quote: how many people raised it, which kind of customer they were, and what they actually said in their own words. Three verbatim quotes from paying customers change a roadmap conversation in a way that a summary sentence never does.
The practical problem is that the evidence is scattered. It sits in support tickets, in sales-call notes, in a Slack channel somebody muted, and in a survey export nobody reopened. Most PRDs skip the section because collecting it by hand costs an afternoon, not because the author thinks it is unimportant.
That is the step Sleekplan removes. Feedback arrives from the widget, the portal and your support tools onto one board. Sleekmate reads it, groups the related posts and drafts the PRD as a document in the workspace, linked to every post it came from. The evidence section is filled before you start writing, and a reviewer can click through to the original requests.
How to write a PRD
Write the problem before anything else
Name who is stuck, on what, and how often. Be specific enough that a reader could go and find that person. A problem statement that works for any feature, say "users want a better experience", is a sign you have started from the solution and are reverse-engineering a justification for it. If you cannot write the problem without naming the feature, you do not have one yet.
Collect the evidence before you propose anything
Pull the support tickets, sales notes and survey verbatims that touch this problem. Group them into themes and count each theme. Two or three direct quotes carry more weight in a roadmap review than any summary you could write. This step is the one teams skip, and it is the one that decides whether the document survives its first challenge.
Propose one solution, not three
A PRD is a decision, not a menu. If you are genuinely torn between two approaches, put the alternative under Open questions with what would settle it, not in the body as a parallel proposal. Describe the solution closely enough that an engineer can picture the happy path, and stop before implementation detail. How it gets built belongs in a technical spec written afterwards.
Pick one number
State the metric, its value today, and the value that would make the work worth doing. "Increase engagement" fails all three tests. "Share of workspaces above 50 seats that export monthly: 0% today, worth building at 25%" passes, because in two quarters someone can check it. A PRD without a falsifiable number cannot be wrong, which means it also cannot be right.
Write down what you are not doing
Non-goals prevent more rework than any other section. List the things a reasonable reader would otherwise assume are included: the adjacent format, the scheduled version, the admin setting. Say why each is out. Then list what you still do not know, who will answer it, and by when. An honest open question is worth more to a reviewer than a confident sentence nobody verified.
Questions people ask
What is the format of a PRD?
A PRD is a text document, usually seven sections: problem, customer evidence, proposed solution, success metric, scope, non-goals and open questions. There is no standard file format. Markdown, a Google Doc or a Confluence page all work, and the choice matters far less than whether the evidence section is filled in.
How do I write a PRD?
Write it in this order: problem, then evidence, then solution, then metric, then what you are not doing. Writing the solution first produces a document that justifies a decision you already made. Expect 800 to 1,500 words for a classic PRD and 300 to 500 for a one-pager; anything longer is usually implementation detail that belongs in a ticket.
What should be included in a PRD?
Problem, customer evidence, proposed solution, success metric, scope, non-goals and open questions. Non-goals prevent more rework than any other section, because they catch the assumptions a reader would otherwise make silently. Leave a section marked open rather than filling it with something you have not verified.
What are common PRD mistakes?
Three recur. Writing the solution before the problem. Leaving customer evidence as an empty heading or a vague "customers have asked for this" instead of counts, segments and verbatim quotes. And omitting non-goals, which is what turns a two-week build into a six-week one when a reviewer assumes something was in scope.
Is a PRD the same as a spec?
No. A PRD states what to build and why, and stops before implementation. A technical spec states how, and is usually written afterwards by whoever will build it. Teams that merge the two end up with a document that is too detailed for leadership and too vague for engineering.
Your roadmap,
on autopilot.
Free for 30 days. No card, no sales call. Cancel anytime.