Imagine you’re a chef at a high-end restaurant. One night, a very important customer comes in (let’s say Meryl Streep) and asks for pasta—but gives no other details. You panic. Sweat begins to gather beneath your toque blanche. If you disappoint Meryl Streep, you’ll be out of a job. But no one will tell you what kind of pasta she wants.
This imagined scenario illustrates why a product requirements document is so important: It’s written by the product manager and details what needs to be built, who it’s for, and how it benefits the end user. It’s the difference between being told to cook pasta and being told to make spaghetti bolognese.
Learn what other benefits you can gain from creating a product requirements document and see how to get started.
What is a PRD?
A product requirements document completely defines the purpose of a product or feature and explains what the product should include. Without this very important document, your team is almost certain to fail because they have no idea what will be considered a successful build.
A PRD keeps everyone on the same page: No one should have any questions about what the product is or what it’s supposed to achieve after reading the PRD. It sets very clear goals and guidelines for a product and shows how the features of a product meet the user’s needs.
What isn’t a PRD?
There’s zero shame in getting a PRD confused with a BRD—there are way too many acronyms in the world. But a PRD is definitely different from other docs you may be more familiar with.
Business requirements document (BRD)
A business requirements document positions the product in context of your organization as a whole. It describes what a new product should do and details the user’s needs and expectations, the reason this solution is necessary, and any constraints that could affect a successful deployment. It doesn’t go into specifications of the product or how it should look or act.
Software requirements document (SRD)
A software requirements document gets into the nuts-and-bolts of the software powering your product. It includes details on interfaces, safety requirements, functional capabilities, performance levels, and related information. These documents are meant for developers, testers, engineers, and clients.
Why you need a product requirements document
The PRD is the vision for the product. Without a vision, what’s there to work towards?
Product requirements documents also show how the product’s goals will be met with different aspects of the product. This document will be used by various teams in your company to help describe the product to stakeholders, help your sales team be able to pitch the product in a compelling way so that they can sell it and get rich, and your designers will know how it’s supposed to look and act. It is essentially a blueprint for your product.
So do you need a PRD? Absolutely. Just as much as a car manufacturer needs a blueprint for a car before getting started on building it.
What should be included in your PRD
Because this document will touch design, support, sales, marketing, and engineering teams, there are a few items that are standard to include.
Key objective
The key objective should explain who you are building the product for, what customer pain points you are hoping to solve, and how this product fits into your goals and vision as a company. This section could also include potential use cases.
Before beginning to craft your PRD document, it’s important that you gather the Voice of the Customer. Imagine you set about building a product without doing any customer research and it turned out that your customers wanted it to feel nothing like a social media app. You’re setting out to build a product that fills a need, so you need to know what those needs are. Once you understand what your customers want, you can then explain how your key objective for the product meets those desires.
Desired release date
You’ll likely have multiple release dates for various components or iterations of the product, especially if you’re using the agile methodology. In your PRD, you’ll detail deadlines for key components of the project. Once this is defined, project managers can start building out scopes and timelines and then placing those into sprints.
Product features
Define the features of your product so people know what to build. Relating back to your key objectives, this section should detail what the purpose of each feature is and what problem it hopes to solve.
For example, let’s say you’re making a marketplace app for selling and purchasing clothes—you want to incorporate all the fun of social media with the excitement of scoring cool clothes for less. In your PRD, you’ll then have the description of what your home feed will look like and show how it meets the requirement of feeling like social media engagement. You may also then have a description of an item’s post with the original price contrasted with the “for sale” price and prove that it meets the requirement of scoring cool clothes for less money. In this way, each feature has a calculated purpose.
You should also be able to detail how the user will interact with the app: Will it have an infinite scroll, will there be an embedded camera feature, and will there be a way to easily block problem users? This should all be defined in your PRD.
Your product requirements document should also include release criteria, goals you must hit before releasing the product. Create release criteria around:
- Minimum functionality
- Usability, measured through user testing
- Reliability
- Performance and speed
- Support
