All say fast iterative feedback, the question is is your feedback really effective?

English Original: 5 mistakes WE all do with PRODUCT FEEDBACK

Translation/heaven Zhuhai rudder; Public number: techgogogo/@techgogogo

We have done products, whether it is success or failure, should have deep feelings: often we all the situation to consider all the user feedback, in fact, this is not realistic, nor correct. It is a very foolish act to satisfy the requests of all users.

When you are launching a new project, especially when you are taking over the development of another product, often we tend to investigate all the users first to find out how the product function should be located. And we tend to move in the wrong direction. In fact, we get the user feedback in the process of repeated mistakes there are 5. At present, many mature tools can let us quickly get feedback from users (such as Intercom), the result we tend to because the feedback is too easy and a little carried away by the random shooting, for each user's request to provide the implementation.

Let's look at the following 5 common mistakes and solutions.

　　1. Refine feedback to get objects

In the order of the English press from left to right and from top to bottom:

• All Users
• New user
• Recent Dive Users
• Users who are trying a Beta version
• Long-term loyal supporters
• It's not necessary to talk to all users to get feedback

When you are too divergent on all users to research together, often you will lose focus. You tend to confuse users who have just signed up yesterday with the ones that have been growing with your product, and treat users who are using your products every day and those who only visit occasionally, and compare users who use only one feature of your product to those who are using the full functionality.

　　Solution : In fact, you should distinguish between different types of user feedback, here are some ways

• If you want to add new customers, then it's good to interview those new customers.
• If you want to enhance a feature, then it is enough to communicate with the user who is using the feature.
• If you want to know why some of your product's features are rarely used, then talk to people who don't use it.
• If you want to find out what is wrong with your product, then it's up to you to consult with those active users.

　　2. Getting feedback should not be a one-time

We often have a preconceived idea of getting feedback: We look for user feedback when we need it. But it also means that you often have to wait nearly one weeks to get the feedback you want. In this case, you will usually cram for the beginning of the wide network-start to find all the users to ask the different questions, which you re-made the first mistake above.

This wrong practice brings double harm:

• The first is when you really need to have feedback to analyze the time when you are empty-handed as well;
• The second is that you only get feedback about your product when you decide to take the initiative to find a user survey. This means that you know nothing about your product even if it has been gradually eliminated by the market.

　　Solution : Periodically interact with the user. The simplest and most effective way is to get feedback from users 30 days, 60 days, 120 days, 1 years after the market. A more advanced approach is to get user feedback based on the use of the product/function point. For example, if your product has a function point of the calendar, you can get the feedback when some users use it for the 1th time, 20 times, 50 times. When a user is accustomed to a product, their feedback will gradually become mature and rational. Often when users first use the feedback is about how the feature makes him confused and so on, the 20th time use will complain that the feature frustrating, the 50th time will complain about the function where the need to enhance.

　　3. Free and paid users should divide and conquer

Describing the different feedback of free users and paid users, the free user will always be constantly on the feature of novelty:

• Please provide with ... The functionality of the synchronization.
• Can this be run on my own host?
• Does this support the Atom protocol Feed?
• Please go with the following ... For integration.
• Can I provide Dropbox as a data storage feature?
• Please add a calendar feature.
• If you can provide ... function, I will buy it.

And the charge users are more than the requirements of the existing features to improve:

• Please improve the ability to invite team members to the email.
• Please improve your search performance.
• Please improve the functionality of team assistance.
• Please provide a better search tool.
• Please provide the task completion notification function.
• Please improve the task scheduling function to make it easier.
• Please accelerate for retrieval.

As the 1th says, we tend to mistake all the users ' needs without taking into account whether they are paid users or free users. Of course, if you want to differentiate between the 50-dollar paid users or 500-dollar paid users, but the big place, we first distinguish between free and paid users. Users who use your products for a long period of time will often only give you advice on how to improve your free features, which should not always be a priority for your business. We provide free features to the purpose is to put the user first stick, and then slowly find ways to let them pay to buy the function, but also improve their product visibility. So here you have to be aware that you should not trust the hypothetical feedback that is full of deception at this time: "If ... , I will pay to buy the "," when ... , I'll pay for it. " This deceptive pseudo-qualitative feedback is often illusory unworthy, can not be cashed, we need is real feedback.

　　Solution:

• If you want to pay for your paid users to solve the payment function, go to pay users to get feedback.
• If you want to seduce those free users to pay for the paid function, go and talk to the customers who have paid for it.
• If you want to improve your free feature points, ask those free users to have a cup of coffee. Forget it, I suggest you do not go to drink coffee with them, direct free email consultation forget it. Because I believe their feedback must be to want more features, free features.

　　4. Occasional does not necessarily mean

A proverb has a cloud, and occasional does not mean it is inevitable. Of course, this is not to say that some of the occasional incidents are not worth paying attention to. Some of the occasional incidents with easy to verify the feasibility, we go to fast verification under the good.

But, when one day you find that there are 5 users who give you feedback at the same time that you want to add an event alert function to your calendar function, you should not immediately shoot your head to set up a person to start the project. The first thing you need to do is to determine if the 5 users represent all the other users, and you have to talk to other users who often use the calendar feature and listen to what they say.

　　Solution : Take the occasional request as a hypothesis, and don't rush to implement it, first to verify that it really exists value. Once you find out that it's really a pain point, don't rush to "implement a solution that satisfies the user's request" and you need to dig deeper. This is the last point we're going to talk about.

　　5. Users often express unclear what they want

　　The dialogue on the left of the diagram is like this :

good team members ,

Functional requirements: Are you building a pony? If so, can the horse be built in the expected plan?

Sincerely salute, Dave.

Dave,

Hello, you.

We have put your feedback requirements into the plan and we will hand you the faster horse in the first quarter of 2015. Is the prototype of the horse.

　　The dialogue on the right of the graph is like this:

good team members ,

Functional requirements: Are you building a pony? If so, can the horse be built in the expected plan?

Sincerely salute, Dave.

Dave,

Hello, you. Thank you for your interest in the importance of horse speed, do you have any other needs we can improve?

Team members,

Speed is of course an important point, but overall reliability and endurance are equally important. A horse that can make me run from Gansu to Beijing in a day is the best for me, otherwise I will be shipped to Beijing to sell the cut cake expired ...

"The process of information transmission is prone to distortion!" ", a very vivid example of this situation is:" When the customer fingers pointing at the moon, our naïve product managers will often extend their middle finger to observe, meditation on what the user is trying to express what is wrong with his finger, or the customer is sticking out the middle finger to their own insult. In fact, what the user really wants is the moon. "

"Pony Tales" are often used to describe situations where customer feedback is not being carefully listened to. It shows that if a client tells you that he wants a faster horse, the message he gives you is just to tell you that "speed" is a very important feature of the horse's transport process. Then you will be preconceived about the speed of this point for a long development. To return to the example of the calendar we mentioned last time, if those users simultaneously proposed that the calendar's existing events function is too complex, you may spend a few months to re-create a smooth user experience of the event form functionality for these users to re-experience, after several revisions, eventually you find that the problem is not solved. Eventually you go to all the other users who use the calendar feature to get feedback, you find that the pain points are not the complexity of these event forms, but the reusability of these events. So the final solution to the pain point is that it only takes 1 weeks to provide the event loop and event replication functionality.

　　Solution : Be aware that the functional requirements of the customer are in fact mixed with their own understanding of the design, familiarity with your product, and their understanding of the pain points they perceive. They are not really sure what your product vision is, what you are perfecting the functionality of the program is all about, and what kind of technology is most feasible. So this is why you often need to do a layer to two layers of abstraction on the user's needs, until the real user pain points are found, so that all users can benefit.

Of course, in some of the functional points that have become consensus, we do not need to check each of the above several user feedback to act, such as in our China, you a calendar tool plus a lunar function I believe that few users will oppose.

However, in other features that require user assistance to determine, please follow the steps above to interact with your customers and get effective feedback to analyze it, which will make your actions more sensible, smarter, and more agile.

http://news.cnblogs.com/n/518129/

All say fast iterative feedback, the question is is your feedback really effective? Go