A Product requirements document (PRD), simply put, is a document that lists out all the features of a product in as much details as possible. In product management world, a PRD is nothing less than a Bible. It is the Product, Design and Tech teams’ go to document for anything related to the product.

A Product requirements document (PRD), however, is different from a Business Requirements Document (BRD) / Market Requirements Document (MRD). A BRD/MRD focuses more on what the actual customer problem is or what the business opportunity is? The “why” part of things. A PRD, on the other hand, focuses more on the “What” and “How” part of things. What are we going to build and how are we going to build it?

So, how does one write a good Product requirements document (PRD) ? Now, there is no fixed standard template for a PRD. Every product manager has their own writing style. However, there are a few key components that every PRD must must have. Below we try to list down the same.

1. Objective

This section talks, at a high level, about why we are building this product, what is the customer problem this product will solve, how the product will help the business grow?
Please note that not every product is supposed to change the world or have an org level impact. Even a simple objective like “achieving competitive parity” would also suffice. The key point is that all the concerned stakeholders should be on the same page with respect to the objective of the product.

2. Success Criteria

Success criteria lists down the quantitative metrics which would be used to measure the success/failure of the product once it is launched. Try to be as specific here as possible, leaving nothing open to interpretation. For e.g. – 
If you are revamping your sign up flow with the objective of reducing the user drop off, then your success criteria can be, let say, “10% drop in the incomplete/abandoned sign up requests”.

You can define multiple metrics as your success criteria as long as your system has the capability to properly measure the same.

3. Product / Feature details

This is where the meat of the PRD is. This section lists down the actual feature/sub-tasks of the product, usually written in the form of a “user story”. A user story usually follows the below format – 

As a [user type], I want to [perform certain actions] so that I [achieve certain goals].

Let say, you want to store users’ credit card details in your ecommerce platform for faster checkouts. Then you user story would look something like – 

As a buyer, I want to store my credit card details in my profile so that I don’t need to enter the details every time and I can do faster checkout.

Though the above format is an industry standard, it’s not written in stone. Feel free to adapt to whatever format your team is comfortable in. The key is that Product, Design and Tech should be able to clearly understand the requirements. Also, try to cover all the corner cases as well while writing the user stories. For e.g., in our above example –

• What would happen if the user enters the card details, but your system is not able to verify the same with the bank?
• Should there be a limit on the number of characters in the name field of the credit card details?

In addition to the user stories, depending on the complexity of the product, this section should also contain the below fields –

• Flowchart / Process flow diagrams
• Implementation / Tech Architecture details, if possible
• Assumptions made while building the product 
• Constraints or the known scenarios where the product won’t work
• Prerequisites / Dependencies on some other data or products

4. User Experience (UX) flows / Designs

This section will include some visual representation of the UX or user journey in the form of wireframes or low/high fidelity prototypes. The age old saying of “a picture is worth a thousand words” aptly fits this situation. Having a clear vision of how the product will look like to the end user will further solidify the product understanding you detailed out in the previous section. Also, add in some screenshots from your competitors for reference if a similar feature is already available on their platform. As mentioned in our post about “Top 5 Product Management tools” –

“As a product manager, you should be able to clearly communicate your vision of the user experience and user journey to the design team. If your vision of the UX is all verbal then there is going to be a significant gap between what you thought and what the design team created. This would lead to lot of unnecessary iterations and would also undermine your credibility within the design team.“

5. Roadmap / Release plan

A PRD should also have some info about the tentative release timeline for the product. If it is a complex product, then probably it’ll have a phased release where a certain set of features are part of the MVP (Minimum Viable Product) and the remaining features go out as subsequent releases. This will help the tech team to prioritize and allocate the resources accordingly.

6. Stakeholder Review & Sign-off

This is a very important part of the PRD and is often left out by a lot of product managers, even at big MNCs. The review & sign-off is extremely important from an implementation / execution point of view. This brings in accountability into the system. This forces the stakeholders (Product, Business, Design, Tech) to commit to a certain set of features and ideally, there should be no going back.

Often, product releases are delayed because – 

• Product team tries to increase / change the scope mid development
• Business team goes back on their word and change the requirement itself. Sometimes they just plainly refuse (pretend to forget) that they agreed on a certain key business requirements / assumptions.
• Tech team tries to change the implementation / UX to simplify the tech complexities.

The above behavior may not sound professional or would make a lot of people uneasy, but this is the truth and you know it.

As mentioned in our previous post about “Top 10 Product Management skills” –

“Tech is usually the easy part, people are the ones that bring complexity.“

Agree/Disagree with the above list? Have anything to add? Let us know in the comments or through our social media.