Simple or feature rich? Usable or complex? It’s time to address a most perplexing question — Should you make your product simple and usable or feature rich and complex?

On one side are companies like Apple and 37Signals. Give the users simplicity, they say. On the other, Microsoft and most Linux apps. Give the user features, is their motto. And I? I say, hurrah for the long tail.

You see, both are right in their own way. Users want simplicity. Users want tons of features too, even if they arent going to use them all. Also, every user has a different ton of features that they want. Like Joel says, everyone wants 20% of the features, but each want a different 20%. So how do we go about solving this dilemma?

Above is a diagram that many of you might recognise as the Long Tail power curve. On the X axis are different features. It’s shown as a continuous axis for convenience. On the Y axis is the number of users using that feature. Its sorted such that more popular features are on the left. In red is what I will call the “hit” features that everyone will use. In yellow are the “niche” features that a small number of people will use.

The Apple philosophy is to have only the red, “hit” features that most want and leave out the rest to enable simplicity. The Microsoft philosophy is to have both “hit” and some “niche” features. They can serve more users this way, but compromise on simplicity. You see, unlike book or music sales, having more features has a side-effect on usability, so its not a simple question of just having more features.

Thats why your product must be hackable. I’m talking about hackable in the sense of extensible, of leaving room in the product to do things that it was not initially designed to do.

You can now design your product to implement the hit features, but leave it hackable so that the community can implement the niche features. Suddenly, your product can handle both. Not only that, users happy with the features in the product will be happy with the usability of the core product. Users wanting to get their hands dirty can do that too.

An example: I wrote before that Catalyst does only project management. Thats the simple and usable part. But Catalyst also has a REST based web API through which you can access the data in scripts outside the tool.

Someone asked me if Catalyst can integrate with source control. I was thinking about it when I realised that SVN has pre- and post-commit hooks. What if you could write a script which looks at the log message and if it found the text “Fixed Bug#xx”, took the Catalyst data via the API and set the corresponding task to done. How cool would that be? This is something that would be hard to do as a core feature, and will almost definately impact usability, but is great as a hack. And it wouldn’t be possible without leaving the data open for access via the API.

Another example: Export. The problem with export is that every tool has its own import format. Should we export to CSV? XML? Excel? There is no standard format that other tools can read. One solution is to implement a host of export formats for each tool. But using the API, you can write a script to get the data and save it in whatever format you want. What if you cannot write such scripts? Thats where the community comes into play. Only one person needs to create the hack and everyone else can use it.

Most companies attack users for using the product in ways it was not designed to be used. This is unfortunate because these are very passionate users. Don’t do it. Go a step further and make your product hackable. That way you can provide a great core experience and have the community extend it with cool hacks.

With all that, I’m happy to announce that once the beta period starts, I will be adding a hacks section to the site to document some of the cool stuff you can do with Catalyst. Happy hacking!

PS: In this article, I’m talking about hacking, not cracking. Dont confuse one for the other.