Twitter's business model seems to be the familiar - "Web 2.0 Flip" - build an audience and sell to someone who thinks they can monetize it. There are key lessons to be learnt from Twitter for Telcos and other service providers.
Our analysis shows that Twitter:
Twitter is the current Social Network Service (SNS) flavour of the day for the media. It has been promoted for diverse causes: from the rallying call for Iranian government opposition to a public diary of Hollywood stars' hourly insights into life. It's appeal to and massive success with users is rooted in the need to participate (analysed in-depth in our new report "Serving the Digital Generation").
To other people calling Twitter a service is a stretch of the imagination. In its current form it is only accepts messages, of a maximum 140 characters, and publishes them to a list of subscribers. Despite this simplicity Twitter has managed to attract US$55m of Venture Capital funding and is the constant source of speculation as to whether Facebook, Microsoft, Yahoo, AOL or Google who ultimately purchase it.
In this note, we explain how the rush to build scale without a focus upon on any underlying business model is extremely risky. It can lead to unintended consequences and allows both partners and competitors to capture the value chain - leaving little value for your service and your investors to capture.
In our opinion, Twitter has to move fast before any value within its network is destroyed and probably management’s best option is to sell the company now and leave the problems of revenue generation and competition with the internet players to someone else.
The lesson from previously popular social networks such as:
...is that timing of exit is of paramount importance.
For five years from 2001 Twitter founder Jack Dorsey mulled over how to distribute status information. At that time, the major instant messaging services, such as AIM and ICQ, had status features but distribution was limited to PCs and internet connectivity was limited to the home or office. Dorsey figured that the real value in status information was when delivered to the mobile phone. People could see in real time what was happening from anywhere.
Fig 1: Early Design Document for Twitter
This is a dream shared by many mobile operators which have repeatedly tried many different approaches - from failed mobile instant message clients to the new rich communications suite (RCS) vision. We have noted our concerns around RCS before.
Even Google has struggled with mobile Social Network Services. In 2007, Google bought Jaiku for an undisclosed amount. Jaiku offered a similar service to Twitter. In 2009, Google closed the Jaiku service after the service failed to build momentum and gain scale.
By 2006, the founders had figured out that the perfect medium for delivery was of course SMS. A little further brainstorming led to the name Twitter and the company was launched.
It is important to recognize that the service was able to be launched for "free" in the USA, because the USA carriers adopt a "receiving-party-pays" model for charging. The subscriber to the status updates, or tweets as they were now called, was paying their carrier for delivery.
Across, the pond in Europe with the "sending-party-pays" model, Twitter had to pay the carriers for delivery. As popularity grew in Europe, the costs grew proportionally. In August 2008, rather than lose its "free" tag, Twitter turned off SMS notifications in the UK. A golden rule of internet economics is to keep variable costs to a minimum. Updates to Twitter via SMS were still permitted with the user paying for sending texts and the cost to Twitter zero.
The beauty of having such a simple service is that theoretically it shouldn't consume a lot of compute resources: both bandwidth consumption and storage requirements are extremely limited; and there are not a lot of complex calculations to place processors under strain.
Nevertheless, scaling applications to serve a large community is tricky and Twitter has had its fair share of downtime. Admirably, Twitter doesn't hide from its availability challenges and publishes statistics for its web-based service - see below.
(www.pingdom.com/reports/wx4vra365911/check_overview/?name=Twitter.com)
Twitter also faced problems interfacing to the original home of status messages - Instant Messaging Services. Microsoft, Yahoo and Skype are closed systems and Twitter has never interfaced to them. However, Google services are open and based upon the Jabber protocol. Twitter had an interface with Jabber and then didn't have one. To us at Telco 2.0, often of the view that Telcos are slow to embrace interoperability, it is somewhat ironic in this case that Telco services such as SMS are far more open and easier to interface to than some of the darlings of the internet world.
One thing that Twitter hasn't done is recruit an army of technical resources to solve its problems and expand its features. The recently leaked Twitter internal documents reveal a total company-wide headcount forecast to be only 65 by Dec 2009. At the end of the day, coding volume is directly proportional to volume of bodies and brainpower thereof. Twitter doesn't seem to have a lot of technical bodies available and their technical output is constrained.
The set of Twitter APIs is probably the key reason that Twitter has managed to keep its headcount so low. Effectively, third parties have built on top of Twitter simple messaging service and built richer clients and extended the functionality. For an indication of relative volumes, the APIs attract at least ten times the traffic of the web. One of the Twitter founders, Biz Stone said "The API has been arguably the most important, or maybe even inarguably, the most important thing we've done with Twitter."
Many people salute Twitter's approach to APIs; however we believe that Twitter's API strategy is flawed - we believe that APIs always need a business model. The sole rationale for the Twitter APIs seems to be growing fast without increasing the headcount. That is a benefit - but comes with a high probability of value (i.e. realisable revenues) leaking away from Twitter, the provider of the API, to the consumer of the API. This can make sense when there is plenty of revenue to go round - everyone wins - but less so when the revenue count is low or zero, and especially without a clear and credible plan to change that.
A recent in depth study of the use of Twitter by 11.5m people in June 2009 by Sysomos illustrates the potential for value leakage.
The rest of the article, covering:
...can be read by members of the Telco 2.0™ Executive Briefing Service and the Dealing with Disruption Stream members here. Non-members: please see here to subscribe.
