PRDo’s and PRDon’Ts - Why the PRD Is Still a Critical Communication Tool

Ari Paparo, one of the mythic-status PMs in the advertising world, tweeted that the more he hears about modern Product Management processes, the more he feels like he was simply “winging it.”

Hey, Charlie Parker improvised too. No shame!

It’s funny, but I suspect that Ari’s version of “winging it” is probably more akin to a jazz musician’s improvisation toolbox. Jazz musicians know the tunes inside and out. The chord progressions are not a mystery. Neither is the form of the tune. The musicians understand chord substitution and how the bass should move. And most importantly, they possess a preternatural feel for what note needs to be played, and when. They used what they knew, and stood on the shoulders of giants.

But of course, jazz (like product management) is iterative. The tools used by Louis Armstrong might be the same as those used by Wynton Marsalis, but how each man presented the result of their usage to their audiences is wildly different.  And that’s a good thing! As a discipline matures, the tools and processes that support and enable it should mature as well.

Unfortunately (for me anyway), one of my favorite tools of the trade, the PRD, has gotten a bad rap. A PRD (Product Requirements Document) is produced to outline what is needed to build a feature or product. 

It’s become a denigrated part of the product release lifecycle. It doesn’t belong in the modern Product Management toolbox. “It’s dead!” “It’s useless!” “This other type of document is far superior!” All of those articles are what I found when trying to figure out whether a PRD is a good investment of time.

eBook

All You Need To Know About Product Management

Read now

And what IS “it” is weird and scary!

But, as you probably saw by checking out those links, the main point the authors are making is that the PRD isn’t bad, it is simply insufficient.

A list of requirements without context is absolutely insufficient.

But this does not need to be true, and like so many tools and processes, a PRD is only as effective as you, the Product Manager, make it. You can wing it, or you can use what you know to create the Product documentation version of Kind of Blue.

Good PRDs, Bad PRDs

Since imitation is the sincerest form of flattery, and we’ve already discussed the similarities between Product and Jazz, I thought I might stand on the shoulders of a giant myself (in this case, Ben Horowitz) and outline a set of criteria for Good PRDs and Bad PRDs.

Obviously, like anything in Product Management, these guidelines depend on your ultimate goals with the PRD. But if clear communication and transparent motivations are your outcomes, then these rails should serve you well.

Good PRDs are flexible. They are living, breathing documents that evolve over time and contain a change log (most documentation tools provide this out of the box). Bad PRDs are rigid and inflexible. They are designed to be presented as final. Their history is a black box.

Good PRDs are collaborative. They encourage and are designed to contain and solicit input from Engineering, Analytics, Design, and more. Good PRDs call out the good work of other teams. Bad PRDs are written entirely by the Product Manager. Other teams are not given space or freedom to provide input. Other teams also are rarely given credit for their work.

Good PRDs open with Context that sets the tone for the rest of the document. The Context section is where the Product Manager provides the qualitative business case for proposing the feature or product. It also gives readers any qualitative or anecdotal evidence that the problems solved by the feature exist.

Bad PRDs provide limited or no context for readers. They assume that anyone reading the document is familiar with why it was produced. It makes no mention of qualitative user feedback.

Good PRDs explicitly outline the Numbers to back up the Context. They have organized data that connects the dots from Context to Problems. Good PRDs may contain visuals that help readers digest the Numbers. Good PRDs also explain the interpretations of the data, and why those interpretations matter. Finally, they cite the sources of the data so collaborators and readers can reproduce the results, and find gaps in logic or call out issues.

Bad PRDs contain raw quantitative data or no quantitative data. They rely on the reader to interpret any numbers in the document. Bad PRDs don’t provide sources for the data because a bad PRD is intended to be rigid and inflexible. A bad PRD doesn’t want readers or collaborators to question its data.

Good PRDs contain a list of the specific customer and business problems that the proposed feature can solve. They frame each problem succinctly, and don’t present the feature as a cure-all or silver bullet. Good PRDs present each problem as a unit, so that the progress against each can be measured. They use known problems and can present new ones.

Bad PRDs may present problems to solve, but without numbers or context, contain no assurance to the reader that these are, in fact, Problems.

eBook

All You Need To Know About Product Management

Read now

Good PRDs outline goals in plain English. Those goals are related to the problems and the numbers and the context. Bad PRDs obfuscate goals with jargon.

Good PRDs explicitly outline which outcomes are impacted by the product or feature. They link themselves to the Outcomes-based Roadmaps that exist across product teams.

Bad PRDs don’t reference Outcomes (but that might be because they weren’t set properly) . They reference disconnected or unrelated ideas that may be beneficial, but are not necessarily strategic.

Good PRDs limit their Scope to an MVP. They present future phases as possible, but not guaranteed. Good PRDs link their MVP Scope to the Outcomes and Problems they’ve established, and there is no confusion as to why each piece of the MVP is required. Each requirement in the Scope portion of a Good PRD is high-level, and encourages Design and Engineering to be creative with the solution.

Bad PRDs don’t focus on an MVP, and instead insist that each phase is required before the feature or product is viable. In fact, a Bad PRD can, in fact, contain nothing other than the Scope section. Each requirement is prescriptive, and does not invite any input from Design or Engineering. 

Bad PRDs try to be end-to-end solutions, and contain precise instructions for building, instead of outlining simply what needs to happen.

Good PRDs tend to contain Alternative Solutions, so readers can see what was considered and discarded. They also contain Non-Goals, so it is clear what functionality or use cases the product or feature is not going to have or solve. Bad PRDs don’t establish these things because they are not concerned with anything other than the prescribed solution.

Good PRDs propose how to measure the success of the feature or product, and encourage feedback. They are ruthless with their own measurement, and relate the proposed KPI(s) back to the Outcomes. Bad PRDs present the feature or product as unmeasurable, or claim that there is no metric or KPI that can capture the success of this uniquely brilliant solution.

Good PRDs explicitly outline which cross-functional teams and/or which customers will be impacted by this feature or product, especially if that impact might be negative in any way.

Bad PRDs are not concerned with the solution’s impact on people, and are simply a means to an end (shipping).

Good PRDs outline any currently-open questions and known risks.

Bad PRDs assume there are no risks, and that any possible questions about the feature or product were answered within the scope of the current document.

eBook

All You Need To Know About Product Management

Read now