Product Requirements Document

What is a Product Requirements Document?

Definition: A product requirements document (PRD) is a detailed outline of all functionalities a software product must fulfill when being delivered.

The PRD describes the magnitude of a product and serves as a record of all features that must be realized or in retrospect, must be found in the product. 

Each functionality is characterized as an individual use case and needs to explain its purpose to establish an accurate understanding for a cross-functional team to take measures during the implementation process.

Get our Mastering Prioritization eBook

Learn how to prioritize by making it a simple process, to build products that stand out. Learn more about how to source insight, choose the right prioritization framework and much more.

Get the eBook

Additional conditions such as environmental requirements, e.g. hard- and software utilization of the end-user, constraints, and dependencies also need to be specified in the product requirements document.

What should a product requirements document contain?

Product requirements documents (PRDs) usually include the following elements:

• Purpose - Who the product is for and why you are building it. Including this high-level objective helps align the team and allows all of you to focus on what’s really important (and what isn’t)

• Features - What you are going to build. Also referred to as the user story, having this short description of the software requirements means the development team is crystal clear on the task ahead.

• Release Criteria - The goals for the release, including functionality. This way, internal teams will have a better grasp of the timeline and the scope of the release, which allows them to plan more efficiently.

• Timeline - A rough window or schedule for the release.

Your PRD should take a top-down perspective, beginning with a broad vision of the goals you wish to achieve. It should then link product objectives and efforts to the features needed to realize that vision. A proper PRD also provides information about what the user will see — and how — while interacting with the feature.

The golden rule is for PRDs to be clear and concise.

What are the steps in creating a PRD? (and how to start writing) 

Writing a product requirements document might come down to just one person, but multiple people or stakeholders will be involved in the thinking behind what’s written.

Below, we’ve listed the five steps in creating a PRD.

1. Establish the product’s purpose

The product and development team has to be aligned, sharing the same objectives of the product vision. This purpose must be the driving factor for the features and should outline the problems solved by the product, the target audience, and why exactly is it important to solve those problems for them.

2. Put forward the must-have features

What are the release feature requirements? Remember that if a feature doesn’t help achieve the product’s purpose, then it shouldn’t make the list. 

Defining initiatives and themes is a common practice when it comes to setting the feature requirements. A good theme can align a company for years. Examples of themes would be harnessing IoT technology to improve user experience or helping amateur photographers access professional-grade tools.

3. Set your release criteria goals

In order to achieve the objective of the product, you need to set the right goals. The goals of the product should make it actionable, easy to understand, achievable and measurable. The release criteria, in particular, has five areas it needs to cover: usability, functionality, reliability, supportability and performance.

4. Agree to a timeline

You don’t need to set an exact date, but every product release has to have at least a rough estimate of when you’ll go to market. Keeping it rough will allow for pivots or unforeseen issues.

5. Review your PRD as a team

When you finish your PRD, you need to have the stakeholders review it. Be flexible to any changes they might ask of you, as the only way a product requirements document works is when it has full team buy-in.

What’s the difference between a PRD and an MRD? 

It’s easy to get PRDs and MRDs confused — especially when just the initialism is used. Once you see the full name, the differences become much clearer:

• PRD = product requirements document

• MRD = market requirements document

As covered above, the PRD outlines how the product should be produced, while an MRD defines what customers require and how the product will meet those needs. 

You can think of the PRD as a roadmap for engineering and design teams, as well as other large cross-functional teams, in order to grasp what the product needs to deliver to add value. 

The MRD should be written first, and then the PRD. After all, you need to have explored the market opportunity before deciding to build a product.

Because of this, the MRD is often created by product managers during the early phases of a brand-new product launch — perhaps in Product Discovery. But it’s not a ‘once and done’ process. Changing market trends and growing consumer demands always bring new product options, so it’s a good idea to review the MRD on a regular basis, even after the PRD is complete. 

Both MRDs and PRDs need to be open to change.

> Here is an example template of a product requirements document from Atlassian.