5 invalid errors when collecting product reviews

At the beginning of work on a project or at the stage of radical changes in the product, it is difficult to resist the temptation to interview all of its users in order to determine the situation. This is usually a mistake. In fact, there are a number of common mistakes that occur again and again. We at Alconost have translated five tips for collecting product reviews for you.

1. Stop communicating with “ALL USERS”

When you interrogate all your users at once, you miss the specifics. You mix those who signed up just yesterday with old customers. Those who use your product daily, with those who sometimes log in to update their payment details. Those who use only a specific function, with those who use them all. It turns out a terrible mess.
')
Decision:

• If you need to improve the registration process, listen only to those who have signed up recently.
• If you want to improve the feature, communicate only with those who use it.
• If you need to understand why people do not use the function, talk only with those who do not use it.
• If you need to find problem areas, poll only active users who use all the functionality.

2. FEEDBACK MUST BE CONSTANT

Standard approach - request feedback on demand. But this means that when you need feedback, you will have to wait, without doing anything, for another week before they arrive. Trying to compensate for this, you throw a very wide network, ask a lot of questions and freeze in anticipation. If you are extremely naive, you would prefer to process each review separately as it arrives, rather than waiting for everyone to analyze the entire array. And this is a double problem: firstly, you will never have reviews when you need them, and secondly, you will find out about the problems only when you decide to ask about them. This means that the gradual degradation of your product will remain invisible to you.

Solution: request feedback regularly. The easiest of the useful approaches is to request user feedback every 30, 60, 120, 365 days, etc. A slightly more advanced option involves collecting feedback on a particular function after the first, twentieth, and fiftieth cases of its use.

It is important to know the opinions of users accustomed to the product. A review of the first use will explain what confuses the user, a review of the twentieth will give an understanding that is disappointing, a review of the fiftieth will clarify the limitations.

3. Distinguish between feedbacks of paid and free users.

There is not much difference, the user pays $ 50 or $ 500, but there is a noticeable difference in the types of requests that you receive from free and paid users. Longtime free users are only able to give you an understanding of how to improve your free offer, but business rarely focuses on that. A free offer, as a rule, exists only for attracting users and then raising their status to paid ones. You can take into account their hypothetical feedback like "I will pay if ...", "I will become a paid subscriber when ...", but it rarely brings benefits. It is better to build on what has already happened in reality.

Decision:

• To improve your product for paid users, ask for the opinion of only paid users.
• To find out what makes people move into the category of paid users, speak only with those who have moved from free to paid.
• If you want to improve your free product, contact only free users. I think they will ask you for more free features :)

4. DO NOT GIVE UP TO AN ACTIVE MINORITY

When five users ask you to simplify the form of creating events in the calendar, do not perceive these five as representatives of the needs of all users and do not rush to immediately launch a project to simplify the form. First you have to try to check the needs of all users. Start by polling the calendar users and see what else it turns out.

Solution: consider each group of reviews that catches your eye as a hypothesis, but do not rely on it, but check. As soon as it turns out that the problem is really urgent, the next step is not to create the required solution: you will have to dig deeper. Which brings us to the last point.

5. USERS ARE RARELY ASKING ABOUT THAT IT REALLY NEEDS

To paraphrase Confucius: when the user points to the moon, a naive product manager examines his finger. The faster horses example is often used to justify not wanting to listen to users, and this is truly a great way to miss the point. If the user says that he wants a faster horse, in fact he tells you that speed is a basic requirement for transport. And you are thinking about how to satisfy it. In the previous example, there were five users complaining about the complexity of the form of adding events to the calendar. It would have been possible to spend weeks on simplifying the input form using natural language or its UX optimization, but none of this, as it turned out, would have helped. Communication with calendar users quickly revealed that the problem is not in the complexity of the form, but in how often it has to be used. And this problem was successfully solved by introducing repetitive events and simplifying the duplication of events.

Solution: keep in mind that user requests for new features are a cocktail of their desires, skills, knowledge of your product and lack of understanding of their own current problems. They know nothing about your vision of the product, what functions you have in development or what is technically possible at all. Therefore, it is important to abstract a little and consider user requests from a position that makes sense to you and benefits your users.

Of course, it is important to clarify that sometimes such requests will get to the point. Then they will be consonant with every detail and perfectly fit into your vision of the world. In such cases, the verification, abstraction, and grouping steps can be omitted and you can trust your product intuition. This will work as long as you yourself remain a user of your product and are constantly aware of the needs of your users.

But in any other case - talk to users, it will make you smarter.

By the way, what mistakes did you make when collecting feedback?


About the translator

The article is translated in Alconost.

Alconost is engaged in the localization of applications, games and websites in 60 languages. Language translators, linguistic testing, cloud platform with API, continuous localization, 24/7 project managers, any formats of string resources.

We also make advertising and training videos - for websites selling, image, advertising, training, teasers, expliners, trailers for Google Play and the App Store.

Read more: https://alconost.com