How To Set Up a Feedback Management System
Do you have a feedback management system in place?
Gathering feedback is one of the most important aspects of managing a product. After all, we build things that solve problems for others, not for ourselves. To truly understand how to build the best version of your product, you must tap into your customers’ feedback, frustrations, and insights.
There are gathering tools aplenty — and I generally recommend one does not try to silo how feedback is collected.
Whether this is through in-app feedback surveys, social media, or even email, the more channels you can open up, the more willing people will be to reach out to you — and this is exactly the kind of community you want to promote.
But what do you do once you get the feedback? How do you use it to your advantage, and even more, how do you make sure you’re not actually losing bits of information?
This is where creating an efficient feedback management workflow can be a game-changer.
Let’s take a look at how to do this!
TL;DR
- Understand the difference between ‘feedback’ and ‘feature requests’ — only one of them opens you up to conversations.
- Appoint someone in your team to manage feedback.
- Always run discovery! Use feedback to your advantage and find out more about the problem you’re solving.
- Setting up a proper workflow is important — from potential new ideas to closing the feedback loop (included below!)
- Cadence and responsibilities depend on how much feedback you’re getting.
- How do you deal with thousands upon thousands of requests? Expand your system beyond just a single tool.
- Start collecting feedback with in-app surveys-get a Userpilot demo to see how.
Customer feedback vs feature requests
I’ve said this a few times, and it has been wonderfully reiterated by my friend Bernhard Hecker in this blog post — but there is a difference between the words “feedback” and “feature request.”
A piece of feedback can be positive or negative, but you should always take it in as a neutral conversation starter.
Most tools offer the option to leave feedback through an in-app feedback widget, like the Jira example above, that opens a short in-app microsurvey, customized based on what features and parts of the product you were using when you clicked the widget.
Whether someone is praising your product or talking about how frustrated they are with something, use this opportunity to ask more questions.
- What did they like or dislike?
- What problem are they trying to solve?
- What caused them to reach out?
- What is it about the experience that helped them get to their desired outcome or caused frustration?
And my favorite question of all time…. “Why”?
Either way, you will learn something — and that something can help you improve the product, feature, or experience even further.
A feature request is just that — a request. It implies there are two possible outcomes once it is received: “yes” or “no.”
This puts you in a position where:
- You are setting the tone that you are not open to conversations
- You are potentially “prioritizing feedback” — which is never something you should do.
- You are not fully understanding problems, just focusing on features.
Unless you are an agency and quite literally managing requests, what you are actually taking in is feedback. The change in wording will have a great impact on both your team and customers.
Who is responsible for feedback management?
It’s never too soon to say… it depends.
There is no wrong or right person that should manage feedback on your team, and a lot of it might depend on the types of roles and structures that your company has.
- If you’re in a Scrum environment, the PO would generally act as the voice of the customer.
- If you have a product marketing manager, they would be supporting the process.
- If you have neither, it could be someone that’s customer-facing, like customer success or a business analyst.
- Or if you prefer, it could also just be someone else in the product team, like an APM, junior PM, or a product manager.
Working with cross-functional teams
My general recommendation is to have someone that is customer-facing, like a PMM or someone in your customer success or support teams.
This could bring some potential benefits, like:
- They get involved in the product process and can help liaise with the rest of your customer-facing teams.
- They get to understand the backlog a bit better, and will encourage them to focus less on asking “when” things will be done, as they understand “how” things get done and why.
- Promotes better cross-functional relationships between product and customer-facing teams.
You can also split up the responsibility and have the customer-facing team member triage up to a point, and then the product team takes over. This takes some of the load off of the product team, while still involving them in the process.
What does a good process look like?
Let me start off by saying good is always relative — and the important thing here is that you’re open to continuously improve your workflows.
With that in mind, the baseline for “good” revolves around one key point:
Make sure you are always seeking to understand problems
User feedback is there to help support a problem statement, provide you with information as to what the value might be, and how you might potentially fix the issue.
Feedback is not there to be prioritized, nor does it help to “validate” a solution.
Remember, feedback is there as guidance, not as validation. Customers are often really good at telling you what they want, not why they want it.
This is where you employ tactics like The 5 Why’s Method.
Toyota’s famous “5 why’s” example illustrates why (lol) really well.
Feedback from the customer: The robot stopped due to an overload in the system, please provide us with a new circuit supplier.
Without asking why you’d literally use this to validate change suppliers because clearly there’s an issue with them.
Or is there…? Here’s what happens after asking why five times:
- Why did the robot stop? The circuit overloaded, making a fuse blow.
- Why? There was insufficient lubrication on the bearings, so they locked up.
- Why? The oil pump on the robot wasn’t circulating enough oil.
- Why? The pump intake was clogged with metal shavings.
- Why? There was no filter on the pump.
As you can see, the problem wasn’t what the customer was describing, that was just a symptom of the overall problem.
Running proper discovery, asking questions, and taking the time to do research is part of your feedback management process — and it begins with ensuring feedback is linked to an actual problem to solve, and not treated as its own independent request.
Setting up your feedback management system workflow
Now that we’ve gone over some of the basics, it’s time to set up your workflows.
This is how I like to set up mine:
Feedback status: New
- Newly submitted, has not been addressed yet.
- Responsibility: PO, PMM, CS
Feedback status: Open
This is where you have the opportunity to understand what the customer is asking further and liaise with your team.
Additionally, I always tag items with the affected product areas, so if you don’t currently have a problem, you can find the item(s) later and create a new problem/idea later.
- Responsibility: PO, PMM, CS
Feedback status: Processed
This indicates the item has been linked to a problem, or it has been looked at by the product team and marked as invalid for whatever reason. (Eg. does not fit the vision of the product, you know it’s something you will never do, or it is a bug and should be reported as such.
- Responsibility: PO, PMM, PM (This is where the cross-over happens, and the product team can now start looking at items more closely.)
Feedback status: Contact Customers
At any given point in time, you will need to get back to customers, whether it is to run discovery or to close the customer feedback loop.
I generally use this particular status to do the latter, but be clear with how you’re managing this and what the expectation is when you contact them.
It’s always good to have a few handy templates for this, so it’s an easy-to-follow and repeatable process.
Feedback status: Done
The last status just helps reiterate that all additional steps have been completed.
Like any workflow process, you are free to archive an item at any point in time, but the ‘done’ status helps highlight that it has gone through the necessary workflows and is no longer needed as part of your active feedback backlog.
This can be easily set up in a tool like Airfocus, Trello, or Notion, which allows you to define what your workflow looks like.
The most important part though is to always have feedback data connected to your product backlog. Keeping them separate is often a mistake, and any solid product tool will allow you to manage both.
Analyze feedback data: How often should I be looking at my feedback backlog?
It depends. (I know, I know.)
It mostly depends on the volume of feedback you’re receiving.
If you are at a younger startup you may be receiving a low volume of feedback, which means you might be able to get away with triaging your feedback backlog once a week.
As the volume increases, you may have to allocate at least one hour every day.
However, this may not scale long-term for a company that receives feedback in the thousands.
For anyone managing large volumes of feedback, there are a few alternate solutions that could be employed.
Advisory Customer Boards
Many companies have customer advisor boards, which contain members of various customer segments.
These act as “representatives” that can help give insights into what these particular segments are experiencing.
While to a certain degree this might work, it’s important to understand this could lead to potentially biased information, so it’s always good to supplement this with further discovery and research and not solely rely on such a small number of users.
Research Teams
Another way of managing large volumes of customer feedback is through dedicated research teams.
This means you can put the right amount of resources into the managing and understanding of feedback as it comes in, without putting additional strain on your existing teams.
Provided the company has the financial resources to have such dedicated teams, this is probably my favorite solution.
Community Management
Managing large volumes of customer feedback is often effective in a community environment.
And by this, I don’t mean through upvotes🤮.
Your community team should be there to help liaise, discuss, and encourage conversations among users.
Even better, if you can get involved as well, that creates a real sense that your product teams work. But even if you didn’t have the time, your community team would be sending feedback your way through some sort of automation or integration that could connect these conversations directly to your customer feedback management tool.
NLP-based analysis
To speed up the process, there are plenty of NLP-based tools out there that can help analyze large amounts of text.
As far as I know, there aren’t a lot of feedback or product tools that do this just yet at scale, but it’ll be interesting to see what comes up in the future.
With that in mind, there’s still a level of humanity and empathy that needs to go into processing and understanding feedback (particularly as it relates to problems to solve) — so I wouldn’t overly rely on NLP systems other than providing extensive help as far as digesting the information.
Conclusion
That’s it for now! If you read this far, thank you.
I think there’s a vast space in solving feedback management problems in the product world. If you’re looking for a problem to solve, this might be it!
Looking to collect feedback with in-app surveys? Get a Userpilot demo and see how easy it is to get started.
