A product requirements document template is a one-document outline of what you're building and why: purpose, goals, assumptions, requirements and what's out of scope. Atlassian says a PRD defines a product's purpose, features, functionality and behaviour, and gives cross-functional teams a single source of truth.
You don't need to run a software company to need one. If you're launching an app, a membership area, a client portal or a new feature on your site, and more than one person's working on it, a PRD stops everybody building from a different picture in their head.
The sections below follow Atlassian's two pages on the subject, as of Nov 2026: its guide to requirements and the steps for its own template. The advice on length and what to cut is mine, and I've labelled it as my view.
What each section does
This table is the template. Atlassian's guide says its sections give "just enough" context to understand a project's requirements and their impact on users, and that phrase is the spirit to keep in mind as you fill it in.
| Section | What to write | Why it's there |
|---|---|---|
| Project basics | Participants, current status and target release date | Anyone opening it can see who's involved and where things stand |
| Objective | A brief explanation of how this supports the organisation's larger goals | Atlassian's question: why should this exist in the first place? |
| Success metrics | Specific goals and the measure you'll use for each | You'll know afterwards if it worked |
| Background | The motivation, and the problem it's meant to solve | It gives everyone the context behind the work |
| Assumptions | What you're assuming about users, technical limits and the business | It surfaces risks and things you still need to validate |
| Requirements and options | Each requirement, a short user story, its importance and any notes | It shows what you've considered and how much each item matters |
| Design and supporting documents | Mockups, diagrams and wireframes, all in one place | People get the context without hunting for it |
| Open questions | Things to decide or research, then the answer and the date you answered | Questions don't get lost, and you can track how the product evolved |
| Out of scope | What you're not doing, as specifically as you can | Everybody knows where the line is |
A PRD outline to paste
Paste this into a shared document that the whole team can see. Fill in the first three headings on your own, then bring in the team for the rest.
Copy this PRD template
PRODUCT REQUIREMENTS DOCUMENT
Product or feature name:
Status (on target, at risk, delayed or deferred):
Target release date:
Product owner, core team and stakeholders:
OBJECTIVE
How this supports our larger goals:
SUCCESS METRICS
Goal, and how we'll measure it:
BACKGROUND
The problem we're solving, and why now:
ASSUMPTIONS
About our users:
About technical limits:
About the business:
REQUIREMENTS
Requirement, user story, importance, notes:
SUPPORTING DOCUMENTS
Mockups, diagrams, customer interviews:
OPEN QUESTIONS
Question, answer, date answered:
OUT OF SCOPE
What we're not doing in this release:
Building it in six moves
These steps follow the order Atlassian uses for its template.
- Set out the basics and roles. Atlassian starts with a top table: target release date, current status and who's on the core team.
- Write the objective and the success metrics. Keep the explanation brief. Atlassian's point is that you shouldn't be launching something just for the sake of it, so say why it deserves to exist, then list the goals and how you'll measure them.
- List your assumptions, then map your options. Atlassian's example is a useful one: if you think most users will access a feature from a tablet, note that assumption, and it then leads to a requirement that the feature must be mobile responsive.
- Add the supporting documents. Mockups, diagrams and designs go in one place, so everyone's looking at the same version.
- Capture open questions as they come up. Atlassian's template has room for the answer and the date, so you can see how decisions evolved.
- Write the out-of-scope list, and keep adding to it. Don't leave this until the end of the project. Atlassian tells you to keep updating this section as you go.
Why the blank section costs you most
Out of scope is the section people leave empty, and it's the one I'd fill in first. Atlassian names it directly as a defence against scope creep, saying one of the best ways to prevent creep is to be proactive, and telling you to list what's out of scope for the feature or release as specifically as you can.
Its guide adds a useful twist: flag things that are out of scope for now but might be considered later. That's what makes the list easy to agree to. Nobody has to hear that their idea's been rejected, only that it isn't in this release.
My view is that a PRD listing what you won't build ends more arguments than one listing everything you will. A long list of features still leaves room for "I assumed that was included". A short list of exclusions doesn't.
Signs your PRD has gone wrong
Atlassian lists some warning signs, and they're worth checking against your own document. It's the difference between a working document and one that's filed and forgotten.
- The whole project's been specified in great detail before any engineering work starts.
- Every team has to give iron-clad sign-off before work can begin.
- Designers and developers don't know when requirements have been updated.
- Requirements never get updated at all, because everyone signed off on them.
- The product owner writes the requirements without the team taking part.
The theme is that a PRD should be a shared, living thing. Atlassian says Agile PRDs focus on shared understanding, customer needs and flexibility, and avoid overly detailed specs. It says product owners who don't work this way get caught up speccing every detail, then hope they've specified the right things. The practical fix it offers is to involve people early: bring a designer and a developer into customer interviews, so they hear from the customer directly and not through someone's notes.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
Where a PRD sits next to user stories
A PRD holds the whole picture. User stories are the individual pieces inside it. Atlassian lists user stories as one section of a PRD and tells you to list them or link to them, along with customer interviews and enough detail to make a complete story. You don't choose between them, because one sits inside the other.
If you're working out when each release happens, a roadmap tool deals with timing across several products, while a PRD covers one. And once the requirements are settled, a project plan is where you'd put the tasks and dates.
The honest trade-off
If you fill in every heading out of duty, you'll end up with a long document that nobody opens, and that's the failure Atlassian's warning signs describe. It takes time to write, and for a tiny change it's overkill.
The pro is that it saves time on anything bigger. Atlassian says a consistent template lets everyone follow along and give feedback, so a new person can catch up from one page and not five email threads.
My verdict
This is my view, not a rule from Atlassian: I'd keep it to two pages and skip anything an engineer will decide anyway. Atlassian's own line is to focus on higher-level requirements and leave implementation details to the development team. I'd write the objective and the out-of-scope list first, because if you can't fill in those two, you're not ready to brief anyone.
Frequently asked questions
What is a PRD?
A PRD is a product requirements document. Atlassian says it defines the product's purpose, features, functionality and behaviour, along with user needs and success criteria.
What should a PRD include?
Atlassian says effective PRDs include goals, assumptions, user stories, design and clear out-of-scope items. Its template adds status, target release, success metrics and open questions.
How long should a PRD be?
Atlassian doesn't set a page count, but it does warn against overly detailed specs and talks about just enough context. My own preference is two pages.
What's the difference between a PRD and a user story?
A PRD covers the whole product or feature, while a user story describes one small piece of it. Atlassian treats user stories as a section inside the PRD.
Who writes the PRD?
Usually the product owner or product manager, but not alone. Atlassian lists a product owner writing requirements without the team's participation as a warning sign, so I'd draft it and then work through it with the team.
