Marco.org

Instapaper is a one-person operation, and all of its development needs to fit into my free time. I originally made it for myself, because I had a need for it, and I didn’t even tell anyone else about it for months. It ended up being useful to other people, but that was a fortunate side effect. When it came time to make an iPhone app, I made my own dream app to satisfy my needs, and the same thing happened: it was adopted by other people who had the same needs. This development and feedback pattern has a number of interesting side effects and corollaries.

I use every new feature myself in a long test cycles — often weeks or months — before deciding whether to release it. I rarely use other beta testers, only bringing a handful of people into testing before major releases or major changes to the storage engine, and they never see features that I haven’t already been using for a while.

Major features only get developed if I want to use them. And, correspondingly, features I’ll never use are unlikely to be implemented.

Features that I don’t personally believe in are unlikely to see the light of day, such as an unread-count icon badge. I believe unread-count badges signify unseen items with some degree of urgency or time significance that were triggered by other people or external events. Instapaper articles are added by you, aren’t urgent, and in most cases, have been seen already (when you chose to read them and clicked Read Later).

Or tags. I don’t use tags. In anything. There are a lot of fundamental organizational and practical problems with tags for which I’ve yet to see a great solution. I try to minimize ways for my customers to shoot themselves in the foot (which is why the RSS folders are so limited).

Or full-screen reading, in which you tap to temporarily show the toolbars, then they fade out after a few seconds or when you tap again. Using this feature in other apps annoys me (except Photos, in which the benefit is immense and the required toolbar interaction is minimal) because it has a very high error rate: I frequently need to tap twice to show the toolbars, and I frequently invoke the toolbars accidentally while trying to do something else, like scroll. It’s the same reason I don’t enable tap-to-click on laptop trackpads: unreliable and unintentional behavior, leading to frustration and mistrust. Instead of implementing full-screen reading, I just keep the required controls as small and simple as possible on the reading screen.

This also applies to feature removals: I’ve removed Graphical Mode from the next release. I never use it because the experience of reading with it is awful. It’s one of those features that people say they want until they actually use it and realize that it’s not worthwhile at all. (Like comments. See: customers shooting themselves in the foot.) When I asked my users if they’d miss Graphical Mode, hundreds of people told me that they never used it. Only two — literally, two, out of hundreds — said they’d miss it, but only occasionally. So I’m replacing it with a much more useful feature: an in-app browser that can be used to view full-layout pages (online only, like Safari), but will be useful in Instapaper for many other reasons as well.

I can’t imagine getting to a point where I’d want to survey my users to decide which features I should implement, or let people vote on features to “buy” their implementations. (This is why I fundamentally dislike the premise of UserVoice.) People like Instapaper because of the features it has now and the way they’re designed into the app. If I let users steer product decisions, the result would be a massive codebase producing a bloated, cluttered product full of features that hardly anyone used at the expense of everyday usability and polish on the features that matter. Like Microsoft Word. Or Firefox.

By listening too much to outside suggestions, I’d destroy the very reason why I’m receiving them.