Reviewed by Zain Khalid MalikCTO & Co-founder, Innovation Insight·Updated Short answer
A product requirements document (PRD) states the problem, who has it, what the first release must do and how you will know it worked. This PRD template has twelve sections: problem statement, goals and non-goals, users and jobs to be done, user stories with Given/When/Then acceptance criteria, MVP scope versus later, requirements tables, UX flows, data and integrations, metrics, risks and a release plan. It is Markdown, so it works in a repository and as context for AI coding tools.
How to use this product requirements document template
Write the problem statement and the non-goals first. They are the two sections most PRDs skip and the two that stop a build from growing sideways. Then write user stories with acceptance criteria before you touch the requirements tables; the tables fall out of the stories. Keep the whole document under ten pages. A PRD that nobody rereads is worse than none, because people assume it is current when it is not. Store it next to the code, in Markdown, and update it in the same pull request as the behaviour it describes.
The PRD is not a design document and not a project plan. Architecture, stack and estimates belong elsewhere; the PRD says what the product must do and why. When we scope an MVP, the PRD is the input to the estimate, and MVP development cost explains how scope in this document turns into a price.
Using the PRD template with AI coding tools
A PRD written for Claude Code, Cursor, Lovable or Bolt is the same document with three habits enforced. Be explicit: name the entities, fields, states and error cases rather than implying them. Be short: a tool reads the whole file every time, so long preambles cost context and attention. Give every story acceptance criteria in Given/When/Then form, because that is what the tool will turn into tests and what you will check its output against. Put the PRD in the repository, reference it from the tool's instruction file (CLAUDE.md, .cursor/rules or the project prompt), and mark sections as done as they ship so the tool stops rebuilding them. Our comparison of Lovable, Bolt and v0 shows how far each gets from a well-written PRD and where an engineer has to take over.
PRD template in Markdown
The download is plain Markdown: headings, bullet lists and tables, no front matter or tool-specific syntax. It renders in GitHub, Notion, Obsidian and every AI tool. Copy it to docs/prd.md, fill in the sections, delete the guidance lines, and commit. If you prefer a document editor, paste it into Google Docs and the headings carry over.
Common PRD mistakes
- Solutions dressed as requirements. "Add a Redis cache" is a design decision; the requirement is "search results return in under 500 ms at 1,000 concurrent users".
- No non-goals. Every reader fills the gap with their own assumptions, and the backlog doubles.
- Acceptance criteria that say "works correctly". If a tester cannot mark it pass or fail, it is not a criterion.
- Every feature marked must-have. If nothing is deferred, there is no MVP, only a long project.
- No metric. Without a number to move, the launch cannot be judged and the next release cannot be prioritised.
For design input, see our UI/UX design service; the UX notes section below is where the two documents meet.
Free download
Get the Product Requirements Document (PRD) Template
Markdown that opens anywhere (Google Docs, Notion, GitHub, your AI coding tool) or a Word file. Tell us where to send it and a senior engineer will answer any question you add.
Just want the file? Download Markdown without the form or the Word version.
The template
Every section below is in the download. Replace each blank line with your own text and delete the guidance paragraph once you have written the section.
1. Problem statement
One paragraph on the problem, who has it, how they cope today and what it costs them. No solution yet. If you cannot state the problem without naming the feature, keep rewriting.
- Who has the problem: ____
- What they are trying to do: ____
- What gets in the way today (current workaround): ____
- Cost of the problem (time, money, churn, risk): ____
- Evidence (interviews, support tickets, analytics, sales notes): ____
2. Goals and non-goals
Three goals at most, each with a measurable target. Non-goals are things a reasonable person might expect this release to do and it deliberately will not. They are the most useful lines in the document.
- Goal 1 and target: ____
- Goal 2 and target: ____
- Goal 3 and target: ____
- Non-goal: ____
- Non-goal: ____
- Non-goal: ____
3. Users and jobs to be done
Each user type, the job they hire the product for, and the situation that triggers it. Roles here become permissions later, so list all of them including admins and support staff.
- User type: ____ | job to be done: when ____, I want to ____, so I can ____
- User type: ____ | job to be done: ____
- User type: ____ | job to be done: ____
- Primary user for this release: ____
- Roles and permissions summary: ____
4. User stories with acceptance criteria
One story per outcome, with Given/When/Then criteria that a tester (or a coding tool) can turn into pass or fail checks. Include the unhappy paths: invalid input, no network, expired session, empty states.
- US-1: As a ____, I want to ____ so that ____.
- Given ____, when ____, then ____.
- Given ____ (error case), when ____, then ____.
- US-2: As a ____, I want to ____ so that ____.
- Given ____, when ____, then ____.
- US-3: As a ____, I want to ____ so that ____.
- Given ____, when ____, then ____.
- Priority for each story: must / should / could
5. Scope: first release (MVP) vs later
Draw the line. The first release is the smallest set of stories that lets the primary user complete the main job end to end and lets you measure the goal. Everything else is listed under later so it is not lost and not built yet.
- In the first release (story IDs): ____
- Release 2 candidates: ____
- Someday / needs validation: ____
- Explicitly never (moves to non-goals if firm): ____
6. Functional requirements
Specific behaviours the system must have, each with an ID, a priority and the story it supports. Use these to track coverage: every must-have requirement maps to at least one story and one test.
- Numbering: FR-1, FR-2 ... Keep each line to one behaviour.
| ID | Requirement | Priority | Story | Notes |
|---|---|---|---|---|
| FR-1 | ____ | must | US-1 | ____ |
| FR-2 | ____ | must | US-1 | ____ |
| FR-3 | ____ | should | US-2 | ____ |
| FR-4 | ____ | could | US-3 | ____ |
7. Non-functional requirements
Numbers for performance, availability, security, privacy, accessibility, localisation and supported platforms. These decide architecture, so vague entries here cause expensive changes later.
- Performance (page load, API latency at expected load): ____
- Availability target and maintenance window: ____
- Security (authentication method, MFA, encryption, audit log, session rules): ____
- Privacy and compliance (GDPR, HIPAA, PCI DSS, data residency, retention): ____
- Accessibility standard (e.g. WCAG 2.2 AA): ____
- Platforms and browsers: ____
- Localisation (languages, currencies, time zones): ____
- Scale assumptions (users, records, requests) for the first year: ____
8. UX notes and flows
Link the wireframes or prototype and describe the main flows step by step. Note empty, loading and error states, because they are what gets forgotten. Do not specify visual design here; reference the design file.
- Design file or prototype link: ____
- Flow 1 (name): step 1 ____ > step 2 ____ > step 3 ____
- Flow 2 (name): ____
- Empty states: ____
- Error and offline states: ____
- Notifications and emails sent by the system: ____
- Copy and tone notes: ____
9. Data and integrations
The main entities and their key fields, where data comes from and goes to, and every third-party service. Name the API, the auth method and who owns the account.
- Entities and key fields (e.g. Order: id, customer, items, status, total, created_at): ____
- Entity relationships in one or two lines: ____
- Data sources to import or migrate: ____
- Integration: ____ | API: ____ | auth: ____ | owner: ____
- Integration: ____ | API: ____ | auth: ____ | owner: ____
- Data retention and deletion rules: ____
10. Analytics and success metrics
The metric from the goals, the events needed to compute it, and the baseline today. If an event is not listed here, it will not be instrumented.
- Primary metric and target: ____
- Baseline today: ____
- Events to track (name, properties, trigger): ____
- Dashboards or reports needed at launch: ____
- Review date for the metric after launch: ____
11. Risks and open questions
What could stop this working, how likely it is, and what you will do about it. Open questions each get an owner and a date; an unowned question stays open until it becomes a bug.
- Risk: ____ | likelihood: ____ | impact: ____ | mitigation: ____
- Risk: ____ | likelihood: ____ | impact: ____ | mitigation: ____
- Open question: ____ | owner: ____ | needed by: ____
- Open question: ____ | owner: ____ | needed by: ____
- Dependencies on other teams or vendors: ____
12. Release plan
How the first release reaches users: environments, rollout (internal, beta, percentage, everyone), what must be true to proceed at each step, and how you roll back.
- Milestones and target dates: ____
- Rollout stages and entry criteria: ____
- Launch checklist (monitoring, support docs, legal, app store review): ____
- Rollback plan: ____
- Owners: product ____ | engineering ____ | design ____ | QA ____
- Document status: draft / reviewed / approved | last updated: ____
Filled it in?
Send us the document and get a written estimate.
A senior engineer replies within one business day with the assumptions we would make and a range per milestone.
Zain Khalid Malik
CTO & Co-founder, Innovation Insight
Zain owns architecture, engineering standards and the platform team at Innovation Insight. He sets the bar for code quality, security and the tooling every squad ships with.
LinkedIn