How to create an effective Product Requirements Document

Definition of PRD

A Product Requirements Document incorporates the definition and purpose of the product to be built. It is used to convey what is being built, who is it for and how it benefits the end-user.  The outline and specifications are used by the product team to actually build and test the product, so it must be clear and thorough enough for them to do their jobs.

There is a set of minimum features that are required for the first or initial release of the product which is known as a minimum viable product. These features should be clear while creating the product requirements document and should be included in the first version or release.

How is it different from MRD

The Market Requirements Document includes the market need, strategies and opportunity while the  Product Requirements Document describes a product that addresses need, strategies and opportunity. The PRD does not include any market opportunity or business case but is rooted in use cases and required functionality. 

PRD in waterfall model and agile model

In the waterfall model, where the sequence of product definition, design, and delivery is maintained, a PRD is defined at the starting point or initial phase of the project and it provides a detailed description of what will be built.

In Agile development, a lot of time is not spent on documentation but one needs to be sensible enough not to just start building features without having a complete idea of what is to be done. Agile does not consist of the traditional documentation flow but it ensures the user stories cover up the product’s purpose, features, release criteria, and timeframe. While working in the Agile development, user stories are created instead of traditional documentation, but it consists of points necessary for the release. It need not be static, rather it is interactive.  

For example, consider a placement portal and the user story for a candidate/job seeker to create his/her profile on the portal can be written as follows:

PRD in waterfall model & agile model

Composition of PRD

  • A PRD contains every straightforward criterion required for product release along with clarifications and scope keeping in mind the resources available. The following about the product can be included in the PRD:
  1. Purpose
  2. Feasibility
  3. Stakeholders
  4. Release Details
  5. Workflow and design
  6. Future scope
  • Additionally, it may include the following:
  1. Assumptions: The assumptions made while defining the product. For example, the user has a device that supports an application.
  2. Dependencies: The known conditions on which the product will depend. For example, depending on a QR scanner for authentication in an application.
  3. Constraints: The features or services that the product may not be able to provide technically or financially.
  • Also, success metrics are included to verify if the objectives are being fulfilled.
  • If there is any possible risk identified for a feature or module it should be well documented and the points to prevent or overcome it must be added.

Briefly, the PRD must have a clear view of solutions against the corresponding problems, so the team has it as a guideline instead of a vague list of features and its needs.

Importance and Benefits of PRD

The PRD acts as the most interactive and living document for the designers, developers, testers and other stakeholders to obtain the purpose and status of the product. It gives a clear idea of how the new features will solve the user’s problems. If the documentation is not done well, it produces doubts and assumptions which may lead to product failure under some circumstances. The PRD helps to keep the product team aligned with the features that must be delivered in the given release and correspondingly helps the designers, developers, support team and sales and marketing teams collaborate internally and achieve the milestone that is deliver the right product at the given time. 

Steps to prepare a PRD

1. Define the purpose and feasibility of the product:

The aim or objective of the product should be defined, and the product team should be aligned with the product needs. Each requirement should be noted and prioritized. If the motive of the project is clear and well communicated, it will be easy for the design and implementation team to focus on building features while keeping customers’ concerns in mind. Following is a brief of what can be included:

The stakeholdersWho will be affected by the product
GoalsA list of goals to be accomplished on release
VisionWhere the product will be in the future

2. Add release details:

A complete description of the features’ delivery or release date is essential. This makes the internal teams pace up with the timeline and plan their work accordingly. All you can add to this release information is as follows:

ReleaseName of the release
DateDate of release
FeaturesThe features included in the release
MilestonesRelease milestones that are  the checkpoints where the team stops and verifies progress as per the expectations.(Suppose a goal is set as “layout design approved”, then it should be approved by then)
DependenciesRelease dependencies that are the conditions on which the release relies

3. Describe features:

Define and explain what is to be built for each feature so the product team can implement and develop it correctly. For each feature the documentation can be as follows:

Feature or user storyName of the new feature or user story
DescriptionDescription of what the feature will do
GoalThe action the user wants to perform
ProblemThe problem user is facing so this feature is required
AssumptionsTechnical, user or business assumptions made
Acceptance criteriaCriteria/conditions to be fulfilled for the product release

For example, suppose a travel booking application, and a user has made a reservation but   wishes to cancel it. Then the feature to allow cancellation will be described as follows:

User storyAs as user I can cancel my reservation
DescriptionThe user who has made a booking must be able to cancel the reservation.
GoalThe user can cancel already booked reservation
ProblemOnce the user has made a travel booking he/she is not able to cancel it
AssumptionsUser is registered and has made a reservation

4. Include user flow and design:

The pixel-perfect wireframes and mockups are no doubt created after the PRD is generated but a simple visual mockup to describe the feature, to show where the feature sits on the page and to describe the user workflow, is required at this stage to verify the objectives are fulfilled. Visual display of the feature will also avoid misunderstandings about how the feature will work.

5. Define the criteria for product testing:

It is important to define the criteria to be fulfilled for product release that is the minimum and mandatory requirements for the product release. Take the feature, think about its impact and verify it accomplishes the desired outcome and solves the user’s problem. For example, if we need to check performance, we can check how long a user takes to understand and interact with the feature, maximum users that may interact with it at a given time etc.

6. Include future work:

Some relevant high-level details of how the product will grow in the future would be helpful to consider the assumptions and limitations.

7. Check for completeness:

The PRD should be reviewed by the stakeholders and the areas that require additional clarifications must be modified and further accepted. All the questions must be identified and answered.

Sample or Checklist for inclusions in PRD

Suppose a PRD for the system that keeps a track of the user’s transactions and balances. 

1. Title: Regur Transactions Handling

Concept: Consider a currency Regur coins and these coins can be converted into Bitcoins by value and further to US dollars. Now there are a number of transactions made by several users in a day, a week and a year. There can be scams or unintentional incorrect transactions that can be difficult to handle. So a transactions management system can be helpful which keeps a track of each users’ credits and debits 

Product: The users’ transactions are recorded and a summary of these is reflected in the form of graphs to indicate users’ balance ups and downs. 

StakeholdersRegur coin holders, Regur coin management team
GoalsTo keep track of transactions made by Regur coin holders and display their balance rates graphically.To record the user’s withdrawals
VisionTo bring innovation to the lending market with secure transactions’ management of cryptocurrencies. 

2. Release information:

ReleaseRelease 1/ Initial release
DateMarch 10, 2020 
FeaturesUser registrationManage users’ RC balance, BTC balance and deposit address Manage withdrawalsShow graphical representation of the user’s balance
MilestonesPhase 1: basic transactions’ management system, Phase 2: Upgrades for file backups and homepage

3. Description of Features:

Feature or user storyAs a Regur coin holder, I should be able to create my account so that I can check my balance
DescriptionUser should be able to sign-up
GoalUser can sign up to the system
Acceptance criteriaScenario: User registers to the system“As an unregistered Regur coin holder, when I fill the email id and valid password and click on sign up, the system logs me up”
Feature or user storyAs a logged in user, I should be able to view balance and deposit address
DescriptionThe logged in user should be able to see his/her BTC balance, RC balance on the homepage and view the deposit address on the deposit page
GoalThe user is able to view his/her BTC balance, RC balance and deposit address
Acceptance criteriaScenario: User views balance and deposit address“Given that the user is logged in, he/she should be able to view BTC and RC balance on homepage and moving on to deposit page I should be able to view my BTC deposit address”
Feature or user storyAs a logged in user, I should be able to apply for withdrawal
DescriptionThe logged in user should be able to apply for a withdrawal by entering BTC address and amount to withdraw (in BTC)
GoalThe user is be able to apply for a withdrawal
Acceptance criteriaScenario: User submits withdrawal application“Given that the user is logged in, he/she should be able to submit a withdrawal request by entering valid BTC address and amount to withdraw (in BTC) and submitting the form on withdraw request page”
Feature or user storyAs an admin, I should be able to view and edit users’ BTC and RC balance and BTC address
DescriptionThe admin should be able to view and edit a user’s BTC balance, RC balance and BTC address
GoalThe admin can view and edit a user’s BTC balance, RC balance and BTC address
Acceptance criteriaScenario: Admin views and updates user’s balance and deposit address“Admin can view a list of registered users (email ID) and along with that view and edit the user’s BTC balance, BTC address and RC Balance ”
Feature or user storyAs an admin, I should be able to view all the withdrawal requests
DescriptionThe admin should be able to view all withdraw requests
GoalThe admin can view and edit a user’s BTC balance, RC balance and BTC address
Acceptance criteriaScenario: Admin views and updates user’s balance and deposit address“Admin can view a list of registered users (email ID) and along with that view and edit the user’s BTC balance, BTC address and RC Balance ”

4. User Flow and Design

   For example, the homepage displays the user’s total balance and graphical representation of the balances by month.

user flow & design

5. Release criteria

Scenario: User applies for a withdrawal

If a Regur coin holder wants to withdraw an amount the withdrawal form request feature will allow the user to apply for a withdrawal and a track of withdrawals can also be kept.

Scenario: Admin can edit Deposit address

In some cases, if the user desires to have a change in deposit address or admin needs to change the deposit address of the user, the admin can edit it. 

In short, the acceptance criteria for each feature should be fulfilled. 

6. Future scope

 In future, there can be a feature for showing the user if the withdrawal request is accepted.

7. Review by the product team:

Checked byQuery/changeAccepted
QA Team
Sales & Marketing Team

On the whole, it can be concluded that the product team collaboration is highly essential for a successful product. Putting the product requirements in one box aligns the members involved in the product development so as to understand the product features correctly and makes it easy for them to deliver efficiently. The document should be shared with each and every team so that progress is made in the right direction.

About the Author


Gladly, working as a PHP/Laravel Developer at Regur Technology Solutions. Strives to explore, learn and grow technically and analytically. Loves crafting in free time.

Leave a Reply

Your email address will not be published. Required fields are marked *