The street finds its own uses for things — uses the manufacturer never intended…
— William Gibson
A growing number of frameworks have been put to work to create markets for services and products where none existed before. While it’s necessary to have that framework in place, a framework alone does not guarantee that a market will form. The framework has to be accessible. People need to be able to use it. Often the framework becomes the backbone of an app or a website. Uber, for example, uses its smartphone apps to present two different views into its transportation framework, one suitable for drivers, the other for passengers.
Though apps can create markets, they also limit the potential of that market. An app is a highly specific view into a market which rigidly restricts possibilities. To order up a limousine from Uber, you must launch the app. But the service – a driver, on-demand – is broadly useful. It could be used by people in ways Uber never imagined, ways that have nothing to do with a smartphone app. Uber aggregated drivers and passengers using their apps, but those apps become a cage that limits growth.
One company that understood the limitations of apps is the messaging service Twitter. Twitter began as a service for sending short messages – ‘tweets’ – to everyone interested in your activities. This service provided a framework for communication between Twitter’s hundreds of millions of members. Additionally, Twitter released an ‘Application Programming Interface’ – or API – providing similar functionality to that found on the website. The API specifies a series of commands – ‘send a tweet’, ‘read a tweet’, and so forth – that everyone must use to interact with Twitter, including Twitter itself.
This API makes it possible for anyone to use Twitter for their own purposes. Major news organizations, like the New York Times, publicise their stories on Twitter: as a story goes live, computers at the Times use Twitter’s API to send out an automatically-generated tweet. Many systems now embed Twitter in their architecture – Apple’s own iOS, the operating system for its iPhones and iPads, has Twitter built into its basic components, so any iOS app can send tweets.
This open interface to Twitter created a lot of competition for the best interface to Twitter. In fact, there is no one right interface – different people and different industries have different needs. A profusion of interfaces means that everyone gets exactly the Twitter experience they can best benefit from. Twitter gets more users – half a billion and counting – without having to cater to the needs of each user – the users themselves see to that.
Twitter gets used in many applications its creators never envisaged. When a computer program experiences an error in its operations, it can send a Tweet to alert a human to the problem. Computers can even talk to one another, using Twitter as a sort of post office or central dispatcher. One individual even created a belt to be worn by heavily pregnant women – every time the baby kicks, the belt sends a tweet!
Interfaces greatly amplify the utility of any service. Twitter would still be a tiny messaging service, dwarfed by Facebook and ignored by everyone else, if not for the million and a half applications that use its API. Instead, Twitter has become an essential utility, used by journalists, politicians, and businesses around the world, precisely because of all of those applications. The firm’s success is built atop the efforts of hundreds of thousands of developers who used Twitter’s API to solve their own problems.
Imagine what might happen if Uber created an API to its service, encouraging others to use it in their own businesses. Anyone would be able to provide an on-demand limousine service. A nightclub might offer that service to tipsy patrons through a specially-branded app. A restaurant could add it into their reservations system, as could a hotel, or airline, or car rental company. As the opportunities to use Uber multiplied, Uber’s business would grow dramatically. Uber would become the default solution for transportation.
Interfaces benefit every hyperbusiness framework. Postmates has recently launched a San Francisco-based delivery service, ferrying items (generally restaurant and cafe orders, but it can be pretty much anything) from one point to another in less than an hour. The service is proving successful, but currently is only accessible through a smartphone app. (Sound familiar?) If Postmates offered an API, any business in San Francisco that wants to offer a delivery service could use that API to provide a delivery service for their customers. When that happens – and it surely will – Postmates will suddenly become the most obvious way to deliver something. Everyone will be doing it.
Product-oriented business also benefit from interfaces; in many cases there’s no reason to go through a human to order something. Amazon.com doesn’t have any human order-takers, but they’re now one of the largest retailers in the world. The interface is the new sales channel, whether you’re selling a product or a service. Now that markets are everywhere, aggregating everything, interfaces are the glue between frameworks and the people who want to participate in a market. Interfaces marry demand to opportunity, because an interface creates more possibilities for the market to become pervasively accessible – like Twitter.
This is the first law of hyperbusiness: Create an interface to your framework, or face irrelevance. People gravitate to the best interfaces: one of the reasons MySpace lost out to Facebook was that Facebook created a powerful API that fostered the creation of an ‘ecosystem’ of Facebook Apps. Using that API, companies like Zynga built themselves into huge businesses, within Facebook. MySpace did finally offer an API, but far too late, long after it had lost its commanding lead over Facebook. MySpace provided no space for anyone else, and hyperbusiness moved on.