During the day, I work making a top-quality flight and hotel search Android application. On May 8th, we launched a major redesign to the Play Store. New UI, vastly improved hotel product, and the addition of in-app booking. Since then, we’ve received great feedback from users. Much of the feedback will be familiar to most producers of consumer applications or developer APIs.
This is really cool, but it would be better if you could do x, y, and z.
The knee-jerk reaction is to think—let’s add all these features overnight, push an update, and all these users are going to be so impressed and happy. Nothing but five-star reviews for us. If that sounds to you like walking into a trap, you are right.
You must resist.
Turns out this trap has a name, and it’s called the availability heuristic. In short, it boils down to:
All the user feedback asks to add stuff, and nobody is asking to remove anything. So obviously adding features is what users want, right?
Adding new features indiscriminately will lead to feature creep. It will make designing harder and possibly make the outcome be worse. It will add noise for all of the users that don’t care for the feature. It will make it harder to change the product. It will add more code. It will increase the risk of bugs. It will increase complexity. It will limit future-you.
Users do not like it when features they use are taken away from them. For a spectacular example you may relate to, Spotify’s recent desktop client removed the ability to see a list of all your friends and what music they like—along with many other features that users had come to like. The community response was not good. Maybe you’re not Spotify-sized and don’t have that many users. Maybe you have metrics in-place and know only 1% of your users utilize feature X. But as a general principle, once a feature exists, removing it will annoy or anger a non-trivial portion of its users.
To decide which feature requests you should pay most attention to, you can separate requests into pseudo-features, that make current functionality more convenient to use, and truly new features that facilitate entirely novel actions for the user. If you make a messaging app, a request of the former type might be to add to add a “clear chat history” button so that users don’t have to delete messages one by one. A request of the latter type might be user-drawn image sharing, so you can send people doodles . In the first case, the user could already clear chat history, but only by doing something really inconvenient. In the latter case, the users will be able to draw on pictures, which they could not do before.
The first kind of feature request is easier to deal with, and it is usually a good idea to implement them, if opportunity-cost is not too high. There’s a few things to consider, like how long it would take to implement, how risky the code changes would be, and how many users would be benefited. In practice, you will probably also have to take into consideration if you even want to make an action easier to perform. There’s still good reasons to not add features of this kind, but these features are less insidious.
The second kind of feature requests is more complicated. Many of the questions just mentioned still apply, but the possibility that this kind of feature will add lots of new code is greater. The most important question to ask yourself at this stage is whether this feature furthers the vision or goals of your product. A great product is simple-to-use and focused on solving a few problems well, not all of them, because it is always better to solve one problem beautifully than one hundred problems badly.
By ruthlessly triaging features, you take a big step to making a great product. You get that much closer to a tidy experience that gets out of the way, that delights, and that solves a few problems very well. You get closer to—in one word—excellence.
For a much more thorough exploration of the subject of feature selection, I recommend Getting Real, a book by Basecamp maker 37signals. It was written about web applications but the concepts are universal.