Responding to app feature requests I'm not going to implement [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this question

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.

Answer 1

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).

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.