Product Requirements Document (PRD) Playbook

A Product Requirements Document (PRD) is a vital tool used to guide the development of a feature or product. It serves as a comprehensive roadmap for aligning teams on the "Why," "What," "How," "Who," and "When" of a product feature, ensuring everyone has a clear understanding of the goals and tasks ahead.

Structure of a PRD

1. Why – The Business Case
• Clearly define the problem or opportunity this feature addresses.
• Identify the impact it will have on the business or users. Why is it worth the effort?
2. What – Feature Definition
• Define the scope of the feature and what actions need to be taken.
• Provide a clear Definition of Done (DoD) for the feature.
3. How – Technical Approach
• Describe the technical solution and outline the possible approaches, including trade-offs.
• Detail the specific tasks and activities needed to deliver the feature.
4. Who – Team and Resources
• Identify the team members involved and their responsibilities.
• Assign tasks from the "How" section to the appropriate individuals or teams.
5. When – Delivery Timeline
• Provide a timeline for delivery, including hard deadlines if applicable.
• Estimate the effort required and describe any blockers that may impact the timeline.
• Align priorities and share expectations regarding the delivery of the feature.

How to Use the PRD

1. Start with the "Why":
• A business stakeholder typically starts the PRD by defining the "Why"—the core problem or opportunity the feature addresses. This sets the context and justification for the effort.
2. Move to the "What":
• Once the "Why" is clear, the next step is to define the "What"—the feature itself. The scope should be clear enough for engineers to understand but flexible enough to allow input on feasibility and trade-offs.
3. Develop the "How":
• After the "What" is defined, the technical team discusses how the feature will be implemented. This step involves exploring different approaches, considering trade-offs, and planning the tasks involved.
4. Assign the "Who":
• Based on the "How," assign specific tasks to team members. This step ensures accountability and clarity on who is responsible for each aspect of the feature's development.
5. Align on the "When":
• Finally, establish a timeline for the feature's delivery, taking into account internal and external blockers, priorities, and deadlines.

Rules for Using the PRD

• Define the "What" only after understanding the "Why":
• The feature’s purpose must be crystal clear before you can define what will be built.
• Plan the "How" only after the "What" is clear:
• The technical approach depends on a well-defined feature scope.
• Discussing the "How" affects the "Who" and "When":
• The technical decisions made during the "How" phase will determine who is needed and when the feature can be delivered.

PRD Template Overview

Each section of the PRD serves a specific function to ensure clarity and accountability throughout the feature development process.

Why

• Describe the business problem or opportunity being addressed.
• Outline the expected impact of this feature, making it clear why this effort is worth pursuing.

What

• Define the scope of the work for this feature.
• Share the Definition of Done (DoD) so that all parties know what success looks like.

How

• Detail the technical solution required to deliver the feature.
• Provide alternative approaches if applicable and discuss the trade-offs of each.
• List the specific tasks and activities that need to be completed.

Who

• List the team members required to complete the feature.
• Assign specific responsibilities based on the tasks outlined in the "How" section.

When

• Provide a timeline for delivery, considering any deadlines, blockers, and dependencies.
• Align priorities and ensure a shared commitment to the delivery of the feature.

How to Implement the PRD Process

1. Business Stakeholders Define the Why:
• The process begins when a business stakeholder identifies a problem or opportunity and fills in the "Why" section. This drives the motivation behind the feature.
2. Collaborate to Define the What:
• From the "Why," the product team collaborates to define the "What." The goal is to create a clear scope that outlines exactly what will be done to solve the problem.
3. Discuss the How:
• The technical team works together (either asynchronously or in meetings) to discuss how to implement the feature. This conversation should cover technical feasibility, trade-offs, and resource requirements.
4. Assign the Who:
• Once the "How" is clear, specific tasks are assigned to individuals or teams, ensuring ownership and accountability.
5. Agree on the When:
• Finally, the team establishes a timeline for the feature's completion, aligning expectations across all stakeholders.

Best Practices for PRD Usage

• Keep it Collaborative: Involve all relevant stakeholders, including business teams, product teams, and engineers, to ensure a holistic view of the feature.
• Be Clear and Concise: The PRD should be detailed enough to guide development but not overly complex. It should serve as a living document that evolves as the feature is developed.
• Revisit and Adjust: Regularly update the PRD based on feedback, new insights, or changes in priorities.
• Use Data to Inform the PRD: Whenever possible, base decisions in the PRD on data, whether from user feedback, analytics, or market research.

Common PRD Pitfalls to Avoid

• Vague Business Case: If the "Why" is not clear, the entire feature can become misaligned with business goals.
• Overcomplicated Scope: The "What" should be specific enough to guide development but not so rigid that it stifles flexibility or innovation.
• Poor Communication of Trade-offs: The "How" should include open discussions about trade-offs, so the whole team understands the implications of each technical decision.
• Undefined Responsibilities: Ensure the "Who" section is not ambiguous. Every task should have an owner, and each owner should have clear responsibilities.
• Unrealistic Timelines: In the "When" section, make sure timelines are realistic and take into account all known blockers and dependencies.