3 C’s of an Effective PRD - Concise, Collaborative & Customer Oriented

Producing a high quality product requirements document (PRD) is one of the most critical responsibilities of a product managers job. Once a market opportunity has been identified and the business plan has been created, then comes a PM’s toughest challenge - getting several teams across the company excited and ready to execute. PRD’s are the main tool at a PM’s disposal to achieve this goal. Even though PRD’s themselves are often thought of as a relic of the waterfall product development process and antithetical to agile development (good read on this topic), PM’s need a way to channel and respond to questions from various stakeholders during the design & development while reinforcing the overall product goals. At its core it is a guiding document that fosters a common understanding of what is being built and why, not an artifact of a specific product development process. The importance of a PRD to a PM has not changed since the time Ben Horowitz & David Weiden first wrote about it, but its structure, content and purpose have definitely evolved.  

Structuring an effective PRD is challenging because it is often looked upon as a crystal ball by your stakeholders. It’s easy to fall into the trap of trying to answer every possible question. Crafting a document that can capture the needs of various stakeholders, be consumed by multiple audiences and not become a tome is a complex task. With increasing asynchronous communication in today’s distributed teams the content and structure of PRD’s take on even more importance. Over the last 10 years I have written PRD’s in various formats and after numerous tune-ups have gradually settled on a template that balances the breadth of the audience with the depth of the requirements.    

Guiding Principles for Your PRD

• Concise - Minimize alternate interpretations of PRD. Creating a PRD structure that fits the needs of your company is possibly one the hardest things for a PM. Similar to your roadmap, generating early buy-in from your audience is critical. Your internal stakeholders (Engineers, CS, Sales, Marketing) should all be able to look at the PRD through their own lens and be clear about its overall impact on the company’s objectives. 
• Collaborative - No Pride of Authorship. Even though PM’s are primarily responsible for writing a PRD, cross functional input is critical for a complete PRD. Instead of thinking of yourself as a content creator, you should see yourself as a curator of several opinions (users, competitive landscape, internal stakeholders) who is applying a consistent winnowing framework to eventually generate the PRD. You should be its loudest champion, but shouldn’t come at the expense of alignment. 
• Customer Oriented - Biggest focus is on the value of solving the PROBLEM. A PRD is your steering document as you navigate uncertainties bound to arise during solution development. Staying focused on the challenges user’s are facing and benefits of solving the problem will prevent the PRD from turning into a detailed description of the solution. A PRD should help you navigate the unknown and stay focused on the problem so that you don’t commit to a specific approach without evaluating alternatives. 

Creating a Compelling PRD

A compelling PRD needs to strike the right balance between the appropriate level of detail and still being the go-to resource for the entire company. Too detailed and it risks becoming overly prescriptive; not enough details and it risks spawning multiple follow on meetings and mis-alignment between the stakeholders. Even enterprise/B2B products need to move fast with enough direction to start making progress and getting feedback as soon as possible.

After testing several versions over many iterations I have found that a 3-5 page PRD with the following sections can help teams move fast while keeping stakeholders aligned.  

• Initiative details. It is important to establish the PRD is a collaborative document with responsibility and accountability covered by cross-functional stakeholders. This section should list out the key stakeholders, current status of the work (draft/in development/released) and anticipated feature release date. 
• Feature Goal(s). Describe “what” you are trying to achieve. Are you trying to drive adoption in a new vertical, increase engagement with a new user flow, converting non-paying users to paying etc. (good reads here & here). Anyone from the company should be able to understand the goals, and more importantly how it aligns with your company’s overall goals. 
• Strategic Fit - Describe “why” this feature is something worth pursuing. It should be a concise and jargon-free explanation of target user challenges, pain points that need to be solved, and why your company should pursue this market opportunity.
• Product Metrics - This section should align tightly with the Feature Goals section. Essentially it should describe how you are going to show progress towards your goals using a standard set of metrics around activation, adoption, retention or conversion. Here’s an excellent blog on this topic.
• Product Requirements - These are stated as user stories clearly describing the user workflow and problem (not the solution).You should also prioritize these based on inputs from customer and internal stakeholder discussions. Read this Atlassian article on crafting user stories.
• User Flows & Design - This section should describe how the new feature will fit with existing features and the expected UI flows as users navigate the product. If applicable visual mockups related to the feature should be added. In the beginning avoid creating hi-fidelity wireframes - instead go with fat marker sketches that help readers visualize at a high level but adding pixel and position details is difficult. See this excellent read on Breadboarding and Fat Marker Sketches.
• Technical Requirements - Use this as a placeholder to link to the full technical requirements document. 
• Launch Plan - Launching a feature is an intricate and detailed process, with many cross-functional stakeholders involved. This section should provide visibility on sequence of events for a successful rollout and ownership over different parts of the launch. Use this section as an alignment tool between stakeholders and to ensure it reflects priorities on your roadmap.  
• Assumptions & Out of Scope Items - Defining the boundaries you don’t want to cross is critical as you are developing the PRD. Clearly stating these early on can avoid going down rabbit holes. 

Traps to Avoid

• Resist the urge to write detailed user stories and requirements before stakeholders are consulted. 
• Introducing stage gates that require sign-offs to proceed is a symptom of stakeholders not feeling involved. Don’t solve alignment challenges with stage gates; instead get buy in early on in the development process. 
• Designers haven’t spoken to the end user till late in the process, and/or don’t have a firm grasp on the user workflow.
• Presenting an almost-finalized PRD for the first time to multiple stakeholders. 

As you proceed with fine tuning your PRD process remember that there is no one size fits all when it comes to writing PRD’s. Use concision, collaboration and customer oriented as your guiding principles as you formulate a PRD that is a good fit for the needs of your projects and teams. Feel free to download this template and modify it to suit your needs. Please do reach out if you have feedback!