The Product Requirements Document (PRD) has long been a topic of debate among the product management community. For those who are not familiar with the term PRD, you might know it by another name, such as a MRD (Market Requirements Document), or a specification document. In either case, the goal is to write down the required information for a team to build the best solution for the target customer.   Since the requirement of a PRD is seemingly straightforward, one might wonder what the debate is all about.

There are two popular approaches towards tackling a PRD.  The Uservoice blog, outlines them well in their post; Is the Product Requirements Document Dead? A Debate. The first approach, the more agile approach, tends to say there is no need for a PRD in an agile environment and in some cases might even suggest that product requirements documents must die. Both articles refer to the the agile manifesto principle of “ working software-  over comprehensive documentation”.  The second approach supports a lengthy waterfall process PRD where the product manager, or traditionally the system analyst, collects all of the requirements into a very long word/pdf document.The reality is usually somewhere in between the two approaches.

I argue that the PRD level of fidelity depends on the level of certainty in which the product manager works. In a fast paced startup environment, there is no need for a 10 page PRD.  The main focus is about rapid prototyping on the way to the product-market fit.  

An example can be seen in the backup application for financial institutions.  For this type of product, the certainty levels are high so there is no real need for rapid prototyping.  However, the functional requirements and the non functional requirements should be agreed upon in advance as there is a rigorous process of quality assurance (no room for mistakes here) before moving to production.  

To help product managers of all kinds, from new to experienced and from startup geeks to enterprises suites, I have collected some best practices for writing down your PRD. I didn’t cover the aspect of breaking down the requirements into epics and user stories. I will cover that in the next video: Link to the the PRD Template