# Writing a Customer Feedback-Fueled Product Requirements Document  ## Metadata - Author: [[uservoice.com]] - Full Title: Writing a Customer Feedback-Fueled Product Requirements Document - Category: #articles - Document Note: **PRD in 4 sections:** 1. Purpose – Who and Why 2. Features – Consider user's feedback 3. Release criteria – Functionality, Usability, Reliability, Performance and Supportability 4. Schedule – Coordination to release or retire features - Summary: You can find concise product requirement documents these days, even in lean startups, but they are always customer-driven. We break down how to write one. - URL: https://uservoice.com/blog/product-requirements-document ## Highlights -  Waterfall. Agile. Scrum. In all product teams, people will debate the best format or usefulness of Product Requirements Documents (known as PRDs). As a Product Manager in agile scrum and continuous deployment environments, I have seen the essence of PRDs in different forms and names, but the basic end goal of them has stayed the same:PRDs are used to communicate to engineers, designers, and ourselves what is going to be built, but not exactly how it should be built. > “Bad Product Managers…want light and ask for a candle when their engineers could have built a light bulb."-Ben Horowitz, [Good Product Manager. Bad Product Manager.](http://www.khoslaventures.com/wp-content/uploads/Good_Product_Manager_Bad_Product_Manager_KV.pdf) Traditionally, the how is written up after the PRD as a technical/functional specification document, but in many teams, it is just worked out informally by the engineers, often with some back-and-forth with the PM (Remember: [Software is a team sport](https://community.uservoice.com/blog/technical-skills-every-product-manager-should-know/). Avoid unnecessarily stepping on engineers’ toes as a Product Manager). Size Doesn’t Matter: Customer Value Does  Whether you end up writing a full-on traditional 60-page PRD or a product spec ticket that looks more like a 140-character tweet, you still run the risk of scope creep and a bloated process. Short does not mean lean. Long documents might lead you to think “Might as well throw in just one more feature”, but short specs might make you say “let’s build whatever is quickest” instead of building what is most valuable to the user.There are 3 things you need to understand to combat bloat and build a customer-driven PRD: 1. **You cannot start writing an effective PRD until you validate the value to users with customer feedback methods.** 2. **You cannot maintain a living PRD that is useful to the team unless each feature decision is prioritized and backed up with customer data, experimentation, or testable reasoning.** 3. **You cannot test the completeness of PRD-driven development without customer feedback and analytics thought through from the beginning of the process.** You can find concise PRDs these days, even in lean startups, but they are always customer-driven. Take a look at [Product Hunt’s stripped-down PRD](https://docs.google.com/document/d/1yrU5F6Gxhkfma91wf_IbZfexw8_fahbGQLW3EvwdfQI/edit?usp=sharing). Only 7 pages of notes for their entire product. While it may not be a "formal" PRD, it does the trick - which is exactly what you need.The Product Hunt team begins with a clear goal for the user, describes who it’s for, gives customer validation data to back it up, and provides UX mockups for design direction. We will dig into PH’s their informal PRD a bit more, but it is clear they did a lot of work before they began writing it. Before You Begin Writing the Product Requirements Document Customer feedback is not a one-and-done process. There are several stages of collecting feedback, like laying brick for a house. After each row of bricks, you need to add the binding and check the level.Let’s look at 3 feedback methods to use before you begin writing a PRD: 1. Talk to your users  As a Product Manager, if you are not talking to users, you are not doing a good job. You can talk on customer forums, directly in your product, or (preferably) in person. Of course, the anecdotes of 4 or 5 users are not a statistically significant sample, but you will see patterns and can quickly highlight some obvious flaws. What this does is provide you with a list of hypotheses (testable assumptions about the value of your product), not a list of features. 2. Determine if you need each feature by measuring potential Revenue, Customer Satisfaction, ROI, & Customer Impact Before writing a PRD or building anything, prioritize your features and validate your ideas against user-generated ideas (from forums, focus groups, etc.) in order to build a business case beyond your assumptions or simple user votes. (Hint hint - here’s one [product management tool](https://www.uservoice.com/product/product-management/) that can help you prioritize customer feedback). 3. Show customers your prototype  The best way to determine what to build without wasting engineering resources or accumulating technical debt is to test a prototype of your product features with your customers. The support costs of adding new features you don’t need are dwarfed by the costs of removing that feature later on ([People don’t like change](https://community.uservoice.com/blog/how-to-communicate-product-changes-to-your-users/)). Remember, prototyping is one of the 5 key [technical skills of a product manager](https://community.uservoice.com/blog/technical-skills-every-product-manager-should-know/).Make your prototypes to the minimum testable version that gets the customer’s job done. That way, you can identify what it is about the product that would or wouldn’t work. Customer Feedback In Each Part of the PRD In his article [“How to Write A Good PRD”](http://www.svpg.com/assets/Files/goodprd.pdf), ex-Ebay and Netscape VP of Product Marty Cagan [broke the PRD down](http://www.svpg.com/assets/Files/goodprd.pdf) into 4 very broad sections. We will look at how Customer Feedback can be incorporated into each section: **1. Product Purpose** In this section, you will define the user needs, the user tasks to fill those needs, and the business case. Feedback is no more important than when communicating the case for building a product. Identify all of the feedback you collected before writing the PRD and add it here. If there are gaps in your business case, you need to go back and collect support quickly. Atlassian even recommends a [PRD 1-page dashboard](https://www.atlassian.com/agile/requirements) to keep up-to-date for all teams. For the Product Purpose, they recommend linking the user need to User Stories and actual Customer Interview notes. There is an opportunity to add snippets from [user testing videos](http://www.usertesting.com) and other customer feedback or user behavior reports. If you are lucky, you have already implemented a [customer feedback tool](https://www.uservoice.com/product/product-management/) to provide this support. This will help your designers and engineers make implementation decisions with more user context. This will also help marketing, sales and customer success teams understand and explain to customers the reasoning for feature decisions later on, if they need to dig in.  **2. Features** What is being built to help users accomplish tasks and meet their needs?Mockups and Prototypes are the best fidelity versions to put in here. If this is pre-design, it will be a living part of the document that you can continue testing. In this section, you will define the user needs, the user tasks to fill those needs, and the business case. Prioritizing features and discovering edge cases to communicate to design and engineering will require user feedback data. You will want your design and engineering teams to spend the most effort on the most valuable features and use cases of the product. If an engineer spends 4 hours optimizing load time on a page, but does not know that the most important factor is a sleek design and highly-customized experience, they may sacrifice what matters most to the user. The best way to communicate this is through prioritizing features.Hopefully, you have already collected customer feedback data before writing your PRD, bu ([View Highlight](https://read.readwise.io/read/01gs61vxpp5apfgpvek4w9etra)) - There are 3 things you need to understand to combat bloat and build a customer-driven PRD: 1. **You cannot start writing an effective PRD until you validate the value to users with customer feedback methods.** 2. **You cannot maintain a living PRD that is useful to the team unless each feature decision is prioritized and backed up with customer data, experimentation, or testable reasoning.** 3. **You cannot test the completeness of PRD-driven development without customer feedback and analytics thought through from the beginning of the process.** ([View Highlight](https://read.readwise.io/read/01gs61xa1v49k0p3ge7wev4x6t)) - **1. Product Purpose** Who is this for? Why are we building it? In this section, you will define the user needs, the user tasks to fill those needs, and the business case. Provide Context Using Customer Feedback Feedback is no more important than when communicating the case for building a product. Identify all of the feedback you collected before writing the PRD and add it here. ([View Highlight](https://read.readwise.io/read/01gs6272vwfdhgb1py4ra4r3y0)) - **2. Features** What is being built to help users accomplish tasks and meet their needs?Mockups and Prototypes are the best fidelity versions to put in here. If this is pre-design, it will be a living part of the document that you can continue testing. In this section, you will define the user needs, the user tasks to fill those needs, and the business case. Prioritizing features and discovering edge cases to communicate to design and engineering will require user feedback data. Only Build What Is Valuable Using Customer Feedback You will want your design and engineering teams to spend the most effort on the most valuable features and use cases of the product. ([View Highlight](https://read.readwise.io/read/01gs62bchgcvsb92c8w1yb839n)) - **3. Release Criteria** User testing, user stories, and usability tests can be included with acceptance tests to ensure each feature is ready for release. A good product manager will provide the engineers with the direction needed to ensure they have built something the user values and can actually use in practice. ([View Highlight](https://read.readwise.io/read/01gs62byap6xkvxeqpq4aftk27)) - To determine what functionality is required and what additional testing you will need, [Jerry Cao at UXPin](https://studio.uxpin.com/blog/write-good-product-requirements-document/) outlines several criteria question areas to consider in his article on PRDs: • Functionality: “What are the absolute mandatory functions and features that need to be met? Does the customer require a specific set of legacy features that have to be maintained? Is there a security component that is mandatory?” • Usability: “Does the feature meet the user’s expectations aesthetically and is it intuitive to use? What forms of user tests, interviews, and “[dogfooding](http://www.forbes.com/sites/michaeldefranco/2014/03/04/not-eating-your-own-dog-food-you-probably-should-be-2/#46f5425c51d6)” are required to ensure this is met? How fast should a user take to complete a task or user story? You need to ensure the team is thinking about usability when they are developing.” • Reliability: “What’s the maximum acceptable failure rate? Are these failures predictable? Can the system recover from these failures?” • Performance: “How fast must it be? What is the maximum response time, throughput, and memory consumption?” • Supportability: “Is it testable, serviceable, installable, and configurable?” You can only find the answer to these questions through customer feedback. ([View Highlight](https://read.readwise.io/read/01gs62cde2j7dkmkxdv8ys8ebn)) - 4. Schedule  A reasoning for a timeframe. Reasoning is better than just specific dates. Understanding the user or [customer’s needs](https://community.uservoice.com/blog/how-to-communicate-product-changes-to-your-users/) for timing of release, the strategy of coordinating different feature releases and retirements, as well as estimation with engineering will improve this section. It should be readdressed often to ensure it is either tracking or should be changed.Timing is strategically important, and can be a key to your product’s success or failure. ([View Highlight](https://read.readwise.io/read/01gs62ecye3011n1t8xvs07bft)) - 4. Schedule  A reasoning for a timeframe. Reasoning is better than just specific dates. Understanding the user or [customer’s needs](https://community.uservoice.com/blog/how-to-communicate-product-changes-to-your-users/) for timing of release, the strategy of coordinating different feature releases and retirements, as well as estimation with engineering will improve this section. It should be readdressed often to ensure it is either tracking or should be changed.Timing is strategically important, and can be a key to your product’s success or failure. ([View Highlight](https://read.readwise.io/read/01gs62etdvpfk2d6wchm3t62eg))