What is a PRD?

A Product Requirements Document (PRD) is the most commonly used mechanism for product managers to describe product requirements for a pending or future release. PRDs often form the basis of requirements for Waterfall software development processes though have been used in more AGILE environments. A PRD is often created AFTER a Marketing Requirements Document (MRD) has been written/ approved by management, and is usually written BEFORE a technical requirements document. It is designed to allow people within a company to understand what a product should do and how it should work. PRDs are most frequently written for software products, but in principle, can be used for any type of product.

Typical components of a software product requirements document (PRD) are:

• Title, Author, Purpose and Scope (technical and business perspectives)
• List of Key Stakeholders, Market Assessment and Target Demographics
• Product Overview and Use Cases
• Requirements, including functional requirements (e.g. what a product should do)
• Usability / Technical / Environmental / Support / Interaction Requirements
• Constraints
• High level workflow plans, timelines and milestones
• Evaluation plan and performance metrics (what does success look like)

A PRD defines the problem / opportunity that the product (or product feature) is looking to address or solve HOWEVER should avoid defining the technical solution to those problems. This distinction allows development engineers / technologists to provide the optimal solution to the requirements defined in the PRD. A PRD sometimes serves as a marketing requirements document as well, particularly if the product is small or uncomplicated.

Though some teams still work this way – being reliant on the production and dissemination of PRDs - many now write product requirements in the form of user stories. Written correctly, user stories tell the engineers exactly what new functionality is needed and also, the context of why you are building what you are building – the benefits. User stories don’t just communicate to engineers what they should build, they communicate why. A distinct advantage of user stories over PRDs. Many people write bad user stories, where they forget to clearly define the actor or leave the benefit off altogether.

In short; write good user stories, clearly specify the actor, and pay special attention to the benefit.

However, back to PRDs …

• They take a considerable amount time to write. You may want to engage with the development teams in the meantime so that they aren’t left twiddling their thumbs, anxiously.
• Declaration and Definition of the User Experience within a PRD may be lacking.
• PRDs are static documents however, development is a dynamic process.
• What you wanted may not be what you get; ‘flat’ requirements are subject to interpretations.
• Development cycles can be wasted with PRDs; ‘ping pong’ between engineering and product management.
• Mills & Boon. It may be too long to read / digest (properly).
• Management Apathy. While they may have a document to see, they don’t have anything to have / see / hold.
• Not easily validated (as opposed to the test & learn approach)

On a positive note, PRDs are very useful when you have an exact set of requirements and can clearly / very clearly articulate 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. AND, the experiences that I’ve had over recent years.

CV140

More Interview Questions