When it comes to feedback, it’s prioritizing feedback and knowing what to take in and what you ignore that’s going to make the difference. There is a lot of noise out there, and not all feedback is created equal. Here are some guidelines for how to start prioritizing feedback:
Prioritizing feedback – Specificity
First, think about whether the user feedback is specific or general in its nature, this is the first step to deciding if it is actionable and worth retaining. Specific feedback is much more useful than general feedback because it can help you pinpoint areas that need improvement. General feedback, on the other hand, is often too vague to be of any use and requires lengthy back-and-forth between recipients and users who submit feedback to understand the actual ask within the user feedback – if there even is one.
Product Managers and software teams can work to facilitate more specific feedback and help users by offering visual feedback mechanisms rather than purely open text options or email feedback requests. By allowing screen capture with annotations, video supported by audio or even full session replays of user interactions, feedback can be centered on complex digital elements without the need to try to explain it in written form. When it comes to user feedback, a picture really is worth a thousand words.
Prioritizing feedback – Actionable
Once user feedback is coming in clear, it’s time to decide whether or not it’s actually actionable when prioritizing feedback in your repository. Is there a defined outcome that needs to be addressed within the feedback to make it worth holding onto? An outcome could come in many forms for software teams, a new function or feature request, a bug fix, a UX improvement or an integration needed to streamline business. Look for these statements within the feedback to confirm the value of feedback. Anything without a clear call to action from developers probably isn’t worth accepting into your feedback workflow and should be screened out.
Taking feedback without the action item associated only leads to more back-and-forth or false assumptions of the underlying thoughts and adds to the potential of feedback assumptions being made which could lead to incorrect product assumptions.
Prioritizing feedback – Organizational focus
So, you’ve got some specific feedback with an action item for the developer teams… The task of prioritizing feedback isn’t quite done. You’ll need to decide if it’s relevant for your current product priorities. You may have a major internal push on feature builds and bug fixes to better the quality of your product, so when a piece of user feedback comes in that has a suggestion for a integration, whilst valuable, you need to weigh up carefully whether that feedback should be integrated into current workflows for change, or be put on the shelf for a later date when developer resources are more readily available. Developers are a limited resource in business in this day and age, so keeping them focused and at maximum productivity is critical, and being selective with feedback timing can be key to that.
This also raises the need to categorize your feedback, providing users a system that allows them to self identify with pre-approved categories at time of submission or by providing them with a user feedback portal in which software teams can access to categorize according to their own wish separate to the submission. This goes a long way to ensuring user feedback can be grouped into the focus at any given time and creates a consistent format for feedback to be assessed and prioritized longer term.
The final tip for this article (I know we said three, consider this a bonus) is to consider frequency. If you’re getting good feedback by the standard raised here earlier, but it doesn’t align with current roadmap priorities, consider the frequency of this user feedback – how many times a bug is reported gives good indication of how impactful it is on your users and how damaging it is for satisfaction and ultimately renew of that software license. So if your focus with limited resources is on feature builds and integrations, give strong consideration to adding in feedback that repeatedly is produced by your user community. The more frequent any user feedback is, the higher the impact that can be implied from it is and the more impactful that change will be – regardless of if it is a bug fix, an integration or a UX element and it could make a meaningful difference to your product adoption.
Modern user feedback platforms have the capability to allow users a view of other suggestions and interact in a similar method to familiar social media platforms, liking or upvoting existing submissions and pushing the more frequently liked user feedback items to the top without the need to manually group and stack rank. If frequency is high enough in any area, it should be considered a priority and added to the focus areas mentioned in the above point. As a side benefit without additional effort from software teams and Product Managers, these feedback portals where users can see fellow users submissions adds to a sense of community and vendor engagement and actually drives up user satisfaction with a vendor before action has been taken as users feel their voice is being heard and can actively contribute to the products future. It’s a win-win for software teams and users.
By effectively categorizing, prioritizing and distributing feedback in this pragmatic way, software teams can maximize the effectiveness of user feedback and their own product roadmaps leading to increased market fit and more satisfied user community and Developers have less noise and fewer distractions in which to slow development cycles, increasing the time to market for future feature releases. How can you go wrong with such little investment for such a major outcome when it comes to prioritizing feedback the modern way.
If you’d like to start modernizing your feedback methods, do as 20,000 other software teams have done and to help with the prioritization and much more.
