A good PRD (product requirements document) has ten parts: problem, goal and success metric, users, scope, out of scope, user stories, acceptance criteria, dependencies, risks and open questions and timeline. Keep it short, write acceptance criteria anyone can test, and list what is out of scope. Copy the free template and the filled-in example below.
Most rework doesn't start in code. It starts in a requirement nobody wrote down clearly. A one-page PRD that everyone reads beats a twenty-page document nobody opens.
What is a PRD?
A PRD explains what you are building and why, so designers, developers, QA and the client agree before work starts. It doesn't explain how to build it. That belongs in the technical design.
Free PRD template
Copy this structure into Google Docs, Notion, Confluence or Word. Each section answers one question your team will otherwise ask you later.
| Section | The question it answers | Tip |
|---|---|---|
| 1. Problem | What is broken or missing today, and for whom? | Use a real complaint or number, not an opinion |
| 2. Goal and success metric | How will we know it worked? | One measurable number |
| 3. Users | Who uses this feature? | Name roles, not "everyone" |
| 4. Scope | What exactly is included? | A short bullet list |
| 5. Out of scope | What are we not doing now? | The section that prevents most arguments |
| 6. User stories | What does each user need to do? | "As a [role], I want [action] so that [benefit]" |
| 7. Acceptance criteria | When is each story done? | Testable: QA can say pass or fail |
| 8. Dependencies | What do we need from others? | APIs, client inputs, other teams, approvals |
| 9. Risks and open questions | What could go wrong, and what is still unknown? | Give each open question an owner and a date |
| 10. Timeline | When are the milestones? | Dates, not "soon" |
Write "Out of scope" first. Clients and stakeholders add requests mid-sprint. A written out-of-scope list turns "can you also add…" into a clear new request with its own effort and date.
PRD example: GST invoice export
Here is the template filled in for a real-world feature: letting customers of a billing app export GST invoices.
Problem
Accountants email support every month asking for invoices in bulk. Support exports them by hand, about 40 requests a month.
Goal and success metric
Customers export invoices themselves. Success: bulk-export support requests drop by 80% within two months of release.
Users
Account owners and accountants with the Finance role.
Scope
Export invoices for a selected date range as one ZIP of PDFs, plus a CSV summary with GSTIN, invoice number, date, taxable value, CGST, SGST and IGST.
Out of scope
Direct filing to the GST portal, Tally export and scheduled automatic exports. These are for a later release.
User story
As an accountant, I want to download all invoices for a month in one click so that I can file GST returns without asking support.
Acceptance criteria for that story:
- The user can pick a start and end date, up to 12 months apart.
- The export contains one PDF per invoice and one CSV summary.
- CSV totals match the sum of the invoices in the date range.
- Exports of up to 2,000 invoices finish within 2 minutes; larger exports are emailed as a link.
- Users without the Finance role don't see the export button.
Dependencies: the PDF service must support batch generation. Open question: should cancelled invoices be included? Owner: product lead, answer by Friday. Timeline: design by the 10th, build by the 24th, release on the 1st.
Common PRD mistakes that cause rework
- Acceptance criteria like "should be fast" or "easy to use", which nobody can test.
- No out-of-scope section, so every new idea becomes "part of the feature".
- Describing the solution in detail but never the problem.
- Open questions with no owner, which are still open on release day.
- Updating the requirement in chat instead of in the PRD, so QA tests the old version.
Unclear requirements show up later as reopened tasks. When the same ticket keeps going from "Done" back to "In Progress", the problem is usually the PRD, not the developer.
PRD vs BRD vs FRD
| Document | Focus | Usually written by |
|---|---|---|
| BRD (business requirements) | The business need and expected outcome | Business analyst or client |
| PRD (product requirements) | What the product or feature must do, and for whom | Product manager |
| FRD (functional requirements) | Detailed system behaviour, rules and validations | Business analyst or tech lead |
Small teams and agencies often combine all three into one PRD. That's fine, as long as scope and acceptance criteria are clear.
Write a PRD from rough notes in a minute
RestMic Studio is a free tool that turns rough meeting notes or a client email into a clear product plan (PRD), user stories or test cases. No sign-up needed. Review it, edit it, and share it with your team.
Once work starts, RestMic watches how tasks actually move and flags the early signs of a requirement problem: tasks that keep getting reopened, work that has stopped moving and scope that keeps growing. That's project intelligence: knowing a project is at risk before the deadline tells you.
Frequently asked questions
What should a PRD include?
The problem, the goal and success metric, the users, the scope, what is out of scope, user stories, acceptance criteria, dependencies, risks and open questions, and the timeline.
How long should a PRD be?
For most features, one to two pages. If a PRD is much longer, split it into smaller features or move technical details into a separate design document.
Who writes the PRD?
Usually the product manager. In agencies and small teams, it is often the project manager, business analyst or founder, with input from the tech lead and QA.
What is the difference between a PRD and user stories?
A PRD is the full document for a feature: problem, goal, scope and more. User stories are one section of it, describing what each user needs to do.
Is there a free PRD generator?
Yes. RestMic Studio turns rough notes into a product plan (PRD), user stories or test cases for free, without sign-up.
Turn your notes into a PRD in under a minute
Paste your rough requirements into RestMic Studio and get a clear product plan. Free, no sign-up.
Try RestMic Studio