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:
BRIEF AND CLEAR
Success screen when there is a match between two users, with a way to connect.
We need a success screen for every match that will excite the user and nudge them toward the next step (i.e., exchanging messages).
Style should match brand and accessibility standards.
- Prominent success message: “It’s a match!”
- Prominent call to action (send message)
- Not as prominent, but include an easy way to keep swiping
Additionally, we would like to see personalization, e.g., profile pictures and/or nicknames. As appropriate, haptic feedback or vibration, animations, etc., should be utilized as well.
When there is a match, a page needs to appear across the full screen that will show the message “It’s a match!” The screen should include profile images from both users, in large circles taking up a quarter of the screen each (with the user’s own picture on the left side), and the message should be above these images.
Below the images, there should be two large buttons, end to end, one with the text “Message now” and one with “Continue swiping.”
On the buttons to the left of the text, there should also be icons: a chat bubble to message the match and a small heart to continue swiping. All text should be in color #003366, except for the buttons, which should have white text.
The screen should appear with a fly-in from bottom effect, with small fireworks, smiley faces, and heart emojis flying around (seven fireworks, three smiley faces, and four hearts,).
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.
PRD Template Notes
The template is broken into two parts: mandatory and optional elements. Using only the former will result in a lean document, enough to gain the key benefits. Including some of the optional elements is recommended to give additional details as needed. Here’s how to use the template effectively:
1. Document Purpose
This section is vital in defining what the PRD will be used for. Write a short statement or perhaps three or four bullets describing its purpose. For example:
- Document discovery and collaboration with the client
- Outline MVP scope
- Summarize different technologies and possibilities for development
- Detail team needs as they arise
2. Executive Summary
Give a high-level overview of the project, its goals and objectives, organizational and market context, and recommendations.
Pro tip: Fill out this section last, once you have the other elements in place.
3. Who, Why, What, and What Not
Who are we building this product for? List the main user groups of the product, their needs, and pain points.
Why are we building this product? List the main opportunities, hypotheses, and reasonings.
What are we building? Write a short description of the product, its rough scope, or its main features/components.
What are we not building? Write a short description of the functionalities that will not be included and the reasons why.