How to write a PRD: product requirements template and example
How to write a PRD using 8 sections from Atlassian's template, with a hypothetical worked example, the PRD vs BRD difference and AI feature additions.
A product requirements document (PRD) is a written brief that tells a team what to build, for whom, why, and how success will be judged. Atlassian's PRD template has eight parts, from participants and target release to a list of what the team is not doing. A good PRD stays brief, links out for detail and is written together with a developer.
What is a PRD in product management?
A PRD is the written statement of a product's purpose, features and behaviour. Atlassian describes it as a single source of truth that keeps designers, developers and stakeholders aligned. ProductPlan describes it as the artifact that tells the development and testing teams which capabilities a release must include.
The readers differ by section. Engineers read the requirements and open questions, designers read the users and flows, testers read the acceptance criteria, and leadership reads the goals and metrics. A PRD is written for all of them at once, so the top of the page should say what is changing and why.
A PRD is not a contract and not the backlog. The Scrum Guide describes the Product Backlog as an emergent, ordered list, and makes the Product Owner accountable for communicating its items. The PRD supplies the context, and backlog items link back to it. The Agile Manifesto of 2001 prefers working software over comprehensive documentation while accepting that documentation has value, and that is the right reading for a PRD: enough to align the team, and no more.
Indian job postings ask for the skill by name. Meesho's Product Manager I posting, listed on 16 September 2026, asks for comfort with product requirement documents, backlogs and roadmaps, and Paytm's UPI product posting, listed on 14 September 2026, asks for the ability to write crisp PRDs.
What is the difference between a PRD and a BRD?
A business requirements document (BRD) frames a business project, while a PRD frames a product release. Atlassian describes a BRD as a detailed official report that usually covers business objectives, project scope, functional and non-functional requirements, key stakeholders, and constraints or assumptions. ProductPlan says a PRD may follow a marketing requirements document (MRD) and lists the capabilities a release must include.
In most teams the BRD answers why the project exists and is agreed with the business side, and the PRD answers what the product must do and is owned by product management. The labels are used loosely, and some companies write a single document and call it either. A candidate or new hire should ask which sections a team expects instead of assuming.
What does a PRD contain?
Atlassian lists eight parts it finds give just enough context: project specifics, goals and business objectives, background and strategic fit, assumptions, user stories, user interaction and design, questions, and what is not being done. The table below groups them under the headings most teams use. Take a hypothetical product team in Pune building a food-ordering app that wants to add a reorder button; every example in the table is invented.
| Section | Question it answers | Hypothetical example |
|---|---|---|
| Participants, status, target release | Who owns it and when does it ship? | Owner is the product manager; design and engineering leads named; status on track; target release set by quarter |
| Problem and background | What problem exists and why now? | Returning customers retype the same order every week and say so in support tickets |
| Users and goals | Who is it for and what should change? | Customers who order from the same restaurant weekly; goal is fewer taps to repeat an order |
| Non-goals | What is left out on purpose? | Scheduled orders, subscriptions and group orders |
| Requirements | What must the product do? | Show a reorder button on orders delivered in the last 30 days; warn before payment if an item is unavailable; always charge today's prices |
| Success metrics | How will the team know it worked? | Share of repeat orders placed through reorder, with cancellations and support contacts as guard rails |
| Assumptions and risks | What is believed but unproven? | Customers reorder the same basket; menus change often enough to break some reorders |
| Open questions | What still needs a decision? | Should closed restaurants appear in the list? Who approves the warning text? |
User interaction and design from Atlassian's list sits inside the requirements row as links to wireframes. Atlassian also suggests a table of things to decide or research, which is the last row.
How do you write a PRD step by step?
Write the sections in the order of the table, but spend the time on the problem and the non-goals.
- State the problem in two or three sentences, with the evidence behind it, before any feature appears.
- Name the users and the outcome that should change for them, in words a stakeholder can repeat.
- Write the non-goals early, since they stop scope from creeping in during review.
- Turn each requirement into a statement a tester could check, and replace words such as fast or simple with something measurable.
- Choose success metrics with a baseline, a target and a review date, and add guard rails that catch harm elsewhere.
- List assumptions and open questions, give each an owner, and update the page as answers arrive.
Atlassian adds two process points: customer interviews should include a designer and a developer so they hear the customer directly, and the PRD should never be written alone. The requirements come out sharper when a developer asks what happens at the edges, and the prioritisation frameworks guide covers how to decide which requirements make the first release.
How does a PRD for an AI feature differ?
A PRD for an AI feature adds a measurement plan, because the same input can produce different outputs. Teresa Torres of Product Talk describes AI evals as methods for measuring whether an AI product or workflow is performing well, and notes that a unit test expects the right answer every time while an eval measures how often the model gets it right. A requirement such as "summaries are accurate" therefore needs a rate, a test set and an owner.
Anthropic's documentation says good success criteria are specific, measurable, achievable and relevant, and lists task fidelity, consistency, tone and style, privacy, latency and price among the dimensions most use cases weigh together. Its own contrast is between "the model should classify sentiments well" and a criterion tied to a score on a held-out test set.
The standard sections stay, and a few additions follow from that:
- a set of real example inputs, including edge cases such as empty, very long or harmful input
- a pass mark for each quality dimension, plus limits on latency and cost
- what the feature should do when it is unsure, for example hand over to a person
- which data the feature may use and which personal data it must never reveal
- who reviews failures, and how often the example set is refreshed
A separate guide on writing effective AI prompts covers the prompt side of the same work.
What mistakes make a PRD fail?
Atlassian lists the patterns to avoid: the whole project specified in great detail before engineering starts, iron-clad sign-off from every team before work begins, designers and developers not told when requirements change, requirements never updated, and the product owner writing them without the team.
Three more come up often. The first is a solution written as a requirement, such as "add a dropdown", which hides the problem it was meant to solve. The second is a metric with no baseline, so nobody can say afterwards whether the change worked.
The third is a PRD that nobody opens after the kickoff meeting because it lives in a different place from the backlog. Linking the PRD to the work items, as Atlassian recommends, helps with that one.
When is a PRD not worth writing?
A PRD costs time to write and keep current, and Atlassian's own guidance names the two risks: documentation goes stale once the solution changes after feedback, and people may not take part in commenting. A small change that one developer can ship in a day rarely needs eight sections. A short brief with the problem, the change and the metric is enough.
A PRD also cannot replace conversation or discovery. It records decisions that were reached by talking to customers and engineers, and a well-formatted PRD built on an untested assumption still ships the wrong thing. The templates in this area come from tool vendors, so treat the section list as a starting point and adapt it to the team. For longer background on gathering requirements before writing, see the software development requirements gathering guide.
Where does PRD writing fit in a product management programme?
Certification in Product Management with Applied AI is an online programme from iHUB DivyaSampark, IIT Roorkee, run with Masai as the implementation partner, with live classes on Zoom and an optional campus immersion. It covers product discovery, prototyping with AI app builders, working with engineering teams, product metrics, designing AI features and go-to-market, and its topics include LLM-drafted product specs and user stories.
Frequently asked questions
Who writes the PRD?
The product manager usually owns it, or the product owner in a Scrum team. Atlassian advises writing it together with a developer, and bringing a designer into customer interviews, so that the requirements reflect what the customer said and what engineering can build.
Is a PRD still used in agile teams?
Yes, in a lighter form. ProductPlan says the PRD is used more in waterfall environments but may be used in agile ones. Atlassian's agile version is a one-page PRD that links to customer interviews, designs and work items instead of specifying every detail before engineering starts.
How long should a PRD be?
Neither Atlassian nor ProductPlan sets a length. Atlassian describes a one-page PRD that acts as a landing page and links to detail elsewhere. A practical test is whether a new engineer can read it in one sitting and then ask useful questions about edge cases and open decisions.
Can AI write a PRD?
AI can produce a draft, and Teresa Torres notes that evals can check whether an AI-generated PRD includes everything that was asked for. The draft still needs review against real customer evidence, constraints and the team's open questions, because the model has not spoken to customers or engineers.
What is the difference between a PRD and user stories?
A PRD describes the whole change and its context. User stories break the requirements into backlog items a team can finish. Atlassian lists user stories as one section of the PRD and recommends linking each to its work item, so the page shows current status.
Next step
The sections above become routine with practice on real products. The product roadmap guide shows where a PRD sits in the planning chain, and the Certification in Product Management with Applied AI page lists the modules that cover discovery, specs, engineering collaboration and metrics.