The Long Tail of Features: Why you should make your product hackable

Posted on January 18th, 2007 in Hacks, Long Tail, Product design by siddharta || 7 Comments

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?

The long tail of features

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.

Doing Distributed Agile?

Share and collaborate with distributed teams with our electronic agile board tools. Get all the benefits of electronic tools without sacrificing the benefits of physical boards. Supports Scrum taskboards, Kanban boards and user story maps. Check it out!

7 Responses to “The Long Tail of Features: Why you should make your product hackable”

  1. Michael Says:

    I don’t believe that supporting the malicious efforts of the hacker community is a good thing. I’m outraged at your open support of software pirates, virus writers, sexual predators, murderers, abortionists, and cut-and-run Democrats. It’s people like you that will result in the downfall of this great country.

  2. Russ Says:

    Michael, that reads like that classic diatribe against the women’s movement. I’m hoping you’re being funny. As in ha-ha, not weird.

    Siddharta:
    Where’s the line between “didn’t code this because I’m lazy” and “didn’t code this because the return on effort isn’t high enough, but we left the API open so someone else can write it” ?

  3. Mr. Smith Says:

    Michael, did you even glance at the content of article. It was not about making software easier to crack. It making a case for building extensibility into the core of you product, and the benefits that affords you when it comes to been able to appeal to your customers when they would like to have a feature that doesn’t make sense to include in your core product. On the contrary it is people like you that will be the downfall, making snap rash judgments and extrapolating them without reason or consideration of what was being said.

    siddharta, I agree that building extensibility into the core of a product creates a much better product in the long run. As it allows a community to form around your product and also allows you to use the extensibility to create niche plugins that don’t belong in the core product. This is a feature that has to be designed into the core of the product and cannot be tacked on late in development. Also consideration has to be given to versioning and keeping the external api’s stable, since once they are out in the wild there isn’t alot of room to make huge changes without breaking the work of the community.

  4. rid00z Says:

    Siddharta, Have an open API will not work for all software. For alot of software it would be a waste of time.

    If you have users that don’t spin code. Users that have trouble even using software/a computer. What is the point of having and open API?

    My point is an open API is not always required.

    I have worked on projects that have scripting engines with hooks/events. These engines are not open, why would you want users breaking your software? The scripting is used internally to give custom features.

    You should first think about the users before you make decisions like this.

  5. JohnPearson Says:

    Nice Post.

    That was well said. Always appreciate your indepth views. Keep up the great work!

    John

  6. BronGondwana Says:

    rid00z,

    We have hundreds of thousands of users who match your definition (hardly able to use a computer) yet we also have the occasional user:

    http://www.fastcheck.org/

    who will produce something that these users can use, not affiliated with us, and improve our core product. Guess what – they started by hacking around webscraping us – then we wrote a CGI to support them, and finally we exposed a subset of our total functionality via SOAP so that not only could their product be better, but we could offer the same to anyone else who wants to extend our service with their own local tool.

    I only wish we had a more general API and more flexible access methods. It’s only TODO list now, especially after reading this article.

  7. siddharta Says:

    Russ: It’s not just a question of return on effort. The Apple argument is that too many non-hit features degrades the user experience for the majority, hence the emphasis on reduced feature set. Based on this argument, the line for which features to code is simple — Code the “hit” features that everyone needs and maybe a few “niche” features, while leaving the other niche features to the community.

    Smith: Yes, making the product extensible is a feature by itself, so it needs to be thought of before. It helps to make the product hackable from the start.

    rid00z: The open API is just for implementation of niche features. Your core product should cover the features required by the majority of the users. i.e. The product should be good for the majority without the need for extension.

    BronGondwana: Thanks for the brilliant example that illustrates this perfectly.

Leave a Reply