Product managers create product requirements documents, right? Despite this long-standing relationship, some people question whether the PRD remains relevant in fast moving, agile development organizations. They suggest that a PRD can become static, rigid, and confining, preferring other forms of communication between product management and engineering.

The PRD holds product management, engineering, marketing, sales, and peers accountable for the agreed plan of record. It enables broad product planning using a common reference point. If it’s not written down, it doesn’t exist.

Like other communication media, a PRD can yield great outcomes or be abused and neglected to irrelevancy. The product manager must formally communicate what product success looks like to a cross-functional organization. Formal communication should be written and subject to broad review and debate. Committing ideas in writing is a critical, formative process that forces her to confront ambiguities and resolve disconnected logic, fostering constructive debate on the product goals and strategy – exactly the rigor expected of product managers.

Informal cormmunication – hallway conversations, ad-hoc email threads, chat logs, backlogs – means most people aren’t quite sure of the bigger vision of success. Even in small teams, informal communication poses high risk of misunderstanding context between business requirements and use cases after achieving a fleeting consensus. New arrivals face difficulty coming up to speed. Not everyone will have access to all the informal communication channels. Those who do are left to piece together history, never sure if something is being missed.

Everyone in the organization should be able to inspect and consider the vision of product success on their own time and at their own pace. Informal communication works against this transparency.

Many people misunderstand the purpose of a PRD to be mainly a prioritized requirements list. Rather, business goals and use cases are the fundamental goal posts that define a new product or release. Documented requirements are an important element, but provide insufficient context on their own to ensure a winning product.

Why are we building this?

Business goals set the context into which the product fits, allowing everyone in the organization to understand why they are building it, who they are building it for, and what systems it replaces or complements. The organization must understand the product’s unique value – why the market should care.

• The why identifies the market being served and the potential for monetization (or the appropriate business metric). It lays out the essential problem being solved and introduces the foundational use cases that demonstrate product-market fit.

• Documenting target users is necessary to ensure a serviceable audience, understand their needs, and determine appropriate degrees of user interaction. Identifying product buyers and influencers helps ensure that messaging and use cases are complete.

• Market alternatives and competitors must be clear to everyone. The product manager must honestly assess competitors’ strengths and weaknesses, ensuring that real value is being delivered to users versus simply another way of operating.

What will people use it for?

A product’s user interaction and interface design rely heavily on the PRD to detail the product’s defining use cases. These use cases illustrate core product value and the most common ways the product will be used.

• Engineering can put features in context and make informed design decisions with clear, focused use cases. Asking “do we need to build ‘X’?” often indicates an incomplete understanding of use cases between engineering and product management.

• Marketing and sales are best positioned to succinctly articulate and demonstrate product value by understanding foundational use cases. Rather than delivering a me-too pitch, they can communicate with users’ familiar language and experiences.

Most products benefit enormously by interoperating within a technology ecosystem. Inability to work with necessary third-party products can make it nearly impossible for users to consume your product’s benefits. The PRD must be clear on other systems in the user’s world the product must operate with and the full set of interactions required to address user needs.

Informal won’t work

Business goals and use cases are too fundamental to product success for informal communication and must be written down for broad review and debate. While a PRD may fail to deliver these prerequisites for success, the solution lies in the product manager improving her work versus believing that relaxing the need for formal, written communication will somehow lead to success.