Free PRD template with examples for every industry

The template

Copy it, fill it, ship it.

What are you building?

Your industry

Fill it in with AI

Open in Claude

Open in ChatGPT

PRDDraft

[Feature name]

Owner: [Name]
Status: Draft · In review · Approved
Last updated: [Date]

1. Overview

One or two sentences: what we're building and why now.

2. Problem and evidence

What problem are customers having? Link every claim to its evidence: calls, tickets, Slack threads, deals.

[Evidence 1: source and link]
[Evidence 2: source and link]

3. Goals and success metrics

Goal: [what changes for the customer]
Metric: [how you'll know, with a target]

4. Users and use cases

As a [role], I want [action] so that [outcome].
As a [role], I want [action] so that [outcome].

5. Requirements

Must: [requirement]
Should: [requirement]
Won't (this time): [requirement]

6. Out of scope

What this project deliberately does not cover, so nobody assumes it does.

7. Design notes

Link mock-ups and describe the key screens or flows.

8. Technical notes and estimate

Systems touched, dependencies, risks, and a size estimate (S / M / L) with a range.

9. For AI coding agents

Acceptance criteria: [testable statements]
Files and services to start from: [paths]
Constraints: [what not to change]

10. Open questions and decisions

Question: [open question] (owner, due date)
Decision: [what was decided, by whom, when]

11. Launch plan

Rollout steps, who needs to know, and which customers to tell when it ships.

Template versions

A PRD template for what you're building.

Pick what you're building and your industry, and the template adds the sections that matter. Then open it in Claude or ChatGPT to fill it in.

PRD template for a mobile app

Changes the technical notes and launch plan, and adds a mobile release checklist:

Platforms: iOS and Android minimum versions, phones and tablets
Offline: what works without a connection, and how it syncs
Permissions and push: what you ask for, and when
App store review: new permissions, privacy labels, screenshots
Release: phased rollout, feature flag, forced update

PRD template for a backend service

Changes the technical notes and launch plan, and adds a service levels and operations:

Service levels: latency, uptime and error-rate targets
Contract: requests and responses, versioning, backward compatibility
Dependencies: upstream and downstream services
Failure modes: what happens when a dependency is slow or down
Operations: dashboards, alerts, on-call owner, rollback

PRD template for payments

Changes users, goals and requirements, adds payments and compliance, and comes with a filled example: Saved cards at checkout.

Money flow: who pays whom, when, in which currencies
Compliance: PCI DSS scope, strong customer authentication, KYC
Failures: declines, retries, idempotency keys
Refunds and disputes: full and partial refunds, chargebacks, evidence
Reconciliation: ledger, settlement reports, finance sign-off

PRD template for healthcare

Changes users, goals and requirements, adds patient safety and compliance, and comes with a filled example: Appointment reminders by text.

Patient data: what health information is stored, shown or sent
Compliance: HIPAA, signed agreements with every vendor, regional rules
Access and audit: who can see what, and how access is logged
Clinical safety: what happens if data is wrong, late or missing
Regulation: could this count as a medical device? Who confirmed it?

PRD template for marketplace

Changes users, goals and requirements, adds marketplace balance and trust, and comes with a filled example: Saved-search alerts.

Both sides: what changes for buyers, and for sellers
Liquidity: where supply or demand is thin, and how this helps
Trust and safety: fraud, reviews, moderation, disputes
Fees and payouts: take rate, payout timing
Rollout: which categories or regions first

What is a PRD?

The document that says what to build and why.

A product requirements document (PRD) describes a feature before it's built: the problem it solves, who it's for, what it must do, what's out of scope and how you'll measure success. Engineers use it to build the right thing, designers to shape it, and leaders to agree on priorities. With AI coding agents doing more of the building, a good PRD also needs testable acceptance criteria and pointers to the code, because agents can only build what the document makes clear.

How to write a PRD

Six steps, from evidence to sign-off.

1
Start from evidence
Collect what customers actually asked for: calls, tickets, Slack threads and lost deals. Count them.
2
Write the problem, not the solution
Describe the customer's problem in two sentences, and link each claim to its source.
3
Set a goal you can measure
One outcome and one metric with a target, so you'll know if it worked.
4
List requirements by priority
Must, should and won't. Say what's out of scope as clearly as what's in.
5
Make it buildable
Add technical notes, an estimate, and acceptance criteria an engineer or AI agent can test against.
6
Record decisions and get sign-off
Note open questions with owners, log decisions as they're made, then share for approval.

Skip the blank page

Let Devplan write the PRD from your customer feedback.

Devplan finds what customers keep asking for in calls, tickets and Slack, and drafts the PRD from your code. Every line links to its source.

Start free See how it works

01
Hear
Calls, tickets and Slack
02
Group
17 customers, one request
03
Draft
PRD with sources
04
Ground
Code context and estimate
05
Hand off
Tickets or AI agents

Questions

PRDs, answered

What does PRD stand for?

PRD stands for product requirements document. It describes what a feature or product should do, who it's for and why it matters, so a team can build it.

What should a PRD include?

An overview, the problem with its evidence, goals and success metrics, users and use cases, prioritized requirements, what's out of scope, design notes, technical notes with an estimate, open questions and decisions, and a launch plan. If AI agents will build it, add acceptance criteria and the files to start from.

How long should a PRD be?

As short as possible while still answering what, why, for whom and how you'll know it worked. For most features that's one to three pages. Link to evidence and designs instead of pasting them in.

What's the difference between a PRD and a technical spec?

A PRD explains what to build and why, from the customer's side. A technical spec explains how it will be built: systems, data and trade-offs. Devplan drafts both, from the same customer evidence and your code.

Is there a PRD template for mobile apps, payments or healthcare?

Yes. Pick what you're building (web app, mobile app or backend service) and your industry (payments, healthcare or marketplace), and the template adapts: users, goals, requirements, technical notes and launch plan change, and a checklist for that case is added. Each industry has its own filled example.

Who writes the PRD?

Usually the product manager, with input from engineering, design and anyone who talks to customers. The PM owns it; the team reviews it before work starts.

Can AI write a PRD?

Yes, if it starts from real evidence rather than a blank prompt. Devplan drafts PRDs from what customers asked for across calls, tickets and Slack, grounds them in your code, and links every claim to its source, so you edit instead of starting from scratch.

Do you still need a PRD if AI agents write the code?

More than ever. AI coding agents build exactly what they're told, so the requirements, constraints and acceptance criteria need to be clear and written down. That's why this template has a section for AI coding agents.

A free PRD template your team and AI agents can build from.