The Platform Matrix: Not All Platforms Are Created Equal
By: Sameer Singh
Tags: Venture Capital, Platform, Technology, Startup, Business

The Platform Matrix: Not All Platforms Are Created Equal

Image credit: Shutterstock

I have previously explained how network effects shape three broad types of tech businesses — marketplaces, interaction networks and data networks. In addition to these, there is one other type of business where network effects play a central role — platforms. Unfortunately, the tech and startup world has spent much of the past decade using the term “platform” to describe everything from operating systems to analytics tools, algorithms, APIs, etc. Quite plainly, if everything is a platform, then nothing is and the term loses all meaning. So let’s take a more granular look at what platforms really are, and then unpack how their network effects work.

What is a platform?

The most meaningful definition of a platform comes from none other than Bill Gates, the architect of one of the first true platform businesses.

“A platform is when the economic value of everybody that uses it, exceeds the value of the company that creates it” — Bill Gates (as relayed by Chamath Palapithiya)

Focusing on economic value to external participants automatically eliminates the vast majority of companies that call themselves platforms. For example, Tableau is a data visualization and analytics tool, but not a platform. However, Xbox, iOS, Android, Salesforce, Shopify, and even Roku are all platforms because they help third-party developers generate economic value on top of their businesses. In order to unlock this economic value, aspiring platforms need to have the following components:

Underlying product: Platforms are always built on top of an existing product with some standalone value. For example, iOS and Android were smartphone operating systems that had self-contained features (phone, text, web browser, etc.) even before developer activity took off. Development framework: One of the most basic requirements for any platform is that it must allow third-party developers to leverage the platform’s capabilities to create software products for platform users. Matching: Modern platforms create an avenue for developers to distribute apps and help platform users discover apps that meet their needs. Enabling discovery is especially important because platforms own the primary relationship with customers or users. Economic benefit: Finally, platforms provide economic benefits to developers and help them build, monetize, or enhance their businesses on top of the platform. These benefits can be either direct (earning revenue from the platform) or indirect (improving engagement or retention via the platform).

In summary, platforms combine an underlying product and the development capabilities of software frameworks with the matching and monetization functions of marketplaces.

Platform = Underlying Product + Development Capabilities + Marketplace

As a result, platforms have some similarities with marketplaces. For example, customer and developer fragmentation is critical for them to be viable. Also, platforms have cross-side network effects, i.e. the addition of each developer makes the platform more valuable for all users and vice versa. This feedback loop makes them more valuable as user and developer adoption grows.

Now that we understand the basics of platforms, let’s take a deeper look at how platform network effects work.

Scalability: Platform Focus

I previously evaluated the scalability of marketplaces based on the geographic range of their network effects, i.e. the maximum physical distance between demand and supply for interactions to take place. Marketplaces with cross-border network effects are significantly more scalable than hyperlocal ones because they can leverage a supplier in one region to attract demand in another. However, we cannot use this approach to compare the relative scalability of platforms because they are purely digital businesses, i.e. their network effects are almost always cross-border. The addition of a developer in one region makes the platform more valuable for users all over the world, and vice versa.

If platforms are cross-border by nature, their scaling potential should depend on their ability to organically expand into adjacent vertical markets or categories (not regions). In other words, scalability depends on the breadth of the platform’s standalone capabilities.

Take Xbox as an example — the underlying capabilities of the platform (processing power, graphics, controller) were designed for gaming. This focus and a growing base of game developers led to strong customer adoption, primarily from gamers. With the launch of the Xbox One, Microsoft attempted to expand this gaming platform to a larger market — home entertainment. However, media was a small minority of the platform’s value for its customer base. In addition, the Xbox One could not justify its price premium over competing streaming devices to non-gamers as its unique capabilities, and developer base did not appeal to that market. As a result, Xbox could not expand their market or gain market share against other dedicated streaming devices.

Game consoles and entertainment platforms like Roku are the clearest examples of focused platforms, but they are not the only ones. In recent years, there have been a number of specialized SaaS tools that have launched their own developer programs and app stores. This includes Slack, Zoom, Okta, and Zendesk. They still meet the definition of platforms, but their developer programs are largely restricted to the specific use case of the underlying product.

This means that the most scalable platforms are those that are multi-purpose, with capabilities that can enable a wide array of potential use cases.

Both iOS and Android (combined with Google Play) are great examples here. As smartphone operating systems, they have always enabled a wide variety of functions. For example, the first iPhone and the T-Mobile G1 (the first Android smartphone) both launched with roughly 15 pre-loaded apps, including YouTube and maps. As a result, they attracted customers who used them as multi-purpose platforms. This initial customer base, combined with a rapidly expanding collection of APIs then helped them attract developers across a range of different categories, from gaming to social media, e-commerce, health, finance, and so on. In other words, they leveraged their capabilities to enter adjacent categories and evolve from mobile computing platforms to general-purpose computing platforms.

Multi-purpose platforms are not limited to computing. SaaS tools like Salesforce and Shopify have become essential infrastructure for their customers’ operations and effectively act as operating systems for business. This allows them to create scalable, multi-purpose developer platforms as well.

Defensibility: Role of Developers

The defensibility of a marketplace is a function of how differentiated its supply is. Marketplaces with commoditized or interchangeable supply (like Uber) are less defensible, see higher multi-tenanting, and face more competition. Unfortunately, this framework is not directly applicable here either because all platforms have varying degrees of differentiated supply. Users look for apps that meet specific and varied needs, and they cannot automatically be substituted for one another. However, platforms are still vulnerable to competition and multi-tenanting, i.e. developers can use more than one platform. The scale of this risk depends on the importance of the platform to a developer’s business.

Take Slack for example. Slack’s app directory includes a range of apps that customers can use to improve their experience. However, the vast majority of popular apps are not actually “native”, i.e. built on top of Slack from scratch. Rather, they are “connections” or “integrations” to pre-existing apps.

The motivation for these developers is to make it easier for customers to use their apps in any context, i.e. improving their UX. For example, Asana is one of the most popular Slack integrations and allows users to convert Slack messages into tasks on Asana or link Asana projects to specific Slack channels. This makes it much more convenient for both Asana and Slack customers. However, this also means that developers are motivated to integrate their apps with any product that their customers use frequently. In addition, the platform is not a necessity for their app to exist and it is relatively simple to extend “connections” to other platforms. This leads to extensive multi-tenanting. For example, Asana is also available on Microsoft Teams, Hangouts Chat, Glip, and Flock. And, of course, connectors like Zapier enable integration with even more collaboration tools.

In addition, “long tail” developers are less important since integrations are meant to complement the use case of the underlying product (and not create new use cases). As a result, competing platforms only need to have integrations with the most popular apps to create a “good enough” alternative. This isn’t to say that these integrations don’t create some switching costs — customers would need to set up all of their integrations again if they switch platforms. However, the wide availability of popular integrations reduces barriers to switching and weakens defensibility. Both Slack and Zoom rely on “connections” or “integrations” rather than native apps. Luckily, Slack has other forms of network effects that insulate it against competition. Unfortunately, Zoom does not.

In contrast, Salesforce is an example of a platform that skews towards native apps over integrations. Salesforce acts as a single source of truth recording data about customer interactions and business operations. Developers leverage its capabilities and recorded data to build new, native apps that extend the functionality of the platform.

The motivation for developers here is to target new market opportunities and acquire new customers. Take Vlocity for example — it built a billion-dollar business by creating customized, industry-specific solutions on top of Salesforce. This extended the use cases of Salesforce’s platform to areas as diverse as claims management in insurance and subscriber management in media streaming. Crucially, it was exclusively built on Salesforce. Vlocity would need to rebuild their application from scratch if they wanted to reach customers using another CRM. This acts as a barrier to multi-tenanting and limits competition.

Clearly, “long tail” developers are exceptionally important here because the whole point of these developer programs is to create functionality that the platform cannot build itself. As a result, competitors need to match the scale of the incumbent platform to provide a comparable experience. This makes network effects exceptionally strong, with first movers locking out later competition. For example, iOS and Android were first to create network effects between developers and smartphone users, which doomed late movers like Windows Phone. While there is extensive multi-tenanting between iOS and Android, this is because they were both essentially first movers targeting different market segments — Android’s modular approach allowed it to penetrate markets that iOS simply could not reach.

The Platform Matrix: Extreme Outcomes

As we have done previously, we can now plot defensibility and scalability against each other to create a framework for evaluating platform network effects. This shows a remarkable pattern that is effectively an inverse of the catch-22 we saw with data network effects. The majority of platforms are either both scalable and defensible, or neither.

The cause of this pattern is simple. Multi-purpose platforms create more opportunities for developers to discover new use cases, which leads to a larger market for native apps. This also creates exceptionally strong and defensible network effects as the value of the platform continues to grow with user and developer adoption. This is not only true for iOS, Android, and Salesforce, but also for Shopify, WeChat’s Mini Programs, and even Atlassian.

On the other hand, the limited capabilities of focused platforms restrict new market opportunities and constrain native app development. These platforms have significantly weaker network effects but do create some switching costs. On the flip side, they are much easier to build because the use cases and complements already exist. Roku, Zendesk, Okta, RingCentral fall into this category in addition to Slack and Zoom.

Building a platform is rarely a near-term option for early-stage startups because attracting third-party developers requires some level of scale. However, by the time that scale is achieved, it is too late to choose the type of platform you want to build. At that point, the capabilities of the underlying product are already defined. If building a platform is the eventual goal, its desired capabilities need to be the core philosophy guiding your long-term product roadmap right from the start.