Product requirement doc template

If you just want the template then here you go! Otherwise, continue reading to learn more about product requirement docs and templates.

Why you should write product requirement documents

The most important reason to write a product requirement doc is for your own understanding. The process of writing the product requirement doc will undoubtedly reveal areas where your understanding is not as deep as it should be. This will lead to a better understanding of the product and a better outcome. I write blog posts for the same reason, to better understand topics that are important to me.

Product requirement documents provide documentation of product evolution. They are easy documentation to manage because they do not need to be kept up to date. Instead, they describe why product decisions were made at a specific time. Product requirement docs are useful documentation for new product managers. Product requirement docs can also be referenced by other future PRDs and in this way, the collective knowledge of the organization can be built up.

Product requirement docs can be used to drive consensus. In my blog post Driving consensus in an engineering organization, I outline the what, why, when, and how of consensus, so I will not repeat that here. My choice of Google Docs as a product requirement doc template allows the document to be easily copied, shared, and commented on. I also include a table at the top of the template where the participants in the consensus process can be called out with their status. You can use any product requirement doc to drive consensus, my template just makes it easier and more explicit.

My consensus blog post gives some ideas about when consensus needs to be driven and when it does not. If consensus needs to be driven about an product feature, that means a product requirement doc needs to be written. Although there are other reasons to write product requirement docs, this is a good place to start when deciding if a product requirement doc is necessary.

Why you should use product requirement doc templates

Product requirement doc templates are a place where organizational learning can be gathered. When something goes really wrong then a postmortem should be completed to understand what happened and stop it from happening again. If the issue was caused by a product requirement problem, then the long-term solution may be to update the product requirement doc template to make a relevant consideration more explicit (more on this in “How to use my template”).

Having standard templates to use for product requirement docs speeds up the writing process. Proposers will not need to make decisions about what sections need to be covered. Proposers will understand over time what information is most useful to include in their requirements and will focus on those areas during product area research.

Having standard templates to use for product requirements speeds up the review process. Reviewers can learn over time what to look for and where.

How to use my template

As a first step to use my template, make your own copy. Then start copying from your template for each product requirement. If you run into a problem twice consider adding a section to your template. This means if you run into some user experience-related product issues you may want a user experience subsection under the Non-Functional Requirements. Be careful with being too reactionary with making edits to the template. You may want to perform a postmortem to validate that the user experience issue was caused by the product requirements and not an error in implementation or something else.

Although I recommend using the table at the top of the template to manage your consensus process, this is not necessary. Writing a product requirement doc without a consensus process will still give you good benefits in terms of improving your product requirements and producing documentation. If you do decide to use this template for driving consensus, make sure that there is at least one reviewer who is an engineer and one who is a product stakeholder.

Do not become dogmatic about the product requirement specification process. Although the benefits of writing product requirement documents are significant, not all organizations recognize this. Always be cognizant of the environment and adapt accordingly.

Defining product requirements should be fun! If you find yourself dreading writing an upcoming product requirement doc then that is a sign that something is wrong. As product managers, we like to build and create. If the product requirement definition process is interfering with that enjoyment then it needs to be overhauled or even eliminated. I would rather work with happy product managers than have beautiful documentation or effective consensus processes (but please don’t make me choose). Do not be resigned to a bad product requirement definition experience, step up and fix it!

In case you made it this far and still haven’t made a copy of my template here it is again, enjoy!