What’s wrong with the Product Requirement Documents (PRDs)?

PRD is the most commonly used mechanism for product managers to describe product requirements for a release. PRDs forms the basis of requirements for both Waterfall and now even with Agile software development processes. However, there are some fundamental challenges with the PRD model and I’m sure if you take a step back and analyze the pros and cons of the PRDs...you will find commonality between your thoughts and what I have shared below.  Not sure who invented PRDs but I’m sure this person/organization didn’t have just the word document as the fundamental way to define products.  So, lets start with the challenges first :

Take Time to Write

Product Managers spend considerable amount time on the document.  During this time your product teams are in waiting mode and management is anxious to figure out what’s next. So, cycles are wasted and engineering management cannot plan for what’s next from a staffing, budget , platform perspectives until this document is firmed up.

User Experience is an after thought

This is the biggest challenge with the PRD. They are a bulleted list of requirements ...very verbose but cannot describe the user experience. User experience is the most important element of a requirement...experience does not only imply the UI. It's every touch point the user has with the product. 

Static in nature

PRDs are static documents. However, development is a dynamic process...in fact, agile development is used today to help give structure to this dynamic nature of software development. On the other hand , the most crucial document that is used for software development is static.
 

Error prone scoping Analysis

Engineer cannot actually provide the scope of the work until he really understands the requirements, gets a chance of putting a high level prototype or design document . However, we hardly give this "must needed"  time and force the engineering team to come up with the estimates to help identify the next spot on the roadmap . Thus, what you get usually are high level estimates with a significant error margin in them and off course very conservative.  PMs are still not done.  Then, the next round of discussions start around the negotiations. Give and Take...

What you ask for is not what you get ?

We all have lived through this. What is specified in the word form in the document is different then what you get? Why is this? Because requirements are subject to interpretations ...PRDs cannot capture the entire context of the requirement.

Cycles after cycles are wasted

The ping pong game between engineering and product management on requirements is a waste of time and crucial product release cycles are wasted. It causes frustration, results in lack of trust, results in throw away work. PRDs usually start with the complete wish list from a PM and ends up with what should have been there from day one prioritized as the right feature set for the release. This is a significant waste.

Cross functional teams have no clue what’s in the release

Even though PRDs exist but honestly the only teams that read it are usually the engineering staff. As a result, cross functional teams are in dark and they all wait for the final PRD and some kind of a dev milestone to understand what is in this release. So, they are in dark and cannot plan for future deliverables.

Too long to read and it changes...

Hardly a few engineers read the entire PRD which takes time and by the time you read it usually changes . Infact, the change is constant since you are going and forth from a market perspective but also adjusting based on all the discussions.

Management is left in dark

Executive team usually gets a few bullets on a power point to help illustrate what the next release would look like. These bullets form the basis of budget approvals, decisions and pretty much the “Go/No Go” decisions for the project.

Do not describe the requirements but end up describing the solutions

In order to be precise and to make sure what you ask for is what you get product managers end up identifying the solutions to the team instead of the requirements. PRDs suffer from this common problem.

Cannot be validated

There is no way to validate the PRD and the assumptions associated with the requirements. It’s not something you can put in front of the customer ans ask for feedback or lead them to discover new requirements.

This list can go on and on...but I’m sure you will find a connection between your process and these data points . On the positive front...PRDs in its true form are a useful document when you know the exact set of requirements and can clearly / very clearly articulate it and expect little to NO changes to it as you move through the release. Usually, this is true with waterfall development models or shorter releases.  This is hardly the case in the software world we live in these days. 

So, what’s the solution...

Solution lies with the startups and entrepreneurs who have built companies from scratch. This will be a topic for my next blog...but here is the hint. What do startups do differently? What do Entrepreneurs focus on initially when they have limited availability of everything ...money, cycles, resources etc?