Skip to main content

Product requirements document (PRD) with an example.

· 10 min read
Goutham Jagannatha

A product requirements document, or PRD, outlines all of the features and functionality that a product release must-have. Know more.

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!

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.

info

Setup your own feature request tracker in 1 minute.

Feature requst tracker

No credit card required. No-code and 1 minute setup.

The document 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.

SectionExample
VisionOrganize 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
PersonasThis 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
ApproachBuild 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 scopeAndroid and iOS applications

Timelines and release planning

Describes the overall release schedule and the features going in each release.

Release NameAudienceDateInitiativeFeaturesDependencies
BarebonesInternal usersApr 15, 2022MVPLogin, add a task, complete a taskNA
Closed betaInternal usersApr 30, 2022MVPEdit a task, reorder tasks, Calendar IntegrationBarebones
Beta MVP LaunchExternal Beta UsersMay 30, 2022MVPEmailsClosed Beta
Team FeaturesInternal UsersJune 15, 2022Enterprise SupportTeam hierarchy, invite team membersBeta MVP Launch
MVP LaunchExternal UsersJune 30, 2022MVPEmailsBeta MVP Launch
Security FeaturesInternal UsersJuly 30, 2022Enterprise SupportSOC Type 2 ComplianceMVP Launch
SOC AuditExternal AgencyAug 15, 2022Enterprise SupportSOC Audit by External AgencySecurity Features
Enterprise Support LaunchExternal UsersSep 30, 2022Enterprise SupportComplete launchSOC 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
ItemDetails
FeatureReorder the items in the list
DescriptionProvide a drag and drop interface to reorder items that already exist in the list
PurposeSupporting reorder will keep the user within the app
User ProblemThe 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 ValueUser 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 InputDescription
Frontend FrameworkWe have always used Angular for building frontend. Let's continue using that since we have the expertise.
Frontend ComponentsInstead of building components from scratch let's leverage open source libraries
Code reviewLet 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!

UX Flow

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.

FeatureSuccess MetricCurrent MetricTarget MetricTimeline
Login with emailNumber of loginsNA100Oct 30, 2022
Create a todoAverage number of Todo created per person per dayNA5Oct 30, 2022
Delete a todoNumber of deletes per person per dayNA2Nov 30, 2022
Edit a todoNumber of edits per person per dayNA1Nov 30, 2022
Reorder the listIncrease user engagement time per day1 Hour2 HoursNov 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.

FeatureDescription
Team InboxA shared inbox for all members of the team
Activity HistoryAdmins 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.

Agile vs waterfall

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 an "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.
info

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

info

Psst... here is one secret. One way to crush your SaaS backlog is to use ProdRoll.

80% of software features are rarely or never used. Why waste time and money building them? ProdRoll helps you prioritize your backlog based on real user needs. Let your users tell you what to build next.

Feature requst tracker

No credit card required. No-code and 1 minute setup.