Below I attempt to define and differentiate between these different types of companies and their products.
Infrastructure products are ones that multiple companies have to build over and over again. Eventually some smart entrepreneur realizes this and builds the common infrastructure product that other companies will pay to use. An example of this is the founders of Mailgun, who built versions of the same email server for multiple employers until they realized they could build this as a general service for all developers.
Infrastructure products are often necessary for a product to function (every ecommerce site needs Stripe for payments) but are not often a “strategic” differentiating buy for their customer (although Stripe has managed to differentiate strategically based on its fast iteration on new features and its simplicity as a product). Early on, many users of Twilio didn’t care if they were using Twilio or another telephony provider – they just want it to work quickly, simply, at a good price (which ultimately meant using Twilio due to its ease of use).
The best infrastructure companies have clear economies of scale or network effects. Twilio is probably able to negotiate better and better deals with carriers on pricing the more volume it aggregates from its customers. Similarly, large amounts of payment data can provide scale effects for fraud or risk management.
An infrastructure company’s success often boils down to a handful of factors:
-Ease of use and integration.
-Differentiated features or historical customer data. This helps you lock in your customer base.
-Economies of scale. This can lead to network effects on costs (pricing power of the infrastructure provider relative to its own suppliers) or features (fraud detection).
-Developers or sales channel. In some cases a developer ecosystem emerges around an infrastructure product (note: this is different from developers using or adopting a product). This is less common for infrastructure then people think, and is more common for a true “platform” (see below).
In rare cases, an infrastructure company can move up to become a “platform” in its own right. This only works if the infrastructure company is able to collect and re-position unique end user data, or build direct brand recognition with its customer’s customers. typically have more lock-in and differentiation then infrastructure, so moving in this direction if possible can be a strong strategic move.
A platform almost always grows out of an existing vertical product (e.g. Facebook, Twitter, etc.) and is ultimately a generalized extension of some aspects of that product (e.g. Facebook’s internal user graph / identity and Facebook Connect. The resulting platform allows third party developers to take advantage of the unique data, services, or userbase of the original vertical application.
A platform is not easily commoditizable. Only Facebook has the social graph that underlies it, or the ability to drive distribution of certain types of content to a billion users. If a developer tried to use another social product’s API (e.g. Foursquare) instead of Facebook’s, they would not get access to the right type of data or the same distribution. Alternatively, their own customers would not want to use the “Login with Viddy” button. In contrast, a company could probably swap one infrastructure product for another without a fundamental change to how its own application functions.
Almost always, a platform is valuable due to some unique characteristic of the original vertical product from which it grew. For example, Facebook Connect worked in part because Facebook itself was a representation of a person’s identity. It was natural for consumers to feel comfortable logging into other sites with their personal identity. Contrast this to federated approaches like OpenID, to which the user had no brand association. These types of “build it and they will come” approaches to platforms tend to fail (in reality, you are building infrastructure in this case, but calling it a platform, but with no user recognition or branding for your product which comes from being an actual platform).
A platform usually has the following characteristics:
-The vertical app the platform is based off of owns the ultimate “end user” directly.
–The core functionality and key features of the platform are derived from the vertical app that spawned it.
–Provides proprietary, non-commodity data and/or distribution to applications using it. The word proprietary here is key.
–In some cases, provides a monetization mechanism for apps on the platform and almost always takes a revenue share. (Contrast this to infrastructure, where the infrastructure provider is paid for use of its product).
Many entrepreneurs I know set out to build a “platform” without any real vertical application underlying it. In reality, they are building infrastructure. Most companies that confuse these two things tend to fail.
The key way to tell if your “platform” product will fail is if you need to build the first “killer app” for the platform yourself for your platform to succeed. In other words, you end up trying to build both a vertical application and a platform simultaneously.
3. Operating System (OS).
This is a pretty reasonable definition of an OS. In general, adoption of an OS is driven by the following:
-The hardware the OS is typically bundled with gets a lot of distribution.
-There exist (or quickly emerge) a small number of killer apps that differentiate the OS causing more distribution and adoption (e.g. spreadsheets and the early PC market).
-An app ecosystem emerges around the OS, which creates a positive feedback loop. The more users on an OS, the more people develop apps for it, the more valuable the OS becomes to users.
In general, OSs seem to follow two phases of adoption:
Phase 1: A combination of the hardware plus a small number of killer apps drive OS adoption. For the early PC operating systems this was largely spreadsheet applications like 1-2-3 and Excel.
Phase 2: Once the OS has strong adoption, the longer tail of apps is created by the developer ecosystem who want access to paying users. This locks in users or spreads OS use to a new set of consumers. After the spreadsheet word processing / desktop publishing and gaming helped to spread adoption and value of PCs.
One could argue that a platform is its own killer app first and foremost. For example, the killer app on the Facebook platform is really Facebook. Once Facebook got adoption for itself, other non-Facebook applications followed. This is the primary way a platform product has similarity to an OS.
The reason these distinctions are important is that the strategy for building a successful Platform is different from building a successful Infrastructure company. Many people confuse the two and pursue the wrong approach as a company.
Signs Your Infrastructure Company Is Off To A Bad Start
Many people call their infrastructure company a “platform” and decide that all they need to do is find a killer app as a customer to drive their own adoption (since the overall market they are gunning for is still hazy and unclear). This type of company is usually started by a non-market driven technologist, who thinks a new technology is really cool. Unfortunately, most of the companies that start off this way end up as small acquisitions at best.
The reason is three-fold:
1. The company is not starting off with a market problem. In the case of a company like Stripe or Twilio, the founders were trying to solve a problem other developers such as themselves faced over and over again.
2. The market may be too small.
3. The “killer app” you are seeking is where all the value in the industry comes from. If the killer app truly took off, it should be able to launch the true platform in the industry and drive you out of business. Unless you are a piece of infrastructure. In which case, where are your customers?
Defensibility and Lock-In: Uber and Lyft
Uber And Disruption
Who Cares If Its Been Tried Before?
The Road To $5 Billion Is A Long One
How To Win As Second Mover
End Of Silicon Valley