Back to Parative
One of the most common mistakes that teams can make when developing a feedback ontology is trying to get too granular and specific in the categorization too quickly.
You can certainly make an organization system that is so nuanced and granular that you have the same number of individual items as organizational units of those items; but that defeats the entire purpose of the organizational system to begin with.
Our suggestion is to always crawl before you walk before you fly; don’t overcomplicate your system by immediately defining as many categories as possible. Instead, work to minimize the number of categories while still being accurate in order to maximize the scalability of the system.
Depending on your industry, company size, product, team structure, etc., your organizational structure will vary wildly, and there is no one-size-fits-all approach.
However, we here at Parative have developed a general organizational structure that has proven itself to be applicable in essentially every case we’ve encountered.
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.
Why this language? Besides avoiding the awkwardness of referring to both one and many items of feedback as “feedback” (arg that pesky plurality), there’s a very real cultural argument for adjusting your internal lexicon.
Unfortunately, “feedback” has a loaded connotation. We tend to trivialize the value of feedback. Feedback is opinion; the stuff we have to deal with. “
Thanks for letting us know” fodder. Customer “needs”, on the other hand, feel different.
Outstanding customer needs can block every major atomic unit in the business – sales opportunities, contract renewals/upsells, product engagement, and customer sentiment. Every team cares about outstanding customer needs. It’s one of the few things we can align our entire company around.
This language shift may seem trivial. It may not be perfectly encompassing. But it will undoubtedly result in a greater level of consideration for the importance of your customers’ perspectives. After all, language is the roadmap of culture.
Now, User Needs can come in all shapes and sizes; they can range in topic from something as simple as helping someone gain access to their account to cataloging a UX friction point that completely interrupts the onboarding experience.
Because of this vast range of possibilities, it’s important to be able to start by classifying the type of need in order to quickly wade through the noise and make sense of what your customers’ needs are related to.
That’s where Need Types come into play.
A Need Type is a simple classification placed on an individual need which signals how it should be handled, what it’s related to, and who should be responsible.
A very common example we’ve seen would be to initially classify a user need into one of five Need Types:
While this is a great starting point, some companies struggling to make these basic Need Types fully accommodate the broad range of needs they receive and need to expand the classification system.
To learn more about expanding your feedback classification system, check out our new guide to the post-collection feedback management process.
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.
Remember, the purpose of this is to make your life easier by making the process scalable, so adjust the model to work for your team’s needs.
