5 unacceptable errors when collecting product reviews

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

1. STOP COMMUNICATING WITH “ALL USERS”

When you interview all your users at once, you are missing out on specifics. You mix those who signed up only yesterday with old customers. Those who use your product daily, with those who sometimes log in to update their billing information. 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 signed up recently.
• If you want to improve a feature, communicate only with those who use it.
• If you need to understand why people do not use the feature, talk only to those who do not use it.
• If you need to find problem areas, interview only active users who use all the functionality.

2. FEEDBACK MUST BE PERMANENT

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

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

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

3. DISTINCT REVIEWS 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 can only 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 to attract users with the subsequent upgrade of their status to paid ones. You can consider their hypothetical feedback like "I will pay if ...", "I will become a paid subscriber when ...", but it rarely benefits. It is better to build on what has already happened in reality.

Decision:

• To improve your product for paid users, be interested in the opinions of only paid users.
• To find out what makes people move into the paid users category, speak only with those who have switched from free to paid users.
• 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 TO AN ACTIVE MINORITY

When five users ask you to simplify the form of creating events on the calendar, do not take these five as representatives of the needs of all users and do not rush to immediately launch the project to simplify the form. First you should try to check with the needs of all users. Start by polling your calendar users and see what else comes up.

Solution: consider each group of reviews that catches your eye as a hypothesis, but do not rely on it, but check it. 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 REALLY ASK FOR THAT IT REALLY NEEDS

To paraphrase Confucius: when a user points to the moon, a naive product manager examines his finger. Faster Horse Exampleoften used to justify unwillingness to listen to users, and this is a truly grandiose way to miss the point. If the user says that he wants a faster horse, he actually tells you that speed is a basic requirement for transport. And you are thinking about how to satisfy him. In the previous example, there were five users complaining about the complexity of the form for adding events to the calendar. One could spend weeks simplifying the input form using natural language or its UX-optimization, but none of this, as it turned out, would help. Communication with calendar users quickly revealed that the problem was not in the complexity of the form, but in how often it had to be used. And this problem was successfully solved by the introduction of recurring events and the simplification of duplication of events.

Decision:keep in mind that user queries regarding new features are a cocktail of their desires, skills, knowledge of your product and a lack of understanding of their own pressing problems. They don’t know anything about your vision of the product, what features you are developing or what is technically possible. Therefore, it is so 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 in tune with every detail and perfectly fit into your vision of the world. In such cases, the steps to verify, abstract, and group can be omitted and trust your product intuition. This will work as long as you yourself remain a user of your product and are constantly in the know about the needs of your users.

But in any other case - speak with users, this will make you smarter.

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


About the translator

Translation of the article was done in Alconost.

Alconost localizes applications, games and sitesinto 60 languages. Native-language translators, linguistic testing, cloud platform with API, continuous localization, project managers 24/7, any format of string resources.

We also make advertising and training videos - for sites that sell, image, advertising, training, teasers, expliner, trailers for Google Play and the App Store.

Read more: https://alconost.com