# Product Requirements Document (PRD) Template

Source: https://www.innovation-insight.com/templates/prd-template (Innovation Insight, updated 2026-10-09). Free to use and change.

## How to use this template

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.

Replace every ____ with your own text. Delete the guidance line under each heading once the section is written. Lines starting with [ ] are checkboxes.

## 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: ____

## Related

- MVP development company: https://www.innovation-insight.com/mvp-development-company
- MVP development cost: https://www.innovation-insight.com/blog/mvp-development-cost
- UI/UX design: https://www.innovation-insight.com/services/ui-ux-design
- App development cost calculator: https://www.innovation-insight.com/app-development-cost-calculator
- Software development RFP template: https://www.innovation-insight.com/templates/software-rfp-template