Adventures in
PM land

A blog mostly about product management

What no one tells you about PRDs

September 1, 2020

You may have heard of the infamous Product Requirements Document: the mysterious, magical, monolithic document that designers and engineers use to turn our ideas into a product or feature. We all wish it were that easy. Writing good PRDs is hard because there's no one right way to do it. Just like good PMs, your PRDs need to fit their own industry and organization. In the end, all PRDs have a commonality: they specify the requirements of a product or feature. And given those commonalities, here are three tips.

It's all about context

When I first started as a PM, I was so excited to start building that I jumped right to the "proposed solution" section. I made that mistake so you don't have to. Nowadays, I spent most of my time writing the history, context, and purpose of my requirements. Here are two reasons why.

Let your team do their jobs

Your designers and engineers are smart. Believe me, they are better than you at designing and engineering. You want their input. You know what they're probably so not good at? Having a deep understanding of the why behind the wonderful work they do. When you distill complex business needs and priorities into a PRD, you deliver important context to your team. If they are aligned to the right goal, your team will come up with unique solutions and ideas.

Do it for posterity

PRDs are a snapshot of your current thinking. They capture goals, rationale, and historical approaches to a specific problem. Whether you're a new PM or have always worked at the same organization, you'll eventually find yourself wondering why a feature was built a certain way. Or whether a certain approach to a familiar problem has already been tried. For future readers, the part that outline what to build will least interesting part of your PRD. They know what was built.

It's just the tip of the Iceberg

Fundamentally, writing a PRD is about taking an extremely large number of competing priorities and boiling them down to specific requirements. It's about picking the right problems to work on. Know what shouldn't make it into the document? Almost everything you thought about before you arrived at the right problems.

“I didn’t have time to write you a short letter, so I wrote you a long one.”

~ Mark Twain

In the process of writing a PRD, you should be defining semantics, considering edge cases, and evaluating competing priorities. Most of that work lies outside the scope of the document itself. Besides, no one will read your 20-page PRD no matter how beautifully it's written.

Collaborative, Living Document

At some organizations, you'll be encouraged to take your PRD and "throw it over the fence" to be implemented. Generally, it doesn't work out. The best teams will collaborate to achieve the goals laid out by a PRD. That means your should share your PRD as soon as you have a first draft of your requirements. It bears repeating: share your PRD early. It is not a work of art: It is utterly functional. Do not fear judgement. There is no PRD connoisseur to snootily look down upon your document before you have it "perfected." Your team will appreciate the chance to give input before it's finalized.

Tags: product management prd