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:
Objective
Timelines and release planing
Features
Design considerations
Success Metrics
Future Work
Objective
This section describes the overall objective of the product, rough timelines and target customer profiles.
Section | Example |
Vision | Organize work so well that high priority work always gets done |
Goals |
|
Personas | This product is ideally suited for professionals managing a large team or needs coordination with multiple stakeholders.
|
Approach | 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.
Release Name | Audience | Date | Initiative | Features | Dependencies |
Barebones | Internal Users | Apr 15, 2022 | MVP |
| NA |
Closed Beta | Internal Users | Apr 30, 2022 | MVP |
| Barebones |
Beta MVP Launch | External Beta Users | May 30, 2022 | MVP |
| Closed Beta |
Team Features | Internal Users | June 15, 2022 | Enterprise Support |
| Beta MVP Launch |
Security Features | Internal Users | July 30, 2022 | Enterprise Support |
| MVP Launch |
SOC Audit | External Agency | Aug 15, 2022 | Enterprise Support |
| Security Features |
Enterprise Support Launch | External Users | Sep 30, 2022 | Enterprise Support |
| SOC Audit |
Features
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
Item | Details |
Feature | Reorder the items in the list |
Description | Provide a drag and drop interface to reorder items that already exist in the list |
Purpose | Supporting reorder will keep the user within the app |
User Problem | 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 Value | User does not have to leave the app and organize her day well |
Acceptance Criteria |
|
Design Considerations
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.
Design Input | Description |
Frontend framework | We have always used Angular for building frontend. Let's continue using that since we have the expertise. |
Frontend components | Instead of building components from scratch let's leverage open source libraries |
Code review | 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!
Success Metrics
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.
Feature | Success Metric | Current Metric | Target Metric | Timeline |
Login with email | Number of logins | NA | 100 | Oct 30, 2022 |
Create a todo | Average number of todo created per person per day | NA | 5 | Oct 30, 2022 |
Delete a todo | Number of deletes per person per day | NA | 2 | Nov 30, 2022 |
Edit a todo | Edits as a percentage of new todos | NA | 50% | Nov 30, 2022 |
Reorder the list | Increase the user engagement time per day | 20 minutes | 30 minutes | Nov 30, 2022 |
Future Work
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.
Feature | Description |
Team Inbox | A shared inbox for all the members of the team |
Activity History | 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.
Conclusion
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.
