Handy Guide to

Product Requirement
Document (PRD)
ESSENTIALS YOU ALWAYS WANTED TO KNOW

Includes a
Sample
Project PRD
by ProductHood with
Resources
Handy Guide to Product
Requirement Document (PRD)
Essentials You Always Wanted To Know.

Brought to you by ProductHood

Graphics & Image Credits: Flaticon.com, Undraw.co, Unsplash.com

©2020-21 www.producthood.com
Table of Contents
Handy Guide to Product Requirement Document
(PRD)

1. Introduction

2. What is a PRD?

3. Purpose of PRD

4. Components of a PRD

5. How to Plan a PRD?

6. Tools for Writing a PRD

7. Resources

©2020-21 www.producthood.com
 PRD or Product
Requirement Document is
an important document
required to be written for any
small or big product feature
development. A product
manager has to put in efforts
regularly to write PRD’s and get
it approved by stakeholders to
facilitate product development.

In this book, you will learn

everything about PRD’s and
what you should be doing as a
product manager to create a
great PRD and make your
stakeholders happy.

You will also find a sample PRD

for a digital product and
relevant templates to give you
a headstart with the PRD
writing process.

We have also provided a few

resources at the end if you
want to learn more about
writing PRD’s.
©2020-21 www.producthood.com
I think of PRD as a one way communication to
the developers and designers, all their queries
should be answered in there, with exceptions.

Hari Om Vashishtha
Product Manager, ZipGrid
What is a PRD?
A great product in the hands of happy customers is the result
of hard work done by the entire team but first, it starts with
research and planning. A product manager facilitates the
entire research and planning process and ultimately
documents everything so that design and development teams
can convert the requirements into something tangible.

A PRD or Product Requirement Document is written by

the product team (or manager) and defines the product
being built and covers the product’s overall purpose,
various features, functionalities, behavior, and
supported by relevant assets like images.

The document will help communicate the capabilities that

need to be included in a product release to various teams like
development, testing, and even sales and marketing teams for
their planning and training purposes.

If a feature is not available in the PRD then the stakeholders

can safely assume that the feature is not available in the
finished product release.

©2020-21 www.producthood.com
One of the most important trait that I push my
team to get and I quote "Knowing what not to
build is a bigger skill than building what is
asked!"
Especially relevant when you are perpetually
struggling for dev bandwidth

Siddharth Chaturvedi
Director- Products at Power2SME
Purpose of a
PRD
Product Requirement Documents are useful as
they help the product team get all stakeholders
aligned and create a shared understanding.

A good product is not built in silos but is the result

of contribution from multiple stakeholders like
Product, Engineering, Testing, Design, Marketing,
and Support. A well written PRD will ensure
everyone is on the same page and what you
deliver is as per business requirements and within
desired timelines.
A PRD is the starting point for other teams to start their
planning process. For example, the Design team will work on
the design artifacts (UI/UX Mocks, etc.), the engineering team
will work on the technical architecture and feasibility analysis
while the marketing team will plan various campaigns.
Similarly, the Testing team will start creating their test cases
based on the PRD documentation.

A PRD will help various teams (like design and engineering)

understand the requirements and priority associated with
various features and the expected timelines. They will be able
to help the product team with suggestions, feedback, or even
communicate their doubts or point out anything which has
been left unchecked.

PRD’s will help plan things better which may not be possible if
product development happens on an ad-hoc basis without
any formal documentation.

©2020-21 www.producthood.com
Writing descriptive PRD brings clarity of thought
to the writer and helps reader and team
understand the PM and his vision in a better
way. Bullet points should be avoided as they are
open for interpretation and add ambiguity

Shobhit Saxena
Director - Product @ Finansme.com
Components of
a PRD
Components of PRD

A good PRD makes things simple and helps

various stakeholders understand the goal at hand
and the various aspects of the product feature
being planned for development.

At a high level, every PRD should follow a set of

components and include relevant details within
each component without any scope for ambiguity
and incompleteness. In the following pages, we
will cover each of the components in detail. These
components are not an exhaustive list but cover
major items that should be there to create an
impact on your product and teams.

You might see the addition or deletion of some

items depending on various factors like product
feature to be developed, and the culture followed
in your product teams.

We will explain each component of the PRD

through a sample project.

©2020-21 www.producthood.com
Sample Project

New moms with their babies need help on child

care, self-care and also need to plan their career
after maternity leave. They need a mobile app that
can connect them with professional coaches and
other women mentors who have been in their
situation before for guidance and help.

We will write a sample PRD for such an application

called MumCoach covering a few important
product features like User login/sign up and home
page post login.
 PRDs are the bible of any product. PRDs define
the know how of a product & helps the creators
(Developer) set the foundation of the product.

Ashutosh Mangal
BE - Manager (Dr. Reddy's)
Components of PRD

Objective or Goal

In this section of PRD, you will cover the objective or goal that
we are trying to achieve through this product or feature
development. You should write in detail about the outcome
and the problem you are trying to solve and how it fits well in
your overall product vision and roadmap.By defining clearly
your objectives, your stakeholders will be able to understand
the overall impact they will be having on the product and
business through their efforts.

The objective creates a sense of shared responsibilities

between all the stakeholders who will be working together to
deliver the product into the hands of the customer.

MumCoach - Objective

New Moms should be able to login or sign up on the

Android mobile app and search for coaches from the
home page.
User or Customer Details

A product manager knows her customers or users like the

back of her hand. However not every team member
understands the user that well.

Some products (or features) can have multiple types of users

(or customers). For example a B2B SaaS application can have
an admin account user and various other user roles with
access to specific parts of the application like reports,
dashboards, integrations, etc.

In another case, there might be scenarios where an

application is accessed by a team with a manager and
subordinates.

For a B2C application like Facebook, there are different types

of users like a normal Facebook user account, admin role for
product features like Pages, Groups or Business account for
companies using Facebook for marketing purposes.

By defining clearly the end user, different teams can plan their
work easily. For example, engineering teams have to think of
user permissions, testing teams will define their test cases
accordingly while Marketing teams have to think of the right
messaging in their campaigns.

Hence defining the end user who will be using the planned
features is a must have in any PRD document.

©2020-21 www.producthood.com
 MumCoach - User

MumCoach users are women with a new born baby or

those who are on a career break and are looking for
help from coaches who are experts on career, health
and child care.

For this PRD, we will limit to women users who are

looking for help from the experts. In future PRD's we will
include coaches as other type of users.

Features or Modules

In this section, you should write as much detail as possible

about the product feature to be developed. You should
include all the relevant details like the goal of the feature (or
set of features), various use cases, and scenarios (including
edge cases) so that all the teams involved in product
development have complete clarity and plan their resources
well in advance.

Your design team would need to understand the rationale

behind those features and how different types of users will
use this feature in different scenarios. Similarly, your
engineering team would need to understand the use cases
and other information like future release plans (high level) so
that they can plan for scale and growth in the future without
having to rewrite everything.

The feature descriptions must be supported by the relevant

user flows that we will cover in the next section.
©2020-21 www.producthood.com
User Flows

Describing the product features is not sufficient until they are

supported by the required user flows which explain how the
user navigates and uses product features under various
scenarios. This would also cover the data that would be
shared between the user and the application and how the
application logic should work based on the user actions.

For example, if you have added a new chat functionality in

your application then how users would use this chat feature
and the way various users flow would function in detail are
given below.

What would happen when the user opens a chat window

(or closes it)
How the chat would work?
How previous chats would load?
How a new chat window would open?
How to archive any chat?
How to block a user?

You must include as much detail as possible at each step of

the workflow so that various teams can plan their deliverable
accordingly.

During the initial stages of PRD, it's always a good idea to

share the document with various teams so that they can start
thinking about the overall user flow and help you with more
information which can enable you to think better and write
more detailed documentation.
©2020-21 www.producthood.com
MumCoach - Modules & User Flows

Login Module

User should be able to login using email address and

password. On successful login, she would be redirected to
the home screen. If the email address or password is not
correct then show an error message.

There should be a link for sign up and forgot password.

Sign up Module

User should be able to sign up using email address and

password information. If the email address exists then show
error message with an option to login via link. For new
accounts, email verification is mandatory.

An email would be sent to the address provided on sign up

with a link to verify email. User must click the link in the
email to verify the account. Unless the account is verified,
user can not login into the account.

User will be landed on the sign in post clicking the verify link
and the account will be marked as verified.

Forgot Password Module

User should be able to reset password by entering email id.

If the email id has an account associated then a reset email
will be sent else error will be shown. User will be asked to
enter a new password when she clicks the reset link in the
email. She will redirected to login page after submitting new
password.
A detailed user flow description will help the design team
visualize the user engagement with your product and enable
them to design the right user experience and necessary user
interfaces. We will touch upon design elements in the next
section.

Design elements (Wireframes, Mockups) and other

supporting assets

Your product requirement document is incomplete without

supporting assets like wireframes, mockups, or prototypes.
At the basic level, you should have wireframes in the V1 of
your PRD. Wireframes will help your team members
understand and visualize the product and various user flows
easily.

In almost all cases, your wireframes would help the team

course correct and suggest necessary changes to the overall
product feature being developed. This means that you have to
iterate on your PRD a few times before it can be considered
complete for further action from the development team.

A final PRD would have finished designs like MockUps,

Prototypes, and supplemented by other assets like images,
font files, etc. which will be used by the technology team
during the product development lifecycle.

A good product manager will ensure that the development

team has the necessary design and other assets required for
the development team.

©2020-21 www.producthood.com
In other cases, you might have to provide details like API Keys
(while integrating with 3rd parties) or necessary tracking code
(like Google Analytics or Mixpanel) so that developers know in
advance and do not have to look for information during the
development process.

MumCoach - Sample Assets

Writing PRDs help you discover many scenarios
that will strengthen your solution and provide a
better and error free experience to end
customers.
Writing PRDs helped me get a structure in my
overall thinking process and enabled me to
provide better and stronger solutions to the
problem in-hand.

Abhinav Jain
AGM Product, PayTM
Assumptions

The assumptions are an important part of the PRD manual

which will help teams assume certain things to be true always.
You should include any information which you would assume
to be in place but may not be guaranteed. For example, users
would always have internet access or users would use
Chrome's latest browser for your product feature.

Assumptions will help make things easier for everyone and

features can evolve with time as and when you validate your
assumptions or get feedback from the end user and other
stakeholders. Sometimes you might have to update PRD post
stakeholder discussions as some assumptions may not be
valid and things need to be planned from the product
perspective.

For example, in V1 you might consider that users will always

have internet access but in V2 of the PRD (post stakeholder
discussions), you might remove that assumption and instead
include a user flow for No internet use case.

Systems and environments Requirements

In this part of the PRD, you should specify some high level
details on the platform or environment in which your users
would exist or use your product. For example what kind of
browsers, devices, OS, data network that would have access to
and how your application should behave under different
environments. For example, if the users are on low internet
bandwidth then how gracefully your application should
degrade or how the user experience should be on Mac
devices as compared to Windows applications.
©2020-21 www.producthood.com
 MumCoach - Assumptions & Environment

MumCoach users would always use Android latest

version and in the V1 product launch, we will assume
that internet is always available. In future versions we
might provide an offline support.

Analytics

No product can be improved without analyzing the metrics

and understanding of customer data. Hence having the right
analytics in place is paramount to product success.

As a product manager, you must include information related

to data to be tracked and anything which can help you track
the product usage post-launch. This may include providing
tracking code (like Google Analytics) or specifying the format in
which you want to track specific information like button click,
video views or window close, etc.

Future Features

Finally, you should give your teams some high-level

information about the future versions of the product and it
would evolve with later releases. This would help your
engineering team plan system architecture from a scalability
and code manageability perspective. Other teams can also
plan their deliveries based on future product improvement
plans. For example, Sales and Marketing teams can update
their clients about current product releases and how future
releases will improve the customer experience.

©2020-21 www.producthood.com
We need a PRD so that anyone who reads it gets
ideas, gets details of what they are making, and
why they are making.

Piyush Rajesh Gupta

Product Lead, HT India
MumCoach - Future Features

MumCoach app would be supported on iPhone and

Windows mobile in the future. Users would be able to
book the coaches and schedule sessions with them by
paying through PayPal or Credit Card.
How to Plan a
PRD?
Writing a Product Requirement Document is a tedious process
and requires planning and hard work. A PRD is never written
in silos and as a product manager, you must ensure that you
bring stakeholders together and discuss with them as much
as possible to ensure nothing is left for assumptions.

Every time you are writing a PRD for a given feature or product
launch, you need to follow the steps outlined in this section.

Product Vision

You will start with the broad vision of the feature within the
overall product or business framework and how the feature
would evolve with time and what you need to build in version
1 and subsequent versions.

You also need to understand the impact of the feature on

your users and other features within the product.You need to
discuss with your management and other stakeholders to
understand their expectations and goals with the new feature
launch. Accordingly, you will include the relevant information
in the PRD.

Research

You have to do a lot of research before starting the work on

the PRD. Your research would involve talking to customers to
understand their pain points and everything that can help you
understand the use cases and value that your product can

©2020-21 www.producthood.com
provide to customers for which they are willing to part with
their time and money.

You also need to understand how the new product will be

positioned with respect to competition and what different
your competitors are doing in terms of features, pricing, or
anything relevant to your business.

In addition to competition research, you also need to do

market research to understand the market size and various
factors like political, economic, social, etc. that can have an
impact on your product and business.

For example, if you are launching the product in new

geography then you must be aware of the local laws and
regulations, customer preferences, and any competition
already serving your target market.

A good example is WhatsApp Payment Solution which started

in the U.S.A and subsequently launched in India but due to
Indian regulations took some time to launch keeping local laws
into perspective and tailored to Indian Customers due to stiff
competition from PayTM, PhonePe and other players in the
market.

Stakeholders Discussion

Once you have a basic understanding of product vision and

other aspects of customer requirements, competition analysis,
and market research, you should be able to discuss with your
stakeholders.

©2020-21 www.producthood.com
You should share with them all the facts and data gathered
during your research and present an outline of what you
intend to build and how your product will evolve with time.

You will get a lot of feedback from your team and based on
this discussion you will work on creating the first draft of your
PRD.

Typically you would include your sales, marketing, business

teams along with higher management during this stage if its a
major product release else you can bring a smaller set of
people from product and business functions.

PRD Draft

Your first PRD draft should be written as fast as possible using

the outline you have studied in the previous section. Gather as
much information as possible in a structured manner and
include placeholders for future additions.

You will also create wireframes for your product and include
as much information as possible on the wireframes so that
later the design and engineering team would be able to do
their job easily.

Once you have your first draft of PRD ready, you are all set for
a discussion with your technical teams and other
stakeholders.

©2020-21 www.producthood.com
Stakeholders Discussion

In this stage, you will again discuss with your technology and
design team to give an overview of the requirements and
share broad goals from a business perspective.

Your engineering team and design team will review the PRD
draft and might ask questions or give feedback with respect to
feasibility and capability within the team.

If it's a major release then you might want to include a wider

audience else a selective representation from business,
design, and technology should be sufficient. Ultimately it will
depend on the company culture and processes followed in
your product function.

The next goal for you would be to get the various assets (like
Mockups) from the design team and a sign off from the
Engineering with respect to feasibility and any other
constraints that they might face.

Iterate, Refine and Handover

Finally, once all the discussions are done and relevant assets
are available, you will finalize the draft and hand it over to the
engineering team for development.

Of Course, you would have to do the stuff like creating user

stories and prioritizing various stories (from the PRD) but all
this is outside of the scope of this book.

©2020-21 www.producthood.com
 Tools for
Writing PRD
The simplest tool that you can use to write PRD is the Word
Processor on your local machine. However, there are many
tools in the market which can help you to write good PRDs
collaboratively.

Some of the tools that you can use are

Google Docs

Confluence

Slite

Notion

Nuclino

Evernote

Slab

Tettra

©2020-21 www.producthood.com
A well written Product Requirement Documents
answers,
where the product is before development,
where the product will be after development
and where the product CAN be.
It captures business context, deliverable by
engineering and measurable benefits for the
impacted users.

Kartik Sharma
Product Manager, CarDekho
 Resources
How to write a good PRD?

Creating a lean, mean product requirements machine

Writing Good PRD’s

PRD Template 1

PRD Template 2
Always Include the edge cases in the
requirement doc else they will fall
through and no one would be
looking at the same until reported
by users

Deepak Jain
Lead, Product Operations
Times Internet
ProductHood is a growth catalyst for
building awesome products.

Master Classes for Product

Professionals
Learn to build, market and sale world class
products with the experts online anytime anywhere
with ProductHood Master Classes.

Attend Now