A product requirements document (PRD) is an artifact that product teams use to describe the solution they are providing in order to solve a specific problem.
A good PRD identifies the outcome you’re trying to achieve and describes the product your team is aiming to deliver in order to reach that outcome. The description of the product includes who the product is for, an overall view of the product, and the main elements of the product organized into a set of planned releases.
A good PRD does not have to be an exceedingly long document. It needs to be long enough to help establish a clear understanding and it needs to be clear and concise enough that everyone on your product team can refer to it and understand what they’re trying to deliver.
The contents of a product requirements document will vary based on your business, your product, and your team. Even though the content depends on several factors, you’ll usually see some form of the following:
This is a general outline of a PRD. The specific contents of your PRD depend on your organization, your team, and your product. To help you decide which sections are most appropriate for your PRD, here’s a brief description of each section.
This PRD section explains why you’re building the product in the first place. It explains the outcome you’re trying to achieve in terms of the problem the product is intended to solve for your customers.
This PRD section establishes metrics you can use to gauge when you’ve achieved the outcome and hence measure the success of the product. The metric included should be from the perspective of your users and indicate a way in which the product delivers value for them.
This PRD section identifies any key people involved with the development of the product and includes which product team is working on the product as well as any subject matter experts who may not be full-time members of the product team.
This PRD section explains for whom you are solving problems. You want to be clear on whose problems you are solving and whose problems you’re not solving. This clarity helps ensure that you’re focusing on the right people and not trying to solve problems that aren’t relevant.
When you identify your personas, make sure they are based on actual data and that there are significant differences between each of the personas you identify so that each one represents a different challenge that you need to focus on.
This PRD section provides a big-picture view of your solution. The more you can use graphics, whether its customer journeys, process flows, or wireframes, the more context you can provide for your solution.
These designs and wireframes help put the specific scope items in perspective so that your team doesn’t lose the forest for the trees.
It’s important that the wireframes don’t have to be perfect or gorgeous. They need to be clear enough to convey the overall idea of the solution and how your users will flow through the product.
This PRD section describes your best guess at the small chunks that you can organize your solution into in order to deliver it. These chunks may be features, user stories, or whatever concept that your team feels comfortable with.
Whatever you may call these chunks, each one needs to deliver some form of value to your user and/or customer and they should be as independent as possible.
You use these scope items when you’re laying out your releases to identify those things that are absolutely necessary for the first iteration of your product, those things that can be delivered, and those things that you may not need to deliver at all.
Every scope item should be related in some form to achieving the outcome you identified, but you shouldn’t feel compelled to deliver every scope item. In fact, it’s helpful to think of scope items as options rather than absolute requirements.
This PRD section describes what you plan to deliver when. It’s a way of indicating your best guess at how the scope items should be organized in order to deliver the most outcome in the shortest amount of time with the smallest amount of output.
Because release details can be somewhat fluent, you may decide that your product requirements document may not be the best place to record this information. You may find that whatever tool the product team is using to track their day-to-day work may be a better place to record release details.
This PRD section explains things that you believe to be true and that factor into your decisions about a solution. It’s important to note assumptions so that you know what your solution is relying upon and so that you can identify efforts you need to take to validate that those assumptions are true.
This PRD section identifies any uncertainty you have in the solution along with noting the likelihood of the event occurring and the impact when it does.
Noting this information helps you to determine if there are actions your product team needs to take to reduce the likelihood of a particular situation occurring and to listen to the impact when it does happen.
This PRD section identifies any restrictions on your solution, whether they come from a limited budget or certain technical restrictions that are in place.
This PRD section identifies any activities or initiatives that the initiative relies on being in place in order to be successful. These dependencies are important to note in order to properly lay out the release details.
You’ll generally use a product requirements document to describe a completely new product, a significant product update, or additional functionality for an existing product. A PRD is generally an overkill if you’re making small tweaks to a product, are adding a small feature, or are making changes to existing functionality.
During the development process, you’ll create the PRD once you know the problem you’re trying to solve and want to describe the solution. The problem description may be written up in a Marketing Requirements Document (MRD) or it’s something you discuss with the product team.
The way you use a PRD depends a great deal on the approach you take to product development.
If you take a sequential approach to product development — sometimes referred to as “waterfall” – you use the PRD to describe the product you’re expecting engineering to build. In effect, you use it as a handoff to engineering with expectations about the solution.
In this case, which admittedly is less common than it used to be, you’d attempt to fully flesh out the PRD then hand it over to your product team for them to build the solution.
If you take a collaborative approach to product development — ie “agile” – you can use the PRD to capture agreements about the problem and solution. The members of your cross-functional product team can use the PRD to guide discussions and collaboratively flesh out the solution you’re building.
In this case, you would create an initial draft of your PRD and then use it as a way to structure the conversation with your team to flesh out all the specifics. You find it helpful to use an app that allows multiple people to edit a document at the same time.
