Website Survey

Should You Listen to User Feedback?

Unless you're the next Steve Jobs and you think you know better than everyone else, you should seize any opportunity to receive customer feedback.

But before you start…

Send your “vision” down the drain

Replace it with a direction that can be changed by user feedback. The “users are stupid and I know better” approach is a waste of time:

Instead of trying to persuade someone they need what you have already built, build what they already need!

Personal example: How we tried to force our “vision” on people

The environment that our product exists in is quite messed up (imagine a plug-in for an open source project). But we wanted beautiful code that conformed to best coding practices. We wanted it to be super-optimized. It's what every developer should strive for, right? Well, in a way. Only in a way.

Version 1.x of our product was awesome from our point of view—the code was neat ’n tidy, we even tried to fix some of the broken things in the environment. But… this was not what our customers were excited about. Nobody cared about “best coding practices”. The only thing that our customers (and yours, too, I bet) care about is that “the product works as expected”.

Like a friend of mine wisely concluded:

Developers care about the performance of their product. All users care about is completing their task.

For a long time we tried to persuade them that messed up code would hurt performance, that what we did was in their best interest, but they didn't want to hear about it. As a result, very often we had to modify our product to get it to work with the rest of the system. We had to add spaghetti code and include badly written third-party libraries. And if we hadn't thrown a lot of effort into supporting the product, the percentage of refunds would have hit the sky.

So, in v2.0 we shifted the focus from “best coding practices” to “compatibility”. We had to make some compromises. But now our product is super-awesome from our customers' point of view. The number of support requests was cut down by half. Customers praise it even more than before. We are all happy.

Lesson learned:

Products built on customer feedback are the ones that last. And the ones that sell.

So, please, ignore your ego and send your “vision” down the drain.

Request feedback

When customers request a feature or complain about the way a feature works, I always ask them to explain how adding the new feature, or changing the old one, would improve their workflow. The valuable part of feedback is the core problem the customer is trying to solve with the product. So, I try to ask questions that will help me find this problem.

Real-life example

A customer requested a feature last week. Before writing it down I asked them how exactly they would benefit from having it:

Hey <customer_name>,

I'm glad to hear that you've found <product_name> useful so far.

If you have a minute, could you tell me more about how you'd be using <feature>:
What is your current workflow with <product_name>? How would <feature> improve it?

I would really appreciate your opinion and feedback. And I'm curious to learn how you use <product_name> in the wild.

<\signature>

I was quite surprised by the length of the reply and the valuable information that the customer provided: He shared some Google Analytics statistics with me, he told me how he used the underlying system day-to-day, in his business. It was truly eye-opening.

Thank the customer and say “Maybe I'll work on this”

After explaining why they need that particular feature, the customer will likely ask you when and if you are going to add it.

Don't feel guilty for not giving them what they want right away. Just say that you are grateful and you'll use their feedback to improve your product. Don't promise anything.

As another friend pointed out:

Sometimes you might implement a feature, experiment with it for a while and determine that it complicates the design of your product. You might then exclude it from the final release.

Back to my example, here's how I replied to our customer:

Hi <customer_name>,
Thank you for the detailed explanation and your feedback. Such a valuable insight!

I will keep in mind the points that you mentioned.
<feature> sounds like an awesome thing to have and I added it to the list of requested features.

[I mentioned the time-frame, because he would ask about it.]
Since we haven't started working on this, there isn't an exact time-frame yet. So, stay tuned and check for updates regularly.

[I also told him about another relevant feature that we added, because I don't want to leave the customer with the frustration of “Sorry, you have to wait indefinitely”]
By the way, did you know we recently added the ability to <new_feature>. If you haven't tried it out yet, go ahead and download the new update. Here's an article which covers <new_feature> in more detail.

<signature>

You can use the above letter as a template response (or inspiration) for saying “Maybe I'll work on this. Thank you.”

By the way, if you're tired of picking your brain for the right words to say to a customer every single time, try the solutions in my free ebook.

Remember: Feedback is a golden ore, not pure gold

For example, a customer might say something like: “I want Facebook login”. This is a piece of the ore.

The pure gold is the core problem. Someone who wants Facebook login is actually saying: “I want a super quick and easy way for anyone to login. I want logging in to be effortless.”

To listen to the users is not to do exactly as the users say.

Instinctively, customers will often tell you how to solve their problem. However, each customer has a different background and experience with different software. If they know that program A does something in a particular way and they are used to this particular workflow, then they will request that you add exactly the same functionality. They are comfortable with it.

But a feature is a solution to a problem. And there is an infinite number of solutions to the same problem. In the end, you are the designer of your code and user interface. It's your job to find the best way to solve users’ problems.

Don't let feature requests distract you

And don't ignore feature requests just because they don't conform to your vision. Mine that golden feedback ore and pick the pieces of pure gold—the problems. See how and if your product can solve them. You might even solve some problems with a new product. ;)

About the author Gergana Dimova

I use my non-magical persuasion methods to help small business owners, digital agencies, entrepreneurs and consultants get more leads and sales. You can learn more about working with me here.

Leave a Comment