It’s often said that you should listen to your users to improve your product. However, the reality is, it’s a really tough challenge, and I believe you need lots of practice and experience to do it well.
I still find it difficult to say NO to users, but I want to share my thoughts about this.
I feel bad about saying No to user requests
When I was watching the iPhone5s Apple video, Jonathan Ive said something like this.
We are as proud of the things we have said No to as the things we have done.
I believe this is really important thing for product design.
When your users request or suggest some ideas, usually, every one of them makes sense in their contexts, and I can understand why they want that in most cases.
However, if I execute every great idea, eventually, the product becomes messy one with lots of noises. It ends up being a product nobody wants by trying to make something everybody wants.
We should choose what to execute very carefully.
Having said that, even though I know the principle in my brain, when I get requests from users, it’s still hard to say No to them. Users like your product, and took their precious time to write something to you, but you have to say NO most of the times.
This is not easy.
When I read the 37 signals book “getting real”, I remember they say “It’s hard to say No, but you have to be good at it”.
As a Japanese person, we have a stereotype image about Americans that they are good at saying No. But, even if they think that is hard, for Japanese people who are really bad at it, it must be really tough challenge.
So, what can I do.
How do you reply?
So, how can I say No to users.
To people who took their time to give me feedbacks and requests, how can I reply? I always find it really hard.
For example, one person say like “I need this feature because..”, and you know that is useful, but you want to protect simplicity of your product.
Let’s say you explained like, “I understand the value of the feature, but I cannot make it since I need to add features which will be used for 80% of users at least.”
In this case, for users who requested the feature, it doesn’t matter if they are in the 80 % category or not, I might end up pissing them off by explaining to them with data.
I really want to say “I will do it in the near future!”, but making a promise about future plan is the last thing you want to do in product development.
You never know how your product goes, and you cannot avoid changing priorities of product often. If you make a promise, and turned out you couldn’t make it later, users would be upset.
Again, in the “getting real”, it is recommended to say “we’ll think about it” basically.
“Think about it”… this carried me back to my childhood when I was blaming Japanese politicians always saying “I’ll think about it” without promising anything. I now know why they needed to say in that way somehow.
Basically, I try not to promise anything to users, because I can never tell what I am going to do for my products in the future.
Even if I expect I would definitely implement one feature, I try not to say I am working on that.
However, I feel bad to say the same template sentences like a robot to users, so at least I try to understand why users request some features and explain my situations sometimes.
How do you say why?
It’s important to say “why” to understand the backgrounds of each requests well. Some people say we should repeat why, so we can dig into the needs behind the requests.
However, in the real world, it is easier said than done. Don’t you think you get tired if you are asked “why, why?” when you just request one feature?
In this case, I try to confirm reasons, just like, “you are requesting this feature, because you have this issue, am I right?”
I believe it’s less annoying to users instead of being asked with why, and of course, this attitude can minimize risks of implementing new features without knowing the real reasons behind feedbacks.
Priorities…
It sounds convincing when you say that “I cannot do that since I should protect simplicity of my product…”, but, it could not be a real reason for not doing something in many cases.
Sometimes, implementing some feature takes too much time, or I cannot see any corresponding benefit for the time. Especially when you are selling apps for a few dollars with one time purchase business model.
In this situation, it is much harder to explain this to users.
Having said that, it’s really worth listening to feedbacks from users as much as you can, since you can learn something you have never thought of. Even if you get opinions you expected, that means you are validating your hypothesis.
If you seek for feedbacks from nowhere, it’s gonna take a time to meet people which are your target users.
When they come to you and ask for something, this is a golden opportunity to learn a lot and get valuable insights.
Plus, you feel great when you see people who actually care about your product. This is why, I set a feedback box using Helpshift for Taxnote, Zeny, and other apps.
I understand you want to avoid getting support emails for apps when you stopped updating in the future, but, at least when you are working on that constantly, it’s worth putting a feedback box inside of your apps.
Related articles
This is a really good article related to this topic.
PRODUCT STRATEGY MEANS SAYING NO
“Avoid Setting Publicly Visible Deadlines” part of this article.
Running A Software Business On 5 Hours A Week
37 Signals Getting Real. One of the best in product development.
https://gettingreal.37signals.com/GR_arb.php
***
I got an email from Gergana of SANSMAGIC saying this issue resonated with her. Her book about how you can reply to customers includes very detailed tips on this topic, and she shares her own experiences in the real world.
http://sansmagi.cc/resources/
*I've made Text-to-Speech, Money Tracker, and Timer apps. About Me.
