Although every step of the feedback management process is important, the entire process is blocked if your team is unable to successfully organize your customers’ needs. Without proper organization, it’s impossible to measure beyond anecdotal opinion. Without accurate measurement, prioritization isn’t grounded in a realistic evaluation of the evidence.
Unfortunately, organization is often treated as an afterthought to feedback collection. For example, have you ever taken a customer reported bug or support request for a product enhancement and immediately created a Jira issue? Of course you have; we all have. But by doing so, you skipped from collecting feedback right to prioritizing it, effectively making Jira a holding ground for ideas rather than a place where jobs go to be done. Without organization, the feedback management process simply doesn’t work. So, let’s start by focusing on proper feedback organization.
Organizing Many Items of Feedback
When developing an organizational system, it often helps to start by understanding your most fundamental atomic unit, on which all organizational units are built. When it comes to the feedback management process, this atomic unit is simply an individual piece of feedback. This can be a support ticket submitted by a user, a feature request recorded during a sales call, or a bug reported through your live chat tool. We suggest calling an individual piece of feedback a User Need, or Need for short.
Classifying individual items of feedback into Needs Types and/or Need Classes is pointless if you don’t have a way to understand how these needs all relate to each other at a more actionable level. In short, we need to be able to merge many similar pieces of feedback into one trackable, measurable, and prioritizable item. This is what Topics and Subtopics are for. Sorting associated User Needs into Topics can help your team better identify, track, measure, and prioritize what matters most to your users in a much more scalable manner.
For example, say you have dozens of User Needs related to your products’ CRM integrations. You could start by creating a Topic called “CRM Integration” and associate all your User Needs that are related to CRM integrations to this Topic. Let’s assume that half of these needs are related to your Salesforce integration, and the other half are related to your HubSpot integration. With your Topic “CRM Integration”, you could have two subtopics: “Salesforce Integration” and “HubSpot Integration”.
Within each of those, you could have more granular Subtopics or Sub-subtopics. You could even have Subtopics split out by Need Type, e.g. a Subtopic for “Salesforce Integration Bugs” within “Salesforce Integration”. This system of nested Topics and Subtopics allows you to contextualize the importance of every single one of your users’ needs and is a critical step in being able to accurately measure the impact of those needs in the future.
At this point, we have many individual Needs, classified by Need Type and organized into meaningful Topics and Subtopics. We’re missing one last important concept, i.e. the ability to relate Needs to one another across Topics and Subtopics.
For example, let’s assume that you care deeply about your first day customer experience (as you should). Many different customer needs may be related to this first day customer experience, such as a bug in your account creation flow, UX friction in your onboarding tutorial, or customer questions regarding what they need to do first. Although each of these Needs would likely have different Need Types and be organized into different Topics, we still want to associate them with one another. We call this cross-Topic association a Theme.
Themes are critical in being able to quickly centralize all customer feedback related to specific projects or experiences that your team is considering how to optimize. In this example, you may have a Theme called “First Day Customer Experience” which you tag all relevant individual needs with, regardless of their Types or Topics.
There’s no way for us to prescriptively define the exact number of Need Types, Need Classes, Topics, or Sub-Topics that your team will need in order to be successful. The main goal here is to just understand how you can use these organizational blocks in order to build a simple but scalable system that fits your needs.
Conclusion
It’s important to reiterate here that you should only create the number of organizational units that you need to accurately define your feedback system. The purpose is to make your life easier by making the process scalable, so adjust the model to work for your team’s needs. To learn more best practices for managing your customer feedback, check out our new guide to the post-collection feedback management process.
