10

I'm a new app developer and after like 20 downloads of my app (free and ad-free) I already got two feature requests, and I'm not going to implement either.

Should I respond to these feature requests and if so, how? I'd prefer not responding at all because I'd rather spend the time to work on my app, but being a new developer, a couple of poor ratings in the app store could hurt my app.

closed as primarily opinion-based by Ixrec, user53019, user22815, user40980, Scant Roger Dec 29 '15 at 0:17

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    Lucky you! Users who care enough to use your app and talk to you about it. You're doing something right. Keep doing it. [The answers are excellent, so I'm not going to add one.] – david.pfx Apr 24 '14 at 11:04
  • After 2 years, 5000+ reviews, and hundreds of feature requests, I can say that the number of feature I get is the best indicator of user engagement and future potential of the app (even early on when downloads are poor). I can also conclude that it doesn't matter if I respond to feature requests, pretty much none of the users are so entitled to be insulted if I don't respond. Some users will try to leverage a 1* review to get what they want, but they typically won't send an email beforehand and they usually won't change their rating even if you do what they asked, so best ignore them. – TimSim May 31 '16 at 17:20
11

Put together a stock "thank you for your interest" letter that covers the possibilities of a) features you will NEVER implement even if I show up on your doorstep with a bag of gold, b) features you don't PLAN to implement but maybe, and c) features you'd like to implement but can't right now. Send that. Because you ALMOST never know when you might find yourself moving something from a) to b), or from b) to c).

  • I think this is the best way to do it. I'll just use a few stock replies, thank them and commit to nothing. – TimSim Apr 21 '14 at 20:01
15

I think that you can only lose by choosing not to communicate.

If you don't plan to implement the feature now, at least suggest users that it is not in the current plan to implement, but might be considered in the future. This would not let users think that it's a feature they can expect soon and will send a message that you are not planning on it either. At the end, you might change your mind in the future (e.g. if these requests will occur more often, maybe it's something users would pay for?).

If you are sure that you are not implementing this feature ever because let's say that you want to go completely different direction with your app, then just ask user to consider trying to use the app your-way.

Communication with your users is important process if you want to build a user-base for you application and a short reply will not take you a lot of the time to write.

  • 1
    Well I took your advice and now I have a new pen-pal and his one feature request turned into 7... and he didn't even rate my app. – TimSim Apr 21 '14 at 19:57
  • It's probably worth nothing that "communicate" here means saying "thank you for your interest." If you say much more than that, the customer may conclude you just promised to do what they want, regardless of what you said. And that's far, far worse than saying nothing at all. – DougM Apr 22 '14 at 16:48
8

Ideally, you should use such requests as an opportunity to help you and users better understand the application.

If you think of it, the very reasons why you prefer to ignore these requests are quite important information and you'd rather have them stored and documented than buried and forgotten deep down in your mind.

If a request is ignored because you don't have time to implement it, but generally looks like good idea, you better keep a knowledge of that somewhere. Later on, when you have time, you may get back to it and reconsider.

Or, if a request is ignored because it is really bad idea and you can write down an explanation for why it's so, this would also be useful knowledge to store somewhere. Doing so will make it easier to address similar requests from other users, or even help yourself if you eventually forget why you thought it's a bad idea.

Keep in mind that spelling out and writing down reasons why some features may do more harm than good will help yourself better understand your application, it's intended use, limitations and strong points.

As an example, take a look at the very Stack Exchange network. Feature requests that are decided not to implement here aren't buried down. Quite the opposite, these are made public, thoroughly analysed and kept for further references conveniently tagged status-declined at Stack Exchange meta site.

  • Oh, I like getting feature requests and I like considering them but I don't want to spend much time responding to users. If I think it makes sense, I'll implement it, otherwise I won't, but my main concern is getting 1-star ratings from users who couldn't convince me to spend a weekend fulfilling their special wish. – TimSim Apr 21 '14 at 20:00
  • 1
    @TimSim - Just worry about getting the 5 and 4 star reviews instead of trying to convince somebody cannot be convinced not to give you a 1-star review. – Ramhound Apr 22 '14 at 18:44
  • @TimSim from your comments here and in other answers it looks like you don't use issue tracker to communicate with users. If this is the case, then answer you accepted makes pretty good sense... although I'd still recommend to get a tracker instead – gnat Apr 23 '14 at 5:35
1

I think the other answers are on the right path in encouraging you to correspond with your users.

one feature request turned into 7..

Based on this comment, you're not giving users enough feedback on the types of features you are open to. Maybe they want you to expand the capabilities/feature set but you're more concerned with performance and usability of existing features? Declining a single feature isn't enough to guide users. They'll keep using trial and error and in your pen-pal's case, the shotgun approach.

The goal is to encourage feedback and give it some direction.

0

Any of this requests, even if you don't planed to implement this feature before is a signal directly send to you. It is annoying, and it is gold. Sometimes you have to wait before you take a decision : if you got only one person asking for something, you could certainly argue that your application shouldn't implement this feature, but if dozens of them ask for the same thing after some time, it could make you think about your own design (and you should).

So I believe an answer is always preferable, because you can't care of your product without caring this feedback. The simplest thing is only to answer that any suggestion is welcome and that it's precious for you, even if everything can't be implemented, it will not be ignored.

and I'm not going to implement either

You have to think about it, and decide which things you could maybe implement, even if you don't planed it before because it could be good ideas, or it could help you to make evolve your primary design.

Not the answer you're looking for? Browse other questions tagged or ask your own question.