The PRD Isn’t Dead: New Best Practices for Digital Product Development

When Agile was first experiencing large-scale adoption in the early 2000s, it revolutionized software development and traditional ways of working. As a result, many staples of the Waterfall approach were seen as outmoded. One of these was the product requirements document (PRD).

The PRD was once described as the “single most important document the product manager maintains” by technologists Ben Horowitz and David Weiden, but its relevance and value in product development has been hotly debated for the past two decades. There are impassioned advocates, experts who believe it to be defunct (see this 2006 blog post from product thought leader Marty Cagan), and many others sitting on the fence.

They all have valid points. My belief, though, is that the issue is not whether to use a PRD, but rather how.

Organizations, products, and markets all create a unique context for which there is no one-size-fits-all PRD, but by implementing these tips and advice where applicable, and using the free template provided below, you can revive the PRD and make it a valuable component of your digital product development process.

The Value of a Good Product Requirements Document

In my many years working as a product manager with various clients and teams, I have found the PRD to be an extremely useful tool, but its value depends on how you utilize it and what it contains. When a PRD is crafted thoughtfully and used with care, these are some of the high-level benefits you can expect:

Internal alignment: A PRD is a great tool to achieve team alignment, particularly in remote or asynchronous settings. It acts as a guiding document, ensuring the team understands what they are building, what they are not building, why they are building it, what the priorities are, and how success will be measured.

External alignment: A PRD can have the same results for other stakeholders and clients, helping teams manage the scope and outcomes of their project transparently and communicate changes proactively.

Collaboration: A PRD does not exist to enable the autocracy of the product manager or any one individual. Rather, it is a tool of and for continuous collaboration. It is a place where engineers, designers, and product managers can gather together to work on defining user stories, for example, or creating ongoing dialogue with clients about goals and priorities as contexts evolve and new learnings surface.

In order to create an Agile-enabled PRD and reap these benefits, there are several common pitfalls you and your team must avoid.

How to Avoid Common Pitfalls

Before Agile’s dominance the PRD was at the core of software development, capturing the very essence of the product. Because of its pre-Agile origins, a traditional PRD is more suited to a Waterfall system with clearly defined, sequential steps (i.e., definition, design, delivery). But a PRD can and should be used as a principal element in Agile settings too. We simply need to adapt the format and content of the PRD for a modern-day context. Here are my best practices:

1. Balance Rigidity With Flexibility

There are two ways to think about rigidity: the rigidity of the PRD itself, and rigidity in the way it is viewed within the organization. Both types commonly occur when creating and using a PRD, but we’ll address the former first.

A rigid document is close-ended, leaving no space for the team to research or implement other solutions during development. But you should make a conscious effort to balance clarity on the desired outcome of a project with the flexibility to make adjustments as you learn new information. The Shape Up method, developed by former Basecamp Head of Product Ryan Singer, can be used to help you find harmony between providing the fixed direction promised by a closed PRD and giving teams room to build products in an agile way.

Another option to prevent the rigidity of a traditional PRD is to use it to describe measurable success criteria. In the context of a game app, for example, the aim would be a 10% increase in users sharing their scores on social media with a redesigned end screen and a smoother sharing experience. This option doesn’t specify the best solution to achieve this, thus allowing for more granular research and discovery.

2. Treat It As a Living Document

The way the PRD is viewed within the organization is paramount to its value. How can you expect to be an agile team when working from a fixed document? Likewise, how can you expect the document to work for you if you don’t use it in an agile way? When a PRD is used rigidly, by being strictly adhered to or enforced, it can impede creative discussions and product discovery, encouraging a Waterfall mindset and hindering overall agility.

Unconditionally following a set plan is a recipe for disaster in software development—considering your PRD “finished” is a common yet counterproductive approach, as the document will quickly become outdated.

Endeavor to continuously refine the PRD and treat it as a living document. Avoid having a chain of review or approval every time a team member makes an adjustment. Most importantly, ensure your team is well versed in a framework such as Scrum, Kanban, or Extreme Programming, so they are able to respond to feedback, incorporate new learnings, and constantly reevaluate. If the team is working in an agile way, they are more likely to use the PRD in an agile way too.

3. Keep Descriptions Brief

Another common pitfall is to cram the PRD with too many details, resulting in a large, verbose document that is difficult to understand and maintain. This typically happens when excessive information is included within the feature description—every single feature element, exhaustive design specifications, or implementation instructions.

Being brief does not mean sacrificing clarity, however. A clear PRD will still include the fundamentals: the goal of each feature, the essential elements, and the guidelines for delivery. Here are examples of different feature descriptions for a dating app:

Even in the “Brief and Clear” example, there is potentially superfluous information: For example, the guidance on brand and accessibility standards, and also on haptic feedback, may not be necessary if it applies to each feature and particularly when organizations have design teams who are familiar with these standards. If this is the case, you can tighten up the feature description even more.

Rather than extensively outlining what is included, it can be more efficient in some cases to use a “won’t do” list, perhaps in an out-of-scope section or using the MoSCoW method. The list should only address items unique to the context or where there may be uncertainty, such as items removed from the scope that would usually be included, items not aligned with regulations, or edge cases.

An important factor in the level of detail you choose to include will also be the team’s experience and the maturity of the product. If your team comprises senior professionals who have worked together before, or if you are building a product that has established standards and guidelines, brief documentation will be enough.

The famous quote “I didn’t have time to write you a short letter, so I wrote you a long one” is applicable here. It will take a lot of effort to keep the PRD brief while communicating all the necessary information, but it is a worthwhile investment.

Use This Product Requirements Document Template to Maximize Success

To get you started, I have channeled all my learnings and guidance into the ultimate PRD free template, available for download. If, in its current form, it is not suited for your unique context, experiment by removing or incorporating different elements to make it work for you.

An Agile-enabled PRD is a hugely valuable tool. By keeping it brief, flexible, and alive, your PRD can foster greater alignment, clarity, and collaboration—all of which are essential in the creation of innovative, useful products.