A product requirements document, or PRD, outlines all of the features and functionality that a product release must-have.
Product managers write the PRDs, based on the marketing requirements document (MRD) created by the product marketing staff. PRDs are written from the customer's point of view and do not usually contain finer implementation or UX recommendations.
In this blog post, we will discuss everything you need to know about PRDs!
The second half of the blog contains some specific pointers on Agile PRDs.
What should be included in a product requirements document? Explained with a TODO app PRD.
Let's assume we're creating a tiny TODO application. The application lets a user to login and create todos and mark them as done when they are done. Teams can also collaborate on the todos for the team and check them off when todos are done.
The below outline is only a sample. But you are free to add more sections to suit your product/company. We have laid emphasis on the structure of the PRD rather than the content. If you are creating a PRD for a feature it will be on similar lines.
The PRD covers these sections:
Timelines and release planing
This section describes the overall objective of the product, rough timelines and target customer profiles.
Organize work so well that high priority work always gets done
This product is ideally suited for professionals managing a large team or needs coordination with multiple stakeholders.
Build a web application for users to collect todos. In the MVP, the focus will be on single users. In enterprise version teams can collaborate on Todos.
Out of scope
Android and iOS applications
Timelines and release planning
Describes the overall release schedule and the features going in each release.
Apr 15, 2022
Apr 30, 2022
Beta MVP Launch
External Beta Users
May 30, 2022
June 15, 2022
Beta MVP Launch
July 30, 2022
Aug 15, 2022
Enterprise Support Launch
Sep 30, 2022
All the features that will go into the product are explained in this section. For our todo example lets consider an example to get a hang of this section.
Feature: Reorder todo list
Reorder the items in the list
Provide a drag and drop interface to reorder items that already exist in the list
Supporting reorder will keep the user within the app
The current structure of task ordering is too rigid and user will have to manage this outside outside the app using notes app or book/pen
User does not have to leave the app and organize her day well
Covers some of the high level design inputs to set the direction for UI/UX. Care should be taken to not prescribe the finer details of the UX. The design team will build the UI and design library based on the inputs present here.
We have always used Angular for building frontend. Let's continue using that since we have the expertise.
Instead of building components from scratch let's leverage open source libraries
Let the engineering team nominate one person to review code commits to the design library to avoid duplication of components
This section also covers a few major UI flows at a high level.
An example of the UI flow experience by a user who has just signed up!
Describes how each feature will impact a target metric. PMs will have to work with engineering teams to add product analytics code. Product analytics tools helps PMs understand how a product is being used.
Login with email
Number of logins
Oct 30, 2022
Create a todo
Average number of todo created per person per day
Oct 30, 2022
Delete a todo
Number of deletes per person per day
Nov 30, 2022
Edit a todo
Edits as a percentage of new todos
Nov 30, 2022
Reorder the list
Increase the user engagement time per day
Nov 30, 2022
These are the features that are deliberately kept out of the scope for now. This section will help architects and designers to think about the future use cases and take them into account in the current design.
A shared inbox for all the members of the team
Admins will be able to see in a chronological order all the updates to team's tasks
Product requirements document vs Functional requirements specification(FRS) vs System requirements specification(SRS)
A minute ago we said a PRD should not have finer details. So how how can engineering team work off the PRDs? Enter Functional Specification and System Specification.
Product manager and the engineering team hash out the finer details of an PRD item in a separate functional spec and system spec. Not every item in the PRD needs to be detailed out in functional spec.
A functional requirements specification(FRS) contains granular details such as data flow and UI/UX interaction details. An FRS will actually be used to as product documentation by support staff.
A system requirements specification details out the environment requirements like hardware, operating system etc.
All the documents - PRD, FRS and SRS are used by the engineering team to build out the product.
Agile vs Product Requirements Document
In the waterfall software development method, PRDs are the way to go.
But according to the agile manifesto, working software is preferred over documentation. So, generally, product managers/product owners end up capturing requirements in the form of epics and stories.
Although the agile method does not require the use of PRDs, a written feature document with some context is an efficient way to convey a large feature and bring everyone on the same page. Since agile world inherited the "waterfall" software development methodology and this feature document is somewhat close to the waterfall "PRD", the document is called, you guessed it, PRD!
So, consider writing "agile" PRDs if:
Your team is remote
Your team works in different time zones
You have a cross functional teams (tiger teams) for the project
You are implementing a large feature
There are several stakeholders like finance, marketing etc
You have new engineering hires
You have junior developers
You are doing a hard 3rd party integration
You are working in a regulated industry (finance, healthcare, etc) where documents must be maintained.
PRDs in Agile are typically written per feature and not for the whole product. Most sections of the PRD described above will be present in the agile PRDs but the context is limited to that one feature.
Section on design consideration or future work may not be present in a feature PRD.
PRD and issue tracking
Every feature written in a PRD will have a corresponding epic or a user story in an issue tracking system.
There are several SaaS softwares available to write PRDs and track epics/stories. If you are new to product management, you can no go wrong with.
Atlassian Confluence for writing PRDs and any other artifact related to your project.
Atlassian JIRA for issue tracking.
Since both confluence and JIRA comes from the house of Atlassian, they are well integrated. Eg: You can get the real time status of a JIRA ticket within a confluence PRD.
Sample one page PRD template for Agile (confluence)
Folks at Atlassian have done a fantastic job simplifying a PRD for Agile.
Click here for the sample. You can signup to download the PRD.
Btw...who writes PRD?
In an agile world, product owners take the ownership of writing PRDs in consultation with product managers and the engineering teams.
After a product requirements document(PRD) is made official the downstream work of architects, developers, designers, and QA will start.
Based on the PRD, the engineering team will do architecture/stack selection, the design team will build detailed mocks for the features and the QA team will prepare a testing strategy and the test cases.
So, it is a good idea for the product owners to consult these teams and get feedback on the draft product requirements document before officially publishing it to the company.
Writing a PRD can be a time-consuming task, and it is important to get it right. Keep the PRDs updated based on consultations with PMs and engineering teams. Revisit PRDs to check if the feature has achieved the desired goal and if not, why and what can be done.
PRDs are living breathing documents. They undergo changes frequently based on budget constraints, scope changes, team changes, and inputs from the stakeholders.
Most companies get creative around what goes into the PRDs. This is what makes PRDs from various companies unique and interesting. Modify the PRD template based on what works for your team.