What Constitutes a PRD?

A PRD is initiated once the decision to invest in a feature has been made, and it precedes the creation of design documents. Consequently, the rationale for investment has already been established. However, PRDs generally include a background or context section that clarifies the reasons for pursuing the feature.

While a PRD does not delve deeply into "how" the feature will be implemented, it aims to address questions that may facilitate the design process, which is elaborated upon in subsequent design documents.

The core components of a PRD include:

• Problem Statement: Identifies the target customer and the specific use cases the feature addresses.
• Solution: Illustrates the anticipated user journey and clearly defines the requirements and execution timeline, forming the basis for design documents.
• Metrics: Outlines the criteria for success and how these will be measured.

What a PRD Is Not

• User-Facing Document: This is an internal document meant to foster a shared understanding of the product's functionality. It doesn't need to be overly polished, as long as the stakeholders find it clear.
• Business Proposal: A PRD isn't the appropriate space for making a business case; this typically belongs in roadmap planning or leadership presentations.
• Design Document: While requirements are critical, a PRD serves as a starting point for design discussions that the engineering team will subsequently address.

Tips for Writing PRDs

1. Guiding Principles

   Effective communication can be approached in two ways: breadth-first, where information is presented at a high level and then elaborated, or depth-first, which focuses on a single aspect in detail before moving on. Generally, a breadth-first approach is more effective for conveying information and securing buy-in, making the document easier to digest.

2. Rationale for Feature Development

   A significant aspect of the PRD is demonstrating how the feature will add value for users. This justification heavily influences whether the benefits of the feature outweigh any delays in market release. One useful format for articulating user value is the Critical User Journey (CUJ):

   "As a [role], I want to [feature] so that [goal]."

   For instance, in my work on the Storage Transfer Service at Google, we introduced a connector for on-premises sources. A CUJ for this feature would be: "As a System Admin responsible for migration, I want checksum validation so that I can confirm the copied data matches the original."

3. Consistent Level of Abstraction

   Maintaining a consistent level of detail is essential. Avoid mixing minor implementation specifics with critical information, unless necessary for stakeholders. For example, if detailing API specifications, include all suggested actions; otherwise, focus on behavioral comments.

4. Mitigating Complexity

   Successful product managers do not transfer complexity to the engineering team. Difficult decisions should be made in the PRD, and clarity on design choices can save developers significant time. These decisions might include whether APIs should operate asynchronously or synchronously, or other implementation aspects that could impact user experience.

5. Broad to Narrow Approach

   This principle encourages generating a wide range of ideas before narrowing them down. In writing, it's better to allow creative exploration in the first draft and then critically assess what is necessary for clarity and purpose.

If you're interested in furthering your knowledge in this area, consider checking out the course: A Simple Approach to Product Management Interviews.