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:

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:

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:

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:

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:

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. 

2. Release information:

3. Description of Features:

4. User Flow and Design

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

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:

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.