Is the Product Requirements Document Dead? A Debate.

I recently wrote a piece on about how to write a Customer Feedback-Fueled Product Requirements Document (or “PRD”), which touched on some of the benefits and shortcomings of the PRD, along with ways to incorporate lean methodology into the writing process. Although there are organizations that still use traditional PRDs, many teams have moved to more agile development processes, and several have even thrown out the PRD entirely. As with many tools in the product management arsenal, the document has seen both strong adherents and detractors over the years.

The Life, Death, & Return of the Product Requirements Document

Ben Horowitz (Andreessen Horowitz) and David Weiden (Khosla Ventures) famously remarked - albeit in 1997 - that the PRD is the most important document a product manager maintains. They claimed that it should be used as a product Bible for marketing, design, and engineering.In a 2012 post on product management, Ben Horowitz noted that “this document was written 15 years ago and is probably not relevant for today’s product managers.”Marty Cagan, ex-Product at HP, AOL, and Netscape, wrote the often-cited “How To Write a Good PRD” in 2005. Only a year later, in 2006, he wrote the follow-up post “Revisiting the Product Spec,” highlighting that the PRD had become outdated and that he rarely recommended them to clients anymore.The PRD is far from dead, though. Even a recent lean startup, Product Hunt, used their own stripped-down version of the PRD. Plus, many large organizations or agencies that use the classic “waterfall”-style of product development still use long-form PRDs that they finalize with internal or external clients, then pass off to engineers and designers.In this piece, I take a look at both sides of the PRD debate and present alternatives to the PRD so you can that you can make your own informed decision about its utility for your organization.

Team NO: Trash Your PRD

1. PRDs were made for waterfall, not agile

PRDs were originally created when full product requirements were necessary before a project or production iteration. This is incompatible with key agile tenets.. ProductArts wrote a multi-part comparison of agile and traditional development methodologies in which they point out the main reason PRDs do not work in agile:

“Agile/Scrum develops requirements on the fly during each Sprint. A primary driver for this comes from the belief that the entire set of requirements cannot be known ahead of time, as users often cannot state what they want or need until they see it.”

The second point, that users don’t know what they need until they see it, is by far the top argument for tossing your PRDs. Spec’ing out new products and features based on historical data or anecdotes from interviews is a waste of time and effort if, when you put the first version in front of a user, you realize you have built the wrong thing or misunderstood their real need.

2. PRDs are bloated

Since PRDs aggregate features that address several user needs, they can invite scope creep. It is very easy to get requests from teams or customers and get into the habit of adding “just one more” feature to the document. Before you know it, you have a bloated PRD with unvalidated features that is not read by anyone except strained developers. They will not be happy when you release a product they worked on for so long, full of features that users don’t end up using. In this way, PRDs may encourage you to make poor choices that erode the trust of your team.

3. PRDs encourage “rear-view mirror” thinking

In their post “Throw Out Your PRD!”, M3 Design points out that PRDs are typically based on “rear-view mirror” perspectives of your market that derive from market research and historical data: "Many user-needs are latent – so it is extremely unlikely that you could uncover any game-changing insights through customer interviews alone.” PRDs slow down the process of making a minimum viable product (MVP), testing it, then iterating.

4. PRDs are rarely read

In his book “How Google Works,” Alphabet/Google Executive Chairman and ex-CEO Eric Schmidt states that you need to tell your team something 10 times before they remember it. If PRDs are intended to communicate to your teams, I can assure you they are definitely not going to read your 30-page PRD 10 times!

Alternatives to the PRD

So, you are in an agile environment, maybe even scrum with continuous deployment. If you shouldn’t use a PRD, what should you use instead to get the same benefits without the drawbacks?

1.Prototypes

In Marty Cagan’s 2007 post, “Revisiting the Product Spec”, he wrote that “some would argue that Agile methods accomplish [a renovation of the PRD] by doing away with the spec altogether.” Although he suggests that doing away with the spec entirely is misguided, he breaks down the problem being solved by PRDs and concludes that high-fidelity prototypes of your product are the best replacement for PRDs.

1. Prototypes are easy to create - Interactive mockups using InVision, Sketch, or UXPin can be tested with users with very little difference from full-fledged products. Need something better? You can even develop real app prototypes, just using hard-coded logic and dummy data to save time.
2. Prototypes describe the full user experience - Prototypes can represent the visual and interaction experience for users, as well as a representation of their requirements.
3. Prototypes can be easily tested by all stakeholders - Users, engineering, design, QA, operations, marketing -you name it. Everyone can use a prototype and quickly identify the use cases and functionality of a product.
4. Prototypes are easier to change than products - Features will change during development. It is better to learn and iterate on a prototype than on a completed product. With PRDs, you can only do very limited validation before actually developing the entire product, but with a high-fidelity prototype, you can find issues and opportunities for change in your product long before full-scale development begins, saving time, effort, and complexity.
5. Prototypes are the best way to collect user feedback - Once your user uses a prototype, they will immediately see what is missing. Reading a PRD or even a simpler spec is much more difficult for a user to conceptualize and make an assessment.

Downside: You may not cover all of the conditional logic and edge cases in a prototype, or other parts of the experience, such as transactional emails or notifications. That is, unless you build a very robust prototype. So, you may need to supplement your prototype with user stories and, yes, additional written specs.

2.User Stories

Agile, user-centered design, design thinking - User stories are key components in most modern design and development methodologies. They are even used in some PRDs. In an agile team, however, you can simply use a set of user stories as specs for each feature in a set. These stories can be handed to your engineers who then know what the user needs, and they can determine how best to solve that problem. As a Product Manager, you should work with your engineers on how to do this, but try not to step on their toes with technical decisions.Teresa Torres at Product Talk wrote a great piece on why User Stories Are Better Than PRDs. Teresa compares writing a 15-page PRD to writing 50 user stories. Whether the engineers read the entire 15-page PRD or all 50 user stories at once the first time, when they actually begin working on each component, they will only read each feature one-by-one. As opposed to a single feature in the PRD, every user story “communicates information about the actor, explains the desired action, and the benefit to the user. As the engineers implement each story...they never lose sight of the content of why they are building what they are building.” Helpful examples of user stories are included with explanation in her piece.

3. Hybrid Spec Tickets

A common way to keep the best of the PRD, but stay lean, is to write your product tickets to the engineering team using the same sections you would in a PRD. Spec tickets usually cover a small amount of work. Sometimes this is an entire small feature, but usually it is a particular action or component of the feature.Here is a common spec structure (5-20 lines on average, depending on complexity) :

1. User Story (1-2 lines): Communicate why/what of each logic step w/out too much detail.
2. Business case and supporting data (2-3 lines).(Note: Some engineers don’t care/never read this. This is crucial for future reference and for others in your team to look at later without having to contact you.)
3. Features (anywhere from 3-10 bullet points).
4. Mockups attached (2-3 visual mockups or wireframes of the UI).
5. If-then logic, if applicable.
6. Analytics, if applicable (1 line): Add in whatever tracking you need to measure feature use later.
7. Acceptance testing (1-3 bullet points): Outline expected minimum expected behavior for QA testing.

4. Wireframes and Storyboards

Sometimes it does not make sense to invest in building a prototype, and it may not make sense to spec out a ticket to communicate the user experience. In these cases, it is a good idea to start with wireframes and storyboards. Although these are typically used in conjunction with the above alternatives, some teams work well by sending a storyboard to the designers and engineers for development. This typically works best if you have very close collaboration between product managers, designers, and engineers in a close-knit lean team. It is difficult to keep track of complex logic or backend requirements using these tools alone, but they are very useful in any process.

Team Yes: The PRD Is Still Useful...Sometimes

Several organizations still use PRDs. Let’s look at the reasons why.

Do you use waterfall?

In the linear, “waterfall” style of product development, the PRD might make sense. In this process, the Product Manager will need to outline every detail of how a product works and then hand it off to the design and engineering teams to simply implement.If you tried to use alternative specs, mockups or prototypes, it would become difficult to plan the development process or ensure everything was developed properly, since you only have one - sometimes quarterly - release. If you have only one shot at getting it right, then taking the weeks up front to write out a large PRD and maintaining it throughout the development process might be the sensible thing to do.Of course, you might consider doing what many other teams, from startups to large enterprises, have done and make the move to an agile process (read here for the pros and cons of agile development).

Are you building for external clients?

Many modern development agencies will run on agile processes, but even so, they will need to align up-front with the client and understand the specific needs, edge cases, and security concerns of their clients. If they do use some version of a PRD, it will not usually be 150 pages, maybe not even 15 pages, but they will still have the main components. They will list why the product is being built, who it’s for, the features, edge cases, and how to test whether development has built what is needed.Visual mockups and even interactive prototypes can support leaner PRDs. The PRD is a living document, so it can still be changed in an agile environment so that clients can track the progress and latest version of what is being developed.

Are you building for enterprise?

Some enterprises, either clients or internal teams, will be used to using PRDs and will sometimes require them for security or other compliance or internal policies. Having an updated and detailed PRD can make it easier for regulators, legal, or external teams, who cannot always directly ask the product team, to look through the PRD and understand if the product meets requirements.Building for enterprise is not itself a reason to use a PRD, though. At HourlyNerd, for example, we built the enterprise platform using agile scrum processes, interactive mockups, short spec tickets, and user stories. This was despite some very large security and feature requirements from initial enterprise clients. That is not to say each ticket did not have the components you would see in a PRD, but they were componentized by feature or sub-feature ticket, instead of having one large living document for the entire product. These become easier to navigate if you use tools like Unfuddle or JIRA.

Does your support team need it?

Your customer support, QA, and technical support teams may want a PRD to have a full view of how the latest product or even previous versions of your product work. This will allow them to address user issues quickly, since they can search through the feature spec for the relevant version of the product. This is particularly important for multi-version physical devices or desktop client software, where updates cannot be easily applied. This is still possible without a PRD, of course, with updated support documentation or wikis.

The Minimum Viable PRD

The product management and development process itself should always be iterated and improved. In my previous post, I broke down the Product Hunt PRD, outlining how a PRD could potentially be created while staying lean. If you do decide to use a PRD for your team, consider applying the concept of Minimum Viable Product to the process. Start with the leanest Minimum Viable PRD (MVPRD) with all of the main headings, but only the bare-bones details. Then iterate until you find what works for your team.The intent of your MVPRD is to validate:

1. Whether you need a PRD in the first place, and
2. The minimum you can put into the PRD to stay lean and build effectively.

Align with your engineering, design, marketing, and support teams on the process. Ensure that the internal or external clients are involved, but do not let unnecessary sections or details creep into your MVPRD just because of feature requests. Write your first MVPRD in a short, limited amount of time (just enough to communicate to your team and start work) to avoid bloat. As you move toward or through development, meet with your team frequently to assess and iterate on what should go into the document and what should be taken out. Remember to keep it lean and that your intent is to figure out what you need in the document and if you need it at all.Nick Barr, Product Manager at Canvass, recommended in this Quora response on PRDs that a lean PRD should include these three sections:

1. “User Stories. What is the exhaustive list of features we need to build for this project? What are the user stories that the development team should execute on?”
2. “Wireframes & Mocks. What does this thing look like?”
3. “Success metrics. How do we measure success? What metrics do we need to instrument and track?”

If you think you must use a PRD, Cisco Product Manager Peter Lamar has helpfully outlined a “6-pager” agile PRD. Features are outlined at a high level, equivalent to “epics” in agile methodology, then broken down into user stories. You can use this as a starting point.

The Decision

It is often said that Product Management is an art, not a science, but that is mostly because every combination of team, product, market, and technology is so different that no one exact process will work in every organization. It is important to test and reassess your process frequently.If you are just starting out with no set process, your team should align on what they think will work and go about testing and iterating on that process. Although you may try using the PRDs alternatives, such as Prototypes and User Stories, your team should at least consider trying to incorporate the main sections of the PRD somewhere in your process, or even test out a minimum viable PRD.If you already use traditional PRDs, especially in a large team, I suggest running an exercise with your engineering, design, product, marketing and any other relevant teams:1. Present a true minimum viable PRD that is totally stripped down.2. Working together, think through the realities of your process and add back only those components or details that you actually use frequently and are critical to the process.3.Come up with some alternatives to the PRD that may accomplish the same goal, and compare the potential effectiveness of each approach.What you will uncover from this process is a much leaner document and some interesting new ways of working to improve your team’s performance and efficiency.Whether you keep the PRD or use another method, any good team should be regularly and formally reassessing and iterating on their process. Treat your product management process as you would treat your product: Build, measure, learn, and repeat.