Product requirements document (PRD) with an example.

Updated: Aug 23

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:

  1. Objective

  2. Timelines and release planing

  3. Features

  4. Design considerations

  5. Success Metrics

  6. 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

  • MVP: Launch MVP by June 30, 2022

  • Enterprise Support: Add features to get enterprise customers by Sep 30, 2022

Personas

This product is ideally suited for professionals managing a large team or needs coordination with multiple stakeholders.

  • Steve: 35-year-old account manager who manages a team of 5 ad operations executives. He receives about 50 emails/slack messages from his team every day. Spends 4-5 hours every day reviewing reports and planning better ad campaigns with his team. He spends rest of the time in client communications.

  • Carol: 26-year-old project manager at a software company. She works with operations, legal, HR, and the engineering team. Different teams from her company use different tools to communicate with her. Some prefer face to face meetings vs emails

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

  • Login

  • Add a task

  • Mark a task complete

NA

Closed Beta

Internal Users

Apr 30, 2022

MVP

  • Edit a task

  • Reorder tasks

  • Calendar integration

Barebones

Beta MVP Launch

External Beta Users

May 30, 2022

MVP

  • Emails

Closed Beta

Team Features

Internal Users

June 15, 2022

Enterprise Support

  • Team hierarchy

  • Invite team members

Beta MVP Launch

Security Features

Internal Users

July 30, 2022

Enterprise Support

  • SOC Type 2 Compliance

MVP Launch

SOC Audit

External Agency

Aug 15, 2022

Enterprise Support

  • SOC Audit by external agency

Security Features

​Enterprise Support Launch

External Users

Sep 30, 2022

Enterprise Support

  • Complete Launch

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

  • ​Reorder across dates

  • Reorder within a date

  • If a task is marked done, do not allow it to be reordered.

  • Do not make any changes if dragged and dropped to the same location.


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:

  1. Your team is remote

  2. Your team works in different time zones

  3. You have a cross functional teams (tiger teams) for the project

  4. You are implementing a large feature

  5. There are several stakeholders like finance, marketing etc

  6. You have new engineering hires

  7. You have junior developers

  8. You are doing a hard 3rd party integration

  9. 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.

  1. Atlassian Confluence for writing PRDs and any other artifact related to your project.

  2. 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.

 

Talk to us about your product/engineering goals and challenges. We always love to connect with product and engineering managers!


 


fatures_not_used.png

Get 10x feedback. Build what your customers need!

No credit card required to sign up.