Posted By Paul Kafasis on December 3rd, 2004

Users often make feature requests, and that’s great. Our users suggest all sorts of crazy new ideas we’d never have come up with on our own, and often they warrant inclusion in a future update. Because customers use the software we create in ways we could never have envisioned, they offer invaluable fresh perspectives.

Put simply, we love our users. Rogue Amoeba couldn’t survive without the people who purchase our products, and you can be damn sure that we know it. The following is not a rant against our users, especially those interested in helping us improve our work. We have no desire to stop the flow of requests and suggestions. Indeed, it is an essential element to what we do, it is a staple in the diet of software development. This is simply a treatise on a topic familar to all developers, to which they may point as needed. It begins with 3 things to keep in mind when asking for a feature:

1) Be aware that you don’t represent all of our users.

2) Don’t browbeat us.

3) Our job isn’t as easy as it looks.

The first item in our list is a response to actions caused by little more than a healthy psyche. Every well-adjusted person believes her opinion is valuable and we wholeheartedly agree. The problem arises when one assumes she knows what other people want as well. I know I’ve been guilty of this when speculating on things Apple does, such as the iPod mini. A year ago, I couldn’t fathom anyone paying so much for so little capacity. Now it’s a runaway hit, and we know people are plenty willing to pay more for less, provided it’s less physical size we’re talking about. I don’t know what’s right for everyone else just because I own an iPod and a user doesn’t know what’s right for everyone else just because he’s used our product.

We attempt to avoid this flaw in our own thinking, as noted in our previous Good Ideas article. “We Are Not Our Users” reminds us that our own usage is probably not the one true way to use our apps, nor even the most common one. The problem is that our users are not Our Users. Sounds strange, doesn’t it? Put another way, one user is not representative of all users nor even necessarily a subset greater than 1. Extrapolating information from a data set works far better as the sample size grows. On our end, we’re fortunate to have a large pool of data coming from many different users, but each individual user doesn’t have access to the full spectrum of feedback we do.

The second note comes in response to two things we hear, “I’ll buy it as soon as you add…” and “It’s useless to me without…”. There’s no doubt about it, we want every sale. But just because a salad spinner is needed doesn’t mean we can drop everything to add a salad spinner. If there’s a do-or-die feature we’re missing, we want to know about it. But if it’s not currently available, and it’s that urgent, alternate solutions should certainly be explored. Our development cycles are flexible, but we don’t want to hurry anything and we certainly won’t rush for a quick cash grab. When there are critical bugs that need to be fixed we move with all possible speed, but adding features deserves time and consideration. Sloppiness and greed in development will only lead to problems down the road.

The third and final item derives from comments such as “Please add feature X, it will make my life so much easier and it’ll only take a minute”. This is a simple appeal to practicality. We all feel our time is valuable, so things which take less of it will be viewed kindly. The problem is, no one ever knows the true time cost of adding a feature and rarely are key aspects such as design and organization factored in to these time estimates.

Another side to the “only take a minute” argument is that because the feature is inconsequential, adding it will have no impact. The gruesome truth is that every addition has a ripple effect. Changes often expose little-known bugs or subtly corrupt the overall design. As an application grows, it becomes more and more unwieldy, a veritable Jenga tower of features, flaws, and fourteen hour days. Every change is a tremor that shifts the balance of the application.

Other times these requests are phrased as an appeal to the developer’s vanity. “It should be easy to code…” or “If your code is properly organized, you can just…”. Far from being a motivation for adding the feature, this sort of thing is likely to foster mild resentment. Writing or moving code is very easy to do, provided you don’t care at all about doing it right.

We need look no further than Microsoft Word to see that it’s easy to add lots and lots of things. There’s a great word processor buried in there somewhere, but each and every user has to work to dig it out from under the 80% of features they’ll never use. Instead of this jambalaya style of design, we strive for a simpler, more elegant (and Apple-like) approach. Our software may not do everything, but everything it does, it does well.

When we contemplate the addition of a new feature we consider many different things. We don’t want users to do that. Beyond basic considerations of practicality (our software is never going to cook breakfast), suggestions and requests don’t need filtering. There are only three things that should be done. First, realize each suggestion or request is valuable to us, and we can easily determine how popular it will be by collecting a large data set. Second, threatening us with a lost sale is a poor negotiating tactic. More flies with honey, and all that. Finally, recognize that it’s never as easy as imagined to add a feature request. In fact, it’s usually much harder. Ideas are great, please submit them – just give us the ability to say “we’ll consider it” without needing to defend our very honor.

Do you have a feature request or suggestion for one of our products? We’d love to hear it, so drop an email our way.