Lessons From Twitter In Scaling A Platform Business
By Matt Boys
The case of Twitter
The case of Twitter
Two-sided platforms are a popular model for internet technology companies. The basic proposition is to build a consumer-facing service that people love enough to sign up for and engage with, then build an API on top of the service for third-party developers to extend the core value proposition, leveraging the registered users and the core functionality of the service.
The value to the company is threefold. Firstly, a vibrant ecosystem of third-party developers can innovate on features more efficiently than the company, brought about not only by the volume advantage of the number of developers writing code, but also from the diversity in ideas, use cases and features. Secondly, the core service becomes more valuable to users by extension as the number of features and use cases proliferates. Thirdly, this proliferation helps the company tailor its product roadmap: by observing which use cases are popular among users, the company will be able to better direct their engineering resources to creating in-house features that users love. In this way, the third party developers are akin to running MVPs in-house to test what works and what doesn’t, and the three value points are a virtuous feedback loop: third party developers riff on the core product, users adopt the features they like most, company adjusts core product in response.
This strategy worked well for Twitter: their core product evolved to include features that were first developed by third party developers, including search, photo sharing, url shortening, and native clients for a variety of devices.
However, this strategy proved dangerous for Twitter. In February 2011, UberMedia, led by industry veteran Bill Gross, went on an acquisition spree, buying popular Twitter clients leading to an estimated market share of 20% of Twitter users[1]. Indeed, Twitter were forced to defensively acquire TweetDeck for $40m to thwart UberMedia’s consolidation strategy. The reason why Twitter had to act was because UberMedia was planning to monetize the users of their clients by showing contextual ads – importantly not ads “in the stream”, but rather contextual banner ads, served by UberMedia themselves. Had UberMedia acquired TweetDeck, they would have had more Twitter users than Twitter themselves[2]; this would have been a disaster for Twitter’s own monetization strategy.
This “existential threat” lead to Twitter drastically curtailing its API terms and conditions, including introducing a maximum number of users that third-party applications are able to have.
They key question is, could Twitter have avoided this predicament? Fred Wilson, one of Twitter’s early investors via Union Square Ventures, doesn’t seem to think so. Speaking in Jeff Bussgang’s Launching Technology Ventures class at Harvard Business School[3], Wilson characterized Twitter’s relationship with third-party developers as a “bait and switch”, but strongly emphasized that it was not an intentional bait and switch. Here was a company growing almost by accident: it was an internal project at an earlier company that accidentally gained traction with no thought given as to how it would become a business. No thought was given to the potential pitfalls of having an open API. Wilson is of the opinion that Twitter should have rate-limited their API from day one. However, this begs the question of whether Twitter would be the product it is today had it adopted that strategy. Wilson’s answer is blunt: “no”[4]. Moreover, “Twitter was the perfect storm and I'm not sure that anybody else is going to be able to get away with what they got away with because I think that has become a little bit of a cautionary tale for developers”[5]
So where does this leave the rest of us? Is it possible to scale your company using third-party developers building on you open API in a post-Twitter world? What is the correct balance to strike between having an open API that encourages developers to iterate on your core product on the one hand, and not exposing yourself to the risk of usurpation on the other?
The solution
The value to the company is threefold. Firstly, a vibrant ecosystem of third-party developers can innovate on features more efficiently than the company, brought about not only by the volume advantage of the number of developers writing code, but also from the diversity in ideas, use cases and features. Secondly, the core service becomes more valuable to users by extension as the number of features and use cases proliferates. Thirdly, this proliferation helps the company tailor its product roadmap: by observing which use cases are popular among users, the company will be able to better direct their engineering resources to creating in-house features that users love. In this way, the third party developers are akin to running MVPs in-house to test what works and what doesn’t, and the three value points are a virtuous feedback loop: third party developers riff on the core product, users adopt the features they like most, company adjusts core product in response.
This strategy worked well for Twitter: their core product evolved to include features that were first developed by third party developers, including search, photo sharing, url shortening, and native clients for a variety of devices.
However, this strategy proved dangerous for Twitter. In February 2011, UberMedia, led by industry veteran Bill Gross, went on an acquisition spree, buying popular Twitter clients leading to an estimated market share of 20% of Twitter users[1]. Indeed, Twitter were forced to defensively acquire TweetDeck for $40m to thwart UberMedia’s consolidation strategy. The reason why Twitter had to act was because UberMedia was planning to monetize the users of their clients by showing contextual ads – importantly not ads “in the stream”, but rather contextual banner ads, served by UberMedia themselves. Had UberMedia acquired TweetDeck, they would have had more Twitter users than Twitter themselves[2]; this would have been a disaster for Twitter’s own monetization strategy.
This “existential threat” lead to Twitter drastically curtailing its API terms and conditions, including introducing a maximum number of users that third-party applications are able to have.
They key question is, could Twitter have avoided this predicament? Fred Wilson, one of Twitter’s early investors via Union Square Ventures, doesn’t seem to think so. Speaking in Jeff Bussgang’s Launching Technology Ventures class at Harvard Business School[3], Wilson characterized Twitter’s relationship with third-party developers as a “bait and switch”, but strongly emphasized that it was not an intentional bait and switch. Here was a company growing almost by accident: it was an internal project at an earlier company that accidentally gained traction with no thought given as to how it would become a business. No thought was given to the potential pitfalls of having an open API. Wilson is of the opinion that Twitter should have rate-limited their API from day one. However, this begs the question of whether Twitter would be the product it is today had it adopted that strategy. Wilson’s answer is blunt: “no”[4]. Moreover, “Twitter was the perfect storm and I'm not sure that anybody else is going to be able to get away with what they got away with because I think that has become a little bit of a cautionary tale for developers”[5]
So where does this leave the rest of us? Is it possible to scale your company using third-party developers building on you open API in a post-Twitter world? What is the correct balance to strike between having an open API that encourages developers to iterate on your core product on the one hand, and not exposing yourself to the risk of usurpation on the other?
The solution
My solution is that companies should only permit API partners to complement and augment their core service. Twitters customer value proposition is to be “the fastest, simplest way to stay close to everything you care about.”[6] Some uses of Twitter’s API do complement and augment this: photo sharing complements the core service by giving another plane for users to interact on. Search augments the core service by enabling users to discover new things to care about. Others do not: building an iPhone client is a replication of the Twitter experience, not an augmentation.
The distinction is a fine one. A quick and dirty test is this: firstly, articulate your customer value proposition. Secondly, consider uses of your API: which uses could your value proposition articulate? Which could it not? My argument is that you should not allow the former, but encourage the latter.
The distinction is a fine one. A quick and dirty test is this: firstly, articulate your customer value proposition. Secondly, consider uses of your API: which uses could your value proposition articulate? Which could it not? My argument is that you should not allow the former, but encourage the latter.
An example
An instructive case is to look at a company who have taken a slightly modified approach. Heroku is a “platform as a service” (PaaS) business, allowing users – in this case developers – to easily push their applications live. The deployment and management of live applications is essential to any software company running applications on the internet, but the chore is commoditized: the process of deploying and maintaining is more or less the same for the majority of applications. By offering this as a service to developers, Heroku removes the need to spend time building and maintaining a live environment, and reduces the cost to the user by passing on cost savings from operating at scale to the user in the form of lower prices.
On top of this is Heroku’s API. It allows third party companies to offer services to Heroku’s users that leverage Heroku’s core service – the production environment. Such third party services (which Heroku calls “add-ons[7]”) include email delivery (for transactional emails and email marketing), monitoring services, and specialized hosted datastores.
The key difference between Heroku and Twitter in their approach to the API is that these add-ons are just that. They extend the core service, but they don’t replace it, and they don’t have the potential to replace it. Heroku’s core value proposition is to “[let] app developers spend 100% of their time on their application code, not managing servers, deployment, ongoing operations, or scaling.”[8] Using my quick test above, their add-ons certainly augment and complement the core service, but their customer value proposition could not be used to describe the value proposition of the add-ons themselves.
The road forward
On top of this is Heroku’s API. It allows third party companies to offer services to Heroku’s users that leverage Heroku’s core service – the production environment. Such third party services (which Heroku calls “add-ons[7]”) include email delivery (for transactional emails and email marketing), monitoring services, and specialized hosted datastores.
The key difference between Heroku and Twitter in their approach to the API is that these add-ons are just that. They extend the core service, but they don’t replace it, and they don’t have the potential to replace it. Heroku’s core value proposition is to “[let] app developers spend 100% of their time on their application code, not managing servers, deployment, ongoing operations, or scaling.”[8] Using my quick test above, their add-ons certainly augment and complement the core service, but their customer value proposition could not be used to describe the value proposition of the add-ons themselves.
The road forward
A crucial element to the ecosystem of third-party developers building on top of a company’s API is trust. Developers need to have sufficient faith that the company won’t pull the rug out from under them. As Wilson noted, developers, having been bitten by Twitter, are now shy.
The downside of my strategy for managing API use cases is that it is reactive, not proactive: a use case must be defined (whether or not built) for it to be run through the augment and complement rubric. This could lead to developers building services on top of your API that you find you need to revoke, making it difficult to establish this all-important trust. The solution to this is open, clear dialogue with third-party developers. Companies providing APIs will need to view this channel of communications as a cost of providing the API. For smaller startups, this could be in the form of an active blog and discussion forum. For larger companies (when the number of developers using the API numbers in the tens), having a dedicated developer evangelist on staff will be a necessity.
It would be very easy to shoot this down on a cost basis: a headcount devoted to evangelism might be viewed as extravagant. This is shortsighted. The case of Twitter illustrates just how expensive these matters can become in the long term. Moreover, a developer evangelist will be able to stimulate use of your API in the developer community, helping kickstart the positive feedback loop of feature innovation.
Ask not, “can I afford to do this?”; ask instead, “can I afford not to do this?”
The downside of my strategy for managing API use cases is that it is reactive, not proactive: a use case must be defined (whether or not built) for it to be run through the augment and complement rubric. This could lead to developers building services on top of your API that you find you need to revoke, making it difficult to establish this all-important trust. The solution to this is open, clear dialogue with third-party developers. Companies providing APIs will need to view this channel of communications as a cost of providing the API. For smaller startups, this could be in the form of an active blog and discussion forum. For larger companies (when the number of developers using the API numbers in the tens), having a dedicated developer evangelist on staff will be a necessity.
It would be very easy to shoot this down on a cost basis: a headcount devoted to evangelism might be viewed as extravagant. This is shortsighted. The case of Twitter illustrates just how expensive these matters can become in the long term. Moreover, a developer evangelist will be able to stimulate use of your API in the developer community, helping kickstart the positive feedback loop of feature innovation.
Ask not, “can I afford to do this?”; ask instead, “can I afford not to do this?”
Comments
Post a Comment