Writing a Customer Feedback-Fueled Product Requirements Document

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.

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. 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. 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 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). Remember, prototyping is one of the 5 key technical skills of a product manager.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”, ex-Ebay and Netscape VP of Product Marty Cagan broke the PRD down into 4 very broad sections. We will look at how Customer Feedback can be incorporated into each section:

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. 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 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 and other customer feedback or user behavior reports. If you are lucky, you have already implemented a customer feedback tool 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.

Product Hunt gets right to the point in their informal PRD’s purpose section:

The PH team outlines:

1. What the product will be
2. What the product will NOT be
3. Which early tests validate customer value
4. Who the product is for
5. and Why they should build it

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. 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, but new features will always creep in during the Product Requirements process. In his article on PRDs, Marty Cagan writes, “Remember that the PRD is a living document, and you should track all features in the PRD through product launch.” This means that you will need to use the same forums, customer interviews, user behavior analytics, and prototype usability tests to identify the priority and scope of each new feature.Remember, you can also get drowned out with a flood of anecdotes and feature requests from customers, sales, and customer support, so you need to supplement feedback with behavior data, usability testing, and metrics that show how much a feature might move the needle.

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.To determine what functionality is required and what additional testing you will need, Jerry Cao at UXPin 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” 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.If you want to avoid a flood of customer support tickets for missed functionality or - even worse - insufficient security features, you should focus on this section and ensure your customer has what they want.If you discover new functionality as you talk to customers, add it to your PRD. If you realize some functionality is not needed after all, then remove it. Just be sure to communicate to your team what and why it is being changed.

4. Schedule

A reasoning for a timeframe. Reasoning is better than just specific dates.

Understanding the user or customer’s needs 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.

Kraft Macaroni & Cheese’s Brilliant Release Schedule - Anticipate User Feedback

For a non-tech example, Kraft made a change to the recipe formula for their core Kraft Mac & Cheese product. They knew that if they announced the change before the launch that there would be a huge backlash. They would not be able to tell the quality customer feedback from actual issues with the product.Instead, Kraft quietly tested the changes and released the new formula without telling any consumers or changing the packaging (except the ingredients list). Part of the launch strategy was to monitor Social Media and Customer Support channels for customer complaints. Nothing happened. They then used the lack of response in funny campaign ads.Using customer feedback also means understanding and anticipating the behavior of your customers. You can learn from your customers’ previous responses to product changes, the failure of other product launches (such as Facebook’s News Feed’s backlash), and the simple needs of your users/customers. Do those enterprise clients need these reporting features by Q3? Do your users have a chance to use your e-commerce integration before the Holiday Season? Listen to your customers and find out. Timing matters.

Putting It All Together

In the end, customer feedback can transform your PRD creation into a lean process of building, measuring, and learning. At each step in the planning, writing, updating, and release stages of your PRD process, collecting and leveraging customer feedback will turn an uncertain bet into a smooth launch. You avoid wasting time writing specs that are not tested or used, and avoid building waste in products that put you in a hole that is costly to maintain and worse to dig out of. In the end, you have a better product for your users and an empowered team in any development setting.