How to build a solid product backlog of ideas and problems
Collect, consolidate and classify product feedback from different sources
Before we begin prioritizing what to build, its crucial to know what all options we have. Unless you have a system in place for capturing and classifying feedback, you will likely miss out on important customer requests.
Having a solid product backlog has the following benefits:
- Helps to understand the pain points and expectations of customers, prospects and senior management.
- Helps to have an informed debate on what are your trade-offs while prioritizing features.
- Helps understand the frequency of specific feature requests.
Thus, a well maintained and frequently updated product backlog is a necessary pre-requisite for feature prioritization.
In this article, I will take you through the three step approach towards maintaining a solid product backlog — collect, consolidate and classify.
1. Collecting Feedback
As a product manager, you will notice ideas and feature requests flying in from all directions. Keeping track of all these is the first step towards acting on them.
Sources of Product Feedback
Here are some ways in which we receive feedback as a B2B company.
- Feedback from prospects (potential customers) — We have a slack channel called #product-feedback where the sales team posts feedback around feature requests after their sales conversations.
- Feedback from existing customers through NPS surveys, in-app feedback, dedicated customer interviews, conversations with account management team etc — This feedback usually comes via emails. (It can easily be automated to land in a dedicated slack channel)
- Product reviews posted on software review websites such as g2, TrustRadius — The reviews posted here automatically land in a separate slack channel that is accessible to all employees in the company.
- Support Tickets — Feedback from customers who faced issues with our product and reached out to the support team for query resolution.
- Feedback from the internal team — Team members may face problems while using the product or may get ideas on improving the product. We encourage everyone in the team to post their feedback on the #product feedback channel on slack.
Depending on your use case and the company’s maturity, you might be getting feedback from fewer or more sources.
The important thing is to make sure that feedback is not lost in conversations or private notes. All feedback should be collected in an easily accessible place from where it can be read, understood and acted upon.
2. Consolidating Feedback
Once systems and processes have been set up to collect feedback from various touch points, its time to start consolidating it.
Consolidating feedback at a single place has multiple benefits:
- Makes it easy for cross-functional stakeholders to know the quantity of the feedback that’s coming. (Otherwise everyone feels that theirs is the only request that needs to be prioritized)
- Helps the product managers classify the feedback specific to their product area and subsequently prioritize the most important items.
How we achieved the consolidation of this feedback?
Most of our product feedback was landing in a slack channel or in email. Using Zapier, all the feedback was funneled to a google spreadsheet. This Google spreadsheet became the single source for viewing all the feedback received by the organization across all possible feedback channels.
Automating the consolidation process made the entire process highly scalable and efficient for us. However, if you are receiving less feedback, the consolidation of all the feedback at a single place can be done manually as well.
3. Classifying Feedback
The process of generating insights from the consolidated feedback requires proper labelling of the feedback. Using this labelling, feedback can be classified as per your needs.
Benefits of Feedback Classification
- Helps the senior leadership make informed decisions around product areas to invest in, new teams to build etc. (For eg. sustained feedback around mobile apps helped push more investment towards building our mobile development team).
- Generates numbers on the frequency of particular feature requests— this helps build a stronger case for prioritizing a particular request.
- Identify the popular themes around which feedback requests are coming.
- Segment Feedback based on customer segment, customer’s pricing plan etc — Based on our product strategy, we can choose to prioritize feedback from certain segments.
Details to specify while classifying the feedback
- The source from where the feedback is coming — This can help differentiate the must-haves vs good-to-haves (For eg. problem reported on a support ticket is much more urgent to resolve than a comment from an internal team member)
- The customer who is sharing this feedback (for every feedback you would have the customer’s email ID. Using this, you can identify the customer type, pricing plan, geography and other customer specific details associated with each piece of feedback)
- The type of the feedback — bug, feature request, pricing issue, product education issue etc.
- The “Product area” — For eg. feedback on desktop app vs pricing vs mobile app vs platform will fall under different product areas. (Generally, different product areas are owned by different product managers. Thus, adding this label also helps product managers focus on their specific areas)
- Whether the given feature request is a sales blocker or not — this helps understand if building the feature bring us new customers or if its going to improve experience of existing customers.
Depending on your use case and company size, you can add or remove classification details associated with each feedback .
Is the above classification happening automatically or manually
Entering certain details such as source of feedback, customer details can be automated through code. Further, depending on the engineering involvement, you can also automate feedback type and product area through text analysis of the feedback received. (In our case, specifying feedback type and product area was a manual effort)
Word of caution: For the manual portion of the classification exercise, all PMs should spend atleast 50–90 minutes per week to classify the data being received. Otherwise, the data will become so huge that nobody will try classifying it.
You may also explore smart feedback management tools that could help you automate the entire consolidation and classification process with minimal manual intervention.
With the above details entered, you now have a solid product backlog ready to analyze and act upon.
Now its time for the final piece of the puzzle — Prioritizing the requests from the backlog. This is a topic which I will touch upon in the last article of this series on feature prioritization.
Conclusion
Maintaining a backlog of ideas and product problems is a very high leverage activity for any product team.
Setting up and maintaining your product backlog has three key steps:
- Collect — Setting up the feedback collection from different sources
- Consolidate — Funneling all the collected feedback into a single place
- Classify — Grouping product feedback into different categories
While there is initial effort involved in maintaining this system, once you have things set up, the subsequent maintenance is quite easy. You don’t need more than 1–2 hours of effort each week to keep things in order.
So, what are you waiting for!
If you don’t have a product backlog that is accessible at the click of a button, its time to start building one now!
This is the second article in the 3 part series on prioritizing features and building a product roadmap. Part 1 of this series talks about the challenges involved in using frameworks and things to keep in mind while prioritising[read here]. In the final article, I will discuss how to craft a solid product roadmap based on this carefully collated product backlog.
