When you’re at the beginning of a new project, or especially if you've been experimenting with the product recently, you’ll be tempted to get a survey from all your users. It’s usually considered a mistake. Wondering why? There are five common mistakes that we used to make over and over unknowingly, that let all our efforts go to the vain.
This is where Hellonext comes in. Hellonext collects feedback from your customers without breaking a sweat. As a result, it’s simple to become a little trigger satisfied with the feedback requests.
This article will help you to know the five quick fixes for product feedback management. Read on...
#1 Stop communicating to all customers
When you request feedback from all your customers together, negotiate the specifics. You mess up yesterday’s sign-ups with life long powerful customers. With, those who used your product in their routine to those who record in just to update pricing details. Also, those who only use some particular feature with those who depend overall for your product. It’s a complete mess.
Avoid this and start doing this. There’s a much better way to get much valuable feedback. Here are some of those:
- If you want to develop your onboarding, only focus on people who recently signed up.
- If you want to build a feature, only communicate with those who use it.
- If you want to understand why customers are not interested in using your features, only communicate with those who don’t use it.
- If you need to determine the areas of concern, only communicate and request feedback to active users who use all your features.
#2 Feedback loop should never stop
The regular approach to feedback is to promote it on demand. But, that means when you realize you want it you have to wait for a week doing nothing while it comes in. To compensate this, you cast a vast net, request a lot of questions, and sit back. If you’re specifically not ready, you’ll react to each piece as it comes in, rather than waiting and analyzing it entirely.
The major issue here is twofold: At first, you never have feedback at your side when you need it, but secondly, you only listen about issues when you choose to request them. This means you’re not aware of the gradual degradation of your product.
So, the solution is frequent check-in with customers. The easiest, yet still meaningful, version of this is to request customers for feedback on the scheduled manner like weekly or monthly. This takes about 20 seconds to fix in Hellonext.
A preferably more advanced version would be to gather feature requests without any mess and organize those feedback based on usage. As a customer gets used to a product, their feedback matures. Keep your feedback loop on the go but don’t ruin the whole day by collecting itself. Hellonext helps you to do this by spending only some minutes each day.
#3 Prioritize your feedbacks
It’s always easy to assume that all the received requests are of similar value, regardless of the stage of an account. This is hardly true within certain thresholds of pricing but there’s a notable difference between the type of requests you get from your trail customers and from paying customers.
Long time trial customers are only capable of providing you feedback on how to improve your trial plan, which is barely a focus for a business. Trial plans exist to draw customers in and upsell them. You can’t lend your ears to hypothetical feedback:
- I’ll update if…
- I’ll update when...
- Supportive behavior is rarely useful, learn from things that happened.
So, how to solve this, here are my ideas
- To develop your product for your premium customers, only communicate with your paying customers.
- To learn what makes customers update from the trail, only communicate to customers who upgraded from free.
- When you want to develop your trail product, only talk to customers who are in the trial period.
#4 Never fall for the group of vocals without analyzing the real demand
The plural voices of the same request are not data, but that does not mean it is not useful. The plural of anecdote is just narrative. Something verifiable.
So, when five users request for a simpler event form in the calendar, it doesn't mean you assume five people mimic all the customers' needs and suddenly kick off an “event simplification” project, leaving other important works aside.
Preferably, you should attempt to verify if these five customers represent all customers. You start communicating to calendar users and analyze what else comes up.
Try this for a solution, use every clustering of feedback that seems like a hypothesis, and then don’t try to build it, verify it. Once you confirm that the pain is real, then the next step is never “build that requested solution”, you have to go a deep dive before deciding anything. Which brings us to the last point.
#5 Don’t assume all the customer’s feedback are the right one to build
When users are in urgent need of some features, the naive product manager examines their finger. If a customer says they want a feature urgent, what they’re requesting you is that speed is a key requirement for transport. So ensure how you deliver that.
Be aware that user feedback is a cocktail of their design skills, their sense of your product, and their level of understanding is not much as you have. They don’t know if your product vision, what features you’re recently working on, or what’s technically possible. This is why it’s crucial to analyze a level or two above what’s requested, into something that makes sense to you, and value for all your customers.
Of course, it’s useful noting frequently a feature request will be spot on. It will rhyme with everything else and perfectly fit in the world the way you see it. On these occasions, you can just jump steps, like, verification, analyzing, and clustering, and loyal your gut.
Your product initially provides you with awesome shortcuts, so long as you’re still an active customer of your product, and always in touch with the needs of your customers.
But on other occasions, communicating with your customers makes you smarter and better at making decisions.