Product Requirements Document – What is a PRD?

You’ve come a long way. You know your customers, their problem, and when and why they have it. You’ve documented or communicated this information to your development team, so now it’s time to turn the work over to them. The Product Requirement Document, or in 280 Group’s version, the Product Description Document, defines how the product will address the customer needs identified in the Market Requirements Document.

This image shows you how the “who” and “why” that the Product Manager has documented in the Market Requirements Document become the “what” and “how” that developers are responsible for and define in the Product Requirements Document. Two more important considerations for you to think about:

• The line between Product Management and product development is porous. Your conversations about what your customers need and what product development proposes as a solution is a discussion. During this discussion, you as a team come to the best possible solution. In fact, the discussion is critical to any relationship between Product Management and product development in order to ship great products.
• The “how” part of the product development isn’t the Product Manager’s responsibility. As a Product Manager, it isn’t up to you to be involved with the guts of how a product is actually made. Your development team determines what development tools, programming languages, and processes to use to build the product. You as a Product Manager simply don’t have that expertise (and if you do, it still isn’t your responsibility), just like your engineers don’t have the business background and expertise to create the product strategy or business plan.

Product Description Statements for Your Product Requirements Document

If you’re writing your problem description statements, your voice ceases to be that of the customer and turns into a description of what the product will do.

The traditional format is written as follows for product requirements that must be met:

• Option 1: Product MUST be able to perform [function]
• Option 2: Product MUST provide [function]
• Option 3: Product MUST have [function]

For those product requirements which you would like to have, but may not have time to develop, you can indicate how desirable it is to have this be part of the product. The format is written as follows:

Remember that the market needs (from the Market Requirements Document) and product feature descriptions (from the Product Requirements Document) are intricately linked. As you work to resolve the differences between the two points of view — that of the Product Manager and that of the product development organization — remain flexible.

Outlining the Product Requirements Document

A best practice is to have your product development folks create the Product Requirements Document as a response to your Market Needs/Market Requirements Document. Then you can have a team discussion to determine what is achievable. If that isn’t possible politically, then co-write the document or write short parts of it and have them check out your progress.

Here’s a basic outline of the Product Requirements Document:

• Executive Summary: This rundown includes the product vision, objectives, scope, and risks.
• Product Features: This detailed section defines the following list of product features. In Agile, this section will be at the level you know today. Agile accommodates change later on in the process. Add to the list if needed and delete what isn’t applicable: Release Planning, Functional, Compatibility, Security, Performance, Usability, Operational, Internalization, Documentation, Support, Legal, Regulatory, Compliance, Distribution and Packaging, and Miscellaneous.
• Architectural Vision: What is the structure of the entire development project? What tools and processes will be used to create the entire product?
• High-level Scope: This section outlines the needed resources, tools, dates, and milestones.
• Risk Analysis, Assumptions, Open Issues: As with all documents, provide a risk analysis and note your assumptions and open issues.
• Conclusions and Recommendations: What is your conclusion and recommendation?
• Exhibits and Appendices: Any supporting documents and further details are placed here.

Completing the Product Requirements Document

The product requirements document is where the product itself appears. As you or your development team create the document, use the market requirements document as a constant check to make sure that all needs have been accounted for, even at a high level for those who work with Agile. It isn’t the length of the document, but the quality of the thinking that counts.