Chef
Normally software products are designed with a list of bullet points in mind, specific things that it must do in order to compete in the marketplace. This is even more true of software that’s going to compete with something that already exists in the marketplace, because conventional wisdom holds that nobody will take you seriously unless you can at least go toe to toe with the established competitor. Whatever features you may have that are unique are less worthy if they’re not the icing on top of a pre-existing cake, rather than if they’re the cake itself.
Unfortunately this methodology leads to a development cycle of diminishing returns, as you pile more and more bullet points onto your feature list, you get further and further away from the problem the software was created to solve in the first place and in turn put off more and more potential users, not just those upgrading from a previous version who don’t see anything worthwhile, but new users as well, who see your software as far too complex for them to understand. A good example of this is Microsoft Office, which gets an upgrade release every couple of years or so, and which Microsoft finds ever harder to sell to businesses. They just don’t see enough benefit in changing. And for the new users, or those that have upgraded, there’s so many features that they don’t even know they exist. When Microsoft does studies to see what people want in the next version of Office, 99% of the time the feature already exists, it’s just so buried under everything else it’s not clear. And the funny thing about all this is that they’re stuck, because if they change the interface too much and try and solve the problems users have about not being able to find the features they want to use, like they’ve done in the latest release, business complains that it’ll cost too much to retrain the users and still won’t upgrade. Microsoft are on the upgrade merry-go-round now, and there’s no getting off.
But for new software, there’s no reason to put yourself in that position, as long as you accept that your software doesn’t need to be right for everyone. When I designed Alertbear I did so because no existing RSS reader out there did what I wanted it to do, so I designed the reader for me. It didn’t matter if it didn’t do what everyone else wanted, it did what I wanted, and that was enough. Turns out from some of the email I receive, it does what lots of other people need it to do too. But if you’ve got 500 feeds and you check them every 2 minutes, then you probably want to look elsewhere.
Like some foods, or a musical group, software isn’t for everyone. But rather than create it like a chef does for a customer who chose it themselves from a menu of many choices, we spend most of our time trying to create a dish that caters to all palates. Nobody would pick a restaurant where there was only one dish containing every possible ingredient, you’d be disgusted, in fact you’d probably be sick. So when you’re designing your next bit of software, be choosy, pick only the best ingredients, and mix them together with the care and attention of an award winning eatery. You may just find people pick your dish from the menu far more than you would think.
