Friday, November 30, 2007

How Does Long-Tail Economics Apply to Software Features?

The term "Long-Tail" is traditionally used to describe a business model where the cumulative sales of a high number of different of low demand products or services are greater than the cumulative sales of the few best selling products.  It's been a buzz word lately to describe a whole host of businesses such as Amazon, Google, and Apple iTunes.  The key factor of success in this business model is that the business must keep the cost of inventory and distribution of these products and services low.

When it comes to software features, the opposite usually applies.  Software features aren't traditionally thought of as assets.  As the small features come in, usually per individual client request, they're added to the software.  The features pile in, and the once pristine architecture becomes muddied by the one offs and exceptions that are made in order to accommodate these smaller features.  Over time, these features become more and more difficult to maintain as those exceptions in the architecture cause bugs.  People forget that the feature exists, until the one client that uses that feature finds the bug you introduced when working on a different feature for that other client. 

In most cases, the only real metric we can gather from this "inventory" of infrequently used features is that they will collectively consist of more lines of code than the highly used features.  Due to the fact that these features aren't usually thought of as inventory, the true cost of this inventory is never realized.

So what would happen if you were able to sift through your software's features and quantify each feature with the number of  clients it was sold to, and how much additional they paid (if any) for that feature?   How do you quantify the fact that if that feature didn't make it into the software, clients may have never purchased the software at all?  Would this number exceed the sales of the frequently used features of the software?

There's companies out there that firmly believe that the Long-Tail concept for software features is a very bad idea.  For instance, the folks at 37Signals take a very minimalist approach to software development.  Only features that are truly inline with the primary function and focus of the product are considered for the software.

So can a Long-tail model work when it comes to a piece of software?  Can you really quantify how much the features in your long-tail cost?  If you decide to cut your long-tail features, can you quantify the possible sales you lose?

Is there a third option?  Can you create a bunch of smaller pieces of software that partition architectures well?  Is it possible to use a standard API that would not be influenced by the needs of the individual long-tail features?  Could you create your own mashup of different features that are built as separate pieces of software to make your solution look like one integrated piece of software targeted towards that client?

Seems like the third option is pretty viable, and that is the model Google and Yahoo are following.  They treat their individual features as individual products.  Individual items that exist in inventory.  Each of these individual pieces of software combine together to create a greater whole that fits the needs of each individual customer.  Each of these long-tail software components speak the same language, but put no pressure on the other's architecture, though they may share common components.  And because these pieces of inventory can be easily combined with other pieces of inventory, and are maintained individually, the cost of inventory and distribution shrink, which is a pillar of the long-tail model.

It's an interesting concept, that I'd like to explore more.  Anyone else out there have any thoughts or comments?

0 comments: