Nine sections, what belongs in each of them, and a weak and a strong version of every one so you can tell which you have written. Copy the blank template as Markdown — or skip the blank page and have the generator fill it in from your answers.
Markdown, so it pastes into whatever you write in.
# Product Requirements Document — <product name>
## 1. Overview
<one paragraph: what this is>
- Product type: <SaaS platform / marketplace / mobile app / internal tool / AI product / …>
## 2. Problem statement
<who is stuck, and on what>
Today, without this product: <the current workaround>
Why now: <what changed — a market shift, a new API, a regulation>
## 3. Target users
- Primary user: <a role, not a demographic>
- What they are trying to get done: <their goal, in their words>
- Also involved: <secondary users>
## 4. User stories
- <scope item> — as a <primary user>, so that I can <goal>.
## 5. Scope — release one
- <the shortest list that solves the problem above>
## 6. Out of scope
- <what you have decided NOT to build yet>
## 7. Success metrics
- <a number and a window>
Launch is done when: <the checklist you would accept as shipped>
## 8. Technical constraints
- Platforms: <responsive web / iOS / Android / desktop / API only>
- Integration: <each external system it has to talk to>
<hard technical, legal, budget or deadline limits>
## 9. Open questions
- <everything still undecided, written down instead of guessed at>
The headings are the easy half. These are the answers people get stuck on, with the version that reads well next to the version that reads like filler.
What is this, in one paragraph a stranger can follow?
One or two sentences and the product type. If a new engineer, a designer and an investor read only this section, all three should come away with the same idea of what is being built.
Who is stuck, on what, and how do they cope today?
Describe the pain, not the feature. Naming the current workaround is what proves the problem is real — if people are already solving it with a spreadsheet and three reminders, the problem exists. If there is no workaround at all, that is worth knowing before you build.
Who is the one person this is for, and who else touches it?
Name one primary user as a role, not a demographic, and say what they are trying to get done. A PRD listing five equal user types is a PRD nobody can prioritise against. Secondary users go in a separate line so they do not quietly become primary.
What does each scope item look like from the user's side?
One line per scope item, tying the capability to the primary user and the goal from section three. Their value is not the format — it is that a scope item which cannot be written as one usually turns out to be a technical task, not a user-facing feature.
What is being built now?
The shortest list that still solves the problem in section two. Every item should be traceable to it; anything that is not is a candidate for the next section. Aim to be embarrassed by how short it is.
What have you decided NOT to build yet?
The half that saves the project. Write down what you have agreed against, so nobody re-litigates it in week five and so a stakeholder can see their idea was heard and deferred rather than missed. An empty out-of-scope list almost always means the decisions have not been made.
How will you know afterwards whether it worked?
One or two, with a number and a window. A document with nine metrics has none, because nobody can act on nine. Pick the ones you would actually change the roadmap over.
What limits the build, and what does it have to talk to?
Platforms, integrations, and the hard limits — technical, legal, budget or deadline. Every integration is a dependency you do not control, so listing them early changes the estimate more than the feature list does.
What is still undecided?
The section most templates omit and most documents need. A PRD that admits three unresolved decisions is more useful than one that quietly invents answers for them — and it tells the reader exactly where their input is wanted.
The template above is Markdown, which is plain text — it pastes into Google Docs, Microsoft Word, Notion, Confluence, Linear or a repository README without anything in between. Google Docs converts the headings and lists back into formatting on paste when Markdown is switched on in its preferences; where it is not, the text arrives complete and takes a minute to style.
There is deliberately no .docx to download. A binary template is a second copy of this page that stops matching it the first time a section changes, and the thing people actually want — a document with their own answers already in it — is what the generator produces in one pass.
One formatting note for Word: keep the numbered headings as headings rather than as bold body text. Word's navigation pane and table of contents both read the heading styles, and a fifteen-page PRD nobody can navigate is read once and never again.
Book a free founder call. We'll help you figure out what to build first, what it'll cost, and how fast we can launch it.
Limited availability — email alex@shipkit.us or use the contact page to start the conversation.