Abstract/TLDR: The biggest opportunity for companies like Uber and Lyft is to expand their transportation services to third parties and diversify the type of objects they convey from one place to another. In doing so, the metaphor we use to describe these companies can shift from platforms to protocols. In short, these companies are building what I’m calling the IRL Transport Protocol, a system for routing packets (in the form of cars and bikes) and their contents from point to point.
This is a draft of a paper I recently submitted.
At this point, discussion of the “disruptive” nature of the “sharing economy” has become somewhat passé. AirBNB is up-ending the hotel industry by empowering renters and owners alike to extract economic value from their unused space. Taskrabbit gives people the ability to directly rent out their skills to others who demand them. One might even consider open-data initiatives from corporations (e.g. open APIs) and governments (like Data.gov) part of the “sharing economy,” insofar as the information they share fuels development of new platforms and innovative solutions to hairy organizational problems, from which these organizations benefit as the providers of these data. But, no sharing economy company has garnered such high levels of simultaneous love and vitriol as Uber, the company arguably leading a vanguard of ride-sharing platforms which include Lyft, Sidecar, and several others.
When we talk about the “rise of the sharing economy” what we’re really talking about is the development of web and mobile-enabled marketplaces. Not just any marketplaces, but platforms. Using a handy tripartite composition of platforms from Sangeet Paul Choudary (the linked post is worth a read) we understand that the keys to success in the development of sharing economy platforms are: building a robust network/market for goods and services, developing a strong technology infrastructure to deliver that product or service, and being able to gather and utilize data to iteratively improve the product or service and how it is provided.
Using this model, we see that companies like Uber (and we will continue using Uber as synecdoche for the rest of the ridesharing industry from here on out) function as platforms. Uber is a synchronous, location-aware spot market that connects things that need to move with a transportation layer to convey them to their desired location, just in time. Underlying its community of drivers and passengers is a technology infrastructure which serves to match drivers and those in need of transportation, and Uber uses data to improve its service and make it run more efficiently.
For emphasis, it’s worth pointing out that I refer to the things being conveyed from point A to point B are, well, just things. For now, ridesharing services are primarily for transporting people who need to be driven from one place to another, which is why we say that ridesharing services are “disrupting” the taxi industry – the historical antecedent to Uber and its peers, at least in the way these platforms are currently used. However, I argue that the real boom for Uber and other services will come when they onboard a sufficient supply of drivers that the aggregate demand from riders is met. (Thus meeting the demand for taxi-type services.) New drivers added to the city’s pool after this point could be contributing to “excess carrying capacity” of the system.
From an ecological perspective we understand that “carrying capacity” is the maximum population size for a given species in a particular, geographically-scoped ecosystem. Thinking about cities as ecosystems in which ridesharing services operate, we understand that there is a theoretical maximum number of drivers who can perform taxi-like services (as a function of demand for those services), but as we know, there are other kinds of drivers in a city. So, again, adding new drivers beyond the carrying capacity for taxi service providers creates a surplus of capacity to move things from one place to another within the ecosystem.
One possible way to solve this problem of excess carrying capacity is to simply create more demand for services to meet the system’s capacity. Alternately, they can make orthogonal moves into different service markets that still utilize drivers as a transportation platform. Ridesharing services can put this excess carrying capacity to work by, well, carrying things from one place to another. To make myself sufficiently clear here: I am suggesting that Uber and other ride-sharing companies should reframe their value propositions: they’re not just platforms for moving people, in the mode of taxis (or even public transit), they are generalized platforms for moving things from one place to another. Such a reframing expands the scope of what sufficient carrying capacity enables companies like Uber to accomplish.
Uber is building a digital mesh–a grid that goes over the cities. Once you have that grid running, in everyone’s pockets, there is a lot of potential for what you can build as a platform. Uber is in the empire-building phase.
This digital mesh is what I’m going to call the “In Real Life (IRL) Transport Protocol,” or the IRLTP. Thinking about the ridesharing platform as protocol creates abundant opportunities for metaphor. We can begin to think of cars as packets, the format of which is defined by the protocol (say, specifying the use of cars or vans instead of railways or drones), but the protocol itself is ultimately agnostic when it comes to the contents of the packet. So, at some point, Uber ought not to “care” what gets transported in cars within the network. And yet, Uber and their industry peers could continue use their current performance-tracking metrics, it’s just that the “rides” may be for books, furniture, packages, food, animals and other things, in addition to humans, in the same way we can measure network utilization on the Internet in terms of raw volume of data transmitted and number of nodes in the network.
The protocol metaphor is also useful to explain concepts like surge pricing as a kind of load balancing mechanism. Car-pooling functionality in UberPool and Lyft Line is, fundamentally, packet-level multiplexing, insofar as two or more discrete entities are carried within the same packet through the network. Other, more lofty, comparisons between ridesharing and protocols arise when discussing the prospect of autonomous cars and the current state of dynamic routing algorithms which take into account traffic conditions to take vehicles (or packets, to use the metaphor) from point to point.
However, putting lofty protocol metaphors aside for the time being, it might be useful to compare the potential trajectory of leaders in the ridesharing industry to what actually happened with the dominant player in the social networking sector. Since Facebook launched in 2004, its role has shifted from social networking service, to a platform, to the backbone for the social web.
It’s important to acknowledge that a company’s status as a service, platform and protocol are not mutually exclusive. In many ways, Facebook’s core service to end users has not changed in any profound way since the site first went online. The core functionality of its service – posting, commenting, liking, sharing pictures, etc – hasn’t meaningfully changed for end users since those features were first implemented. The design and experience of those features may have changed, but a photo shared by a person on Facebook in 2015 is very much like a photo shared in 2006. The public launch of the Facebook Platform in June, 2007 expanded the scope and scale of Facebook’s value proposition by giving developers the ability to integrate parts of Facebook’s core infrastructure, like the Social Graph, into their applications.
Recalling Choudary’s framework for understanding platforms, the release of Facebook Platform gave developers the opportunity to build applications for the Facebook community, using parts of Facebook’s data reserve to create social functionality on their applications, while relying on Facebook’s infrastructure to distribute their applications. The shift from service to platform placed Facebook one step closer to the center of controlling the social web, and allowed the company to benefit enormously from the applications built on Platform.
Whereas “platforms” enable developers to build applications on top of core technology infrastructure and data, “protocols” act as the medium through which things are passed. The first step in Facebook’s shift from platform to protocol could be identified in the release of Facebook Connect. The four core features of Connect – centralized authentication, real identity, friends access, and dynamic privacy settings – positioned Facebook as a central broker of personal data and social interaction on the Internet. However, Connect is just one side of Facebook’s protocol. Whereas Connect allowed developers to extract value from Facebook by extracting (or gaining access to) users data, the Open Graph Protocol turned that dynamic on its head by allowing developers to derive value from Facebook by integrating their own data into the Facebook core. This gave end users the ability to share events on integrated applications (like playing a song on Spotify, sharing a review on IMDB, etc.), thus using Facebook as a content distribution channel and generator of new business. Facebook benefits from OGP by being able to develop an incredibly detailed picture of what Facebook users are doing when they are not on Facebook. The third side of Facebook’s protocol strategy can be found in its Messenger application (which, as an aside, is in itself a service, platform and protocol). Messenger now can act as an intermediate layer between websites and the iOS and Android notification screens, and it gives developers the ability to exchange snippets of app content in Messenger, turning Messenger into a medium all its own. (For more on this, check out a16z partner Benedict Evans‘s amazing post on the state of mobile messaging.)
We have established the general arc that Facebook followed from being a service, to a platform provider, to acting as a protocol and underlying social layer to the modern consumer web. The question remains: in what ways can ride-sharing companies create the same kind of protocol-like status? What are the blocks between companies like Uber and Lyft becoming a transportation layer for real life? How do companies make the leap from platforms to protocols? Previously, we have discussed one factor hampering this evolution: insufficient carrying capacity of the system to divert drivers away from taxi-type service provision to the transportation of other things. There is, however, at least one other factor to consider.
Assuming that sufficient carrying capacity will be achieved by one or more players in the ride-sharing industry, the next biggest limiting factor is openness. Uber has an API that allows developers from partner companies to access parts of Uber’s core, but so far the functionality that is accessible to developers is limited to making requests for Uber drivers to pick up users from a particular location. There does not yet exist a generalized method to request a driver to a particular location or declare the type of object that needs to be moved, because there does not exist an object type besides “person(s)” on the general Uber platform. The information architecture of ridesharing platforms currently limits the scope of their use to being highly technical taxi services, not the generalized transport layer they could become. Until the means of making requests from the system is abstracted to account for other kinds of objects besides people, and requests can be triggered programmatically by other applications, the use case for ride sharing companies is limited to the status quo.
This is not to say that ride sharing companies have not experimented with branching out of the taxi business before. Uber has executed deliveries of things like ice cream and kittens as marketing stunts, but on a more serious note, the company also experimented with a limited rollout of a bike courier service called UberRUSH. In some markets, Uber has experimented with deliveries of everyday items like s’mores kits, shampoo, liquor, and trash bags (among other items) through UberESSENTIALS, presumably in an attempt to compete with on-demand delivery services Postmates and Instacart.
The most telling indication that the ridesharing industry’s leader is expanding into the merchant delivery market comes in the form of documents leaked to TechCrunch on April 28, 2015. Those documents contain a training manual for UberRUSH and some UberX drivers that details a new experiment: a partnership with high-end retailers to deliver packages from retail locations to online customers within an hour or two of order completion. The company has also conducted experiments food delivery (UberEATS, a service aimed squarely at restaurant food delivery, and UberFRESH, for delivering fresh produce and groceries) and an on-demand moving service called UberCARGO.
As TechCrunch’s Jordan Crook puts it:
It’s not hard to imagine Uber combining these verticals — fresh food, restaurant food, home goods, online purchase orders, and more — into a single logistics framework that is dispatched to its thousands of drivers and couriers. A driver could theoretically have Johnny’s pizza in the front seat, Jenny’s new Louis Vuitton bag in the trunk, and you in the backseat.
To conclude, we believe that ridesharing companies like Uber have much more potential as generalized transportation and same-day logistics providers. In order to reach this potential, our understanding of these companies core service has to be reframed, and the underlying technical infrastructure needs to be made sufficiently abstract to serve more use cases. Rather than viewing these companies as ride-sharing or taxi services, it serves us better to think of each company as an early-stage implementation of the IRL transport protocol. When analyzing the market of transportation providers, it is important to remember that most companies are still at the platform stage, but that a more generalized protocol for accessing transportation is on the horizon. Whether this protocol is controlled by one company, many companies, or becomes a more open and distributed standard is uncertain. Change like this does not come at the press of a button, no matter how companies wished that wasn’t the case.