How to write a product requirements document (PRD)
Note: If you want to skip my advice on how to write a product requirements document and go directly to a sample PRD, you can click here.
Ben Horowitz and David Weiden, in their legendary internal memo at AOL titled "Good Product Manager, Bad Product Manager" wrote:
"Good product managers clearly define product requirements - in writing."
There isn't a single product manager, developer, designer, or test engineer I know, who would disagree with this statement. However, where I see most new PMs struggle is not the why, but how to write a product requirements document or PRD. Over the time I spent making the transition from former data analyst to product manager, I've internalized some critical learnings on how to write a great PRD.
It is (usually) not a tool of persuasion.
I know some PM's who try to add every bit of market research and analytical test result to their document. At its core, the PRD is a way for the product team - PMs, engineers, and UX designers to stay on the same page (no pun intended) about how the product should look, feel and act. Anything more than that and you're unnecessarily burdening your document with distractions that often overwhelm the reader.
Usually, the team has already agreed that a feature or set of features is needed before the PM ships the final list of requirements. At most, I add a small product brief where I include a brief (20-30 words) note on why the market needs our product.
Know your audience
Over time, you'll develop a shared vocabulary with your engineering team. Keep in mind that you customize the language in the document for the person that is most likely to read it. Sometimes that can mean referring to a technical detail like an internal API. Sometimes it can mean using familiar acronyms. Don't hesitate to make the document as easy to consume for your team as possible.
It's about what to build, not how to build
Your product requirements document is not a technical specification. It shouldn't define database schemas, dictate sorting algorithms, or suggest UI frameworks. I can't stress this enough. I don't care if you used to be an engineer. In my experience, the team will deliver a product far superior to anything the PM could've imagined or built - 99.99% of the time.
Instead, focus on writing crisp sentences of what the product should do. Write in precise input-output combinations.
Do:
"When the user begins to type her query in the search field, show her a list of suggestions for finished keywords based on our best guess."
Don't:
"After the first three keystrokes, the app should call the autocomplete API with the search query, user ID, and unique browser ID. The autocomplete API would pre-compute an inverted index of finished keywords based on the already typed characters. Rank suggested keywords by using probabilities calculated using a naive bayesian algorithm."
Write short sentences, but long paragraphs.
In "Good Product Manager, Bad Product Manager," the authors suggest that "good product managers err on the side of clarity."
When writing your PRD, remember that it is the team's best effort to describe the solution they've identified. It is essential to be as detailed as possible with all the user outcomes the team can envision.
However, detail needs to be matched by readability. Use short sentences to describe the essence of a requirement and expected user behavior. But then, illustrate with examples to drive the point home. The example given below extends the reader's understanding of the autocomplete feature:
e.g., if the user types "Har," we should suggest "Harry Potter," "Harvard Business Review," and "Hardy Boys" as rank-ordered suggestions for finished keywords.
Aim for completeness, not completion
Often when new PMs are figuring out how to write a product requirements document, they make the mistake of aiming for a perfect solution.
Your objective when writing the document is not to craft a perfect vision for your product. Want to include AI in your feature? Do you have the training data or the data science talent on your team to build it? The answer is probably no. If so, include a note that says, "For the first version of this product we will not include any sophisticated AI." Done? Ship a PRD that reflects a version of the product that can be built now. Not later.
Similarly for so-called "corner-cases." If your research indicates it's not a big deal, be courageous. Say the team doesn't need to build for it and move on. If it's something you hadn't thought of, have the humility to say you'll look into it. Look into it.
Building products is a team sport. It takes a village or, at the very least, a scrum team to write a PRD. While the PM is the final authority on what goes into the documents, their most significant role is that of a scribe. It is 100% OK to tell your team that these requirements may change as you learn more.
This unfortunately, is all the advice I have on how to write a product requirements document. Feel free to click on the link below to see a sample PRD for a search engine for an online bookstore.