Product Management

The Product Requirements Document

Written by Therese Padilla

One of the most important jobs (and significant challenges) that product managers face on a daily basis involves successfully striking a balance between vision and purpose. The product manager understands the customer exceptionally well, putting them in the best possible position to hone in on the purpose of a product while delivering the proper context of their vision at the same time. At its core, the Product Requirements Document, or PRD, is designed as a communications tool to do exactly that.

I have observed in recent years, many product managers have moved into doing wireframes and prototyping in an effort to meet these goals, and I have seen a shift to replace the PRD. However, after watching this evolution, it is clear that wireframes and prototypes have some value when done by a PM, as long as these tools are not in place of the PRD. Instead, they are a natural evolution of communicating, as it’s easier to demonstrate visually with pictures as well as words than ever before. Despite the fact that the PRD continues on this path of evolution, there are still a number of core components that must always be present for the best results.

The Essential Components of the Product Requirements Document

The number one goal of a Product Requirements Document is simple: it must define the product’s purpose above all else. Why is this product being released versus something else? What problem does it solve in the lives of end users? Why should they care at all?

Next, the document must also define the product’s features. It must tell people what the product is, how it can be used and it must clearly outline who the ideal user types actually are. These all address purpose, but product vision is also woven in throughout all of these points.

It’s also important to strike a balance between describing a product’s features and describing its ultimate functionality. Functionality, in general, is typically handled by a product’s development team in partnership with the business analyst.

The Quest for the Minimum Viable Product

Another important purpose of the Product Requirements Document is to define the release criteria, which is now often referred to as the Minimum Viable Product. When doing this, however, it is important to understand that the terms “viable” and “tolerable” are not necessarily the same thing. Many people think of the Minimum Viable Product as the “Minimally Tolerable Product,” or “how bad can this be so we can still release it but not get in trouble.”

Instead, what Minimum Viable Product means is “what do we have to do to deliver on the intended purpose of the product while maintaining the vision needed to get people to care.”

The Measurement of Fidelity

As stated, prototyping is also a recent addition to the Product Requirements Document as it helps to define something with pictures and models in addition to words. When going down this route, however, remember that fidelity is key. Fidelity being the degree of exactness in the portrayal. And in this instance, the lower the fidelity, the better. Low fidelity is often characterized as post-it notes and napkin sketches. Perfecting the tools is not the goal. For product managers, directing and understanding how to best use tools like prototyping and wireframes is an efficient way to evolve the PRD into a cross functionally effective tool.

Pictures Are Worth a Thousand Words

Providing visuals to the vision and the purpose only helps to tee up the most viable product – it does not take the place of it. Time and again, the product manager must sell their peers on the reason a product MUST exist. As sometimes convincing the internal team is harder than convincing the market, these visual elements can serve as a very welcomed addition to a development phase that is constantly in flux.

Filling the Toolbox

In the end, tools like UXpin continue to play a more important role in the Product Requirements Document as the document itself continues to evolve and change. They are a worthy addition to any product manager’s toolkit. Always remember that adding new concepts like UX prototyping and wireframing is not replacing the intention of the original PRD – instead, it is using the PRD as a solid foundation from which to continue to build a powerful communications tool to help bring both vision and purpose to your audience in the most effective way possible.

About the author

Therese Padilla

Therese is President of the Association of International Product Marketing & Management. She is a product management professional with broad experience in all areas of product development and management, including consumer products, enterprise software in startups and large corporate environments. Therese created the first product management certification program at the AIPMM which she co-founded in 1998.

Leave a Comment