Testing the Long Tail's First Test

Web entrepreneurs have been relying on the Chris Anderson's long tail hypothesis even before he published his ideas, so it's good to see that the academic community has begun to study the effect and test for its existence. The results of the first major study looking for proof of the long tail were announced on Harvard Business Online and were not the endorsement of the long tail that proponents were looking for. Specifically, the author, Prof. Elberse, found a growing preference for hits rather than niche products based on an increasing portion of all sales coming from the top 10% of items sold on Rhapsody and Quickflix. This leads her to recommend that companies focus on cultivating popular products, rather than long tail products, generally ignoring long-tail business models.

While these results are important and shouldn't be taken lightly, the analysis falls short of what I'd like to see on three fronts. First, I'd like to see more depth to the statistical analysis, focusing on analyzing the falloff of sales volume - rather than just sales volume in the head of the distribution - to avoid arbitrary definitions of "hit" and "long tail" (such as whether to use the top 5%, 10% or 20%). Second, I'd like to see greater attention paid to the types of goods being sold and whether they are even appropriate for analyzing long-tail effects. Finally, I'd like to see managerial recommendations that are focused on profitability, rather than top-line revenue - a more helpful metric for designing business models.

Elberse's study focuses on the head of the sales distribution, but the head doesn't tell us how the tail behaves. To do that, we need to look at how the volume of the tail falls off. Fortunately, power-law distributions (the statistical distribution that describes the long-tail theory) are easily described with a single number, k, which tells us how fast popularity dies out. Long-tail proponents would expect this number to slowly increase over time, pushing more of the sales toward the tail. Moreover, looking at deviations from a power-law distribution - lower than predicted volume in the head and greater than predicted volume in the tail - would provide a stronger indication of the long tail. (For more on some of the statistical problems in measuring the long-tail see Kurt Cagle's nice write up.)

In addition, by focusing on music and film distribution services, she ignores the fact that high production costs within these industries make finding evidence of the long tail difficult. By focusing on other industries where every part has low marginal costs, she would have had a much better opportunity for finding long-tail effects. Since much of the music and movie industries have not adjusted to long-tail forces - the bulk of the less popular titles in existing catalogs are failed hits, rather than niche products - her results aren't surprising, as she was looking for long tail at the distribution end of industries that are just beginning to support it in the production end. Until long-tail production houses like RCRDLBL and Normative take off, Rhapsody and QuickFlix can only sell the movies and albums that are produced - and since these industries have low marginal-cost distribution, but not production, they aren't ideal choices.

If you are developing a new long-tail business model these results can be disconcerting, especially given Elberse's recommendation that you ignore the long tail entirely. However, even when you set aside whether her results are correct to begin with, her recommendations are only instructive for driving top-line revenues. They fail to address what's really important: becoming profitable. Creating hits can be an expensive business - it's risky and error prone. In contrast, one of the most attractive features of a long-tail business is its focus on selling products with very low costs of production. Ignoring the opportunity for making profits with very low costs through volume means not just ignoring the entire idea of the long-tail approach, but also the importance of profits over revenue. With Elberse's single-minded approach, while there is the potential for taking in more money overall, there is also the potential of operating at an overall loss through high expenditures. You would be better off to think of your business holistically, considering both top-line revenue and profitability, for the well-being of your own business, as well as that of your suppliers and partners, so every part of your industry is working to take advantage of the long tail.

Whether or not you agree with the results shouldn't change that fact that it's important that Elberse has given us our first results in this market. Her results, made possible only through privileged access to proprietary data, are the first steps towards understanding if the web can alter the way we consume products. I'd like to see more of this research put forward and a clean dataset made public for others to examine (the likelihood of this is very low given how valuable this data is to companies - but one can hope). The publication of these results have already started a debate online and are forcing proponents of the theory to make the arguments more robust and, therefore, more helpful to entrepreneurs.

Twitter: User Co-Creating or User Co-Opting?

Now that the dust has settled from last week’s Twitter rollback of the reply feature, I’ve been thinking about how Twitter and other services with passionate users incorporate user-generated usages like replies into their core platforms—and when it's healthy co-creation and when it's a risky co-opting of the product by users. If @ replies put a burden on the Twitter service, was user dependence on them the result of a symbiotic conversation between Twitter and its users, or the result of letting users take control of the product without regard for corporate consequences?

I’m not saying Twitter falls into one category or the other—I’d rather not speculate from afar (there are enough folks doing that on the web right now)—but these sorts of features and rollbacks raise questions about how companies and users align their interests. Co-creation can be a fantastic tool for accelerating the rate of feature development in your product, provided you have other competitive defenses (Twitter enjoys a network effect that’s close to tipping to insurmountable); co-opting can cause you to support use cases that lead you to the “Fail Whale”.

In either case, something seems wrong with Twitter’s adaptation of user behavior.

If it’s co-creation, the platform and product strategies may have diverged by allowing the features to get out ahead of the platform’s ability to support them - it wasn’t supplying users and engineers with the right feedback to guide the platform towards where the users wanted it to go. There’s usually time to be deliberate in adsorbing user ideas; for example, Chris Messina wrote a spec in mid-2007 for channels on Twitter that is just starting to take hold - plenty of time to react to support or dissuade users from this behavior. Given the wide-spread adoption of this specification, and how it's used on Summize, these sorts of requirements should already have been incorporated into the platform technologies Twitter is building in an effort to get ahead of user adoption. If the long-term platform won’t support this, perhaps it shouldn’t encourage such behavior by working so closely with Summize.

If it’s co-option, Twitter can learn from some other companies that take steps to mitigate dangerous users. For example, as Ben Lorica showed,Twitter doesn’t limit friends/followers, creating situations where bragging rights exceed utility, while greatly taxing the service. Facebook, facing similar challenges, prevents users from having more than 5000 friends, limiting the damage “power users” can do to the platform. These limitations allow companies to focus on the core business and the majority of their customers. Another approach, one Twitter has adopted, is to work with partners to support needs you can’t deliver, which Twitter has done with Summize to deliver real-time search results.

Whatever is actually going on at Twitter, allowing your user community to engage in a conversation regarding your product development can be incredibly valuable, and ignoring their behavior can lead you to miss a key new feature. However, if you embrace every use of your service, and avoid every complaint about a feature you don’t support, eventually the conversation will become dysfunctional, and could prove disastrous, undermining your credibility and service.

zembly Provides Social Context for Web Development

Guest blogger Jesper Andersen is a former software architect who currently provides entrepreneurial consulting services for startups. He co-founded Ignite Chicago.

The future of application development might be becoming a little more social. Sun certainly hopes so, and has launched zembly, a new collaboration platform for writing small, and lightweight web applications. It’s a promising start, squarely aimed at small, long-tail developers, and a new approach to collaborative development over the web. Challenges remain, such as the long-term reliability of third-party application hosting and the findability of small long-tail applications on large platforms.
 
I was able to demo zembly, which attempts to lower the barrier of entry to writing applications for social platforms such as Facebook, Meebo, OpenSocial and the iPhone by sharing services and widgets - and came away impressed with its focus on ease-of-use and belief in a new development process.  zembly is working to create a social setting for developers to share components between applications - a "wiki for live, editable code that is more than just about trivial widgets, but rather about full-fledged social applications that can tap into the social graph and reach millions of users".
 
Applications are written in javascript, rely on a widget / web service development model, and have an extensive architecture for securely managing developer credentials so that you can share outbound service calls without sharing your credentials.  These widgets and services can be shared, or cloned (forked) from other developers and carry a full change log with them, so you can freeze your dependencies to a given version.  The system makes source control and component sharing simpler for the uninitiated than tools like Git and Subversion that can be difficult to learn.
 
zembly hopes that network effects will kick in, as the service will be most successful if users trust others on the system, and share components freely - something that has been hard to accomplish even in large corporate development teams.  If successful, it will be this feature that distinguishes zembly from Google App Engine and other competitors.

However, all this centralization comes with a cost - a service developers have come to rely could disappear. These fears are allayed somewhat by the fact that zembly is hosted on Sun's own network.com computational grid, but it would be nice to see an open source approach, or a mechanism that would produce a complete runtime for your application that you could run on your own servers. zembly is looking into both of these options (but no word on how to handle moving your application from a zembly hosted *.zembly.com url to your own domain name yet). As has been noted before in discussing the now defunct zimki, these concerns are real and need to be addressed so that developers can have confidence that they can migrate their applications to another solution if a vendor drops the service that hosts them.

Another potential concern for zembly's target market of long-tail application developers is helping make applications more discoverable. The market for social applications hasn't yet developed far enough to organically support long tail applications, and the platforms providers aren't bridging the gap yet. Because zembly is designed for developers of long-tail social applications, and, as others have noted, the long tail of social applications isn't a vibrant place to be yet (the O'Reilly Facebook report shows that over 90% of Facebook applications have no activity), it will be hard for these applications to rely on viral growth for installations in popular social networking platforms. Interested users will have to discover these applications on their own. This is a problem that Facebook and other platforms haven't been very good at solving - hits are the only applications that matter the social application market. In lieu of platform support for application findabililty, zembly will have to provide users with a simple service for finding new applications - a daunting task - even with the cooperation of social platform vendors.

Despite these concerns, as someone who sometimes needs a little peer pressure and social support to get started on development projects, I'll be following zembly as they build out their community-oriented features and work to deliver on their promise to wiki-fy web development, and I'll be looking forward to sharing code with friends online.

The service is currently in limited private beta but should be opening up to the public soon.
 

Recent Posts