Platforms and Experiences

8 min read

All software is either an experience or a platform. Experiences are built on top of platforms. There are a small number of truly viable platforms but tens of thousands of experiences. Platforms are somewhat synonymous with Operating Systems while experiences are synonymous with applications. I say somewhat since there are platforms that are not OSes (e.g. Stripe) and experiences that are not applications in the app store sense (e.g. a web site).

It helps to set some definitions for the words "platform" and "experiences".

I’ve always liked Bill Gates’ definition of a platform.

“A platform is when the economic value of everybody that uses it, exceeds the value of the company that creates it. Then it's a platform.”

Platforms seek to create economic value for the people who build on them and the people who use them. The platform then takes a slice of that value as revenue. Platforms seek rents from the people who build on top of them.

Experiences, on the other hand, create and capture value much more directly from the people who use their products. Typically, they succeed by directly charging for the product or service (e.g. buy and download a game) or by aggregating enough people in the experience to sell advertising.

Experiences are built on top of platforms. In the simplest example, Operating Systems are platforms and applications are experiences. Some experiences try to build platforms inside them but very few are true platforms. Just because you have an API or SDK doesn't instantly make you a platform. You need the economic condition of creating more value than you take from the participants.

Because platforms only capture a subset of the value they create, they are incentivized to pursue things at scale (serve as broad a market as possible). The more people who use and build for the platform, the larger the total economic value and therefore the larger the revenue that can be reaped by the platform.

These economics mean that platforms should always focus on building features for the widest audience possible. When deciding what features to build into a platform it's most helpful to focus on features that benefit the P50 person… the most average person the platform is serving.

Experiences, on the other hand, create value in specific segments of the platform. They do this by finding unmet needs that the platform has no incentive to build for specifically, but wants to support broadly.

While platforms focus on the P50, they allow experiences to build for the P50+/-1 participants in the platform. What I mean but this is the most sophisticated (p99) and least sophisticated (p10) people on the platform.

In new platforms developers build for the most sophisticated users of the platform. This is because new platforms only attract early adopters.

New platforms often don't have all the features these people want so developers step in to build these features. The early adopters are willing to pay for this value not well created by the platform.

For example, in the early days of Apple's transition to OSX there were third party "Finder" replacements you could install. For some users, the Finder just wasn't powerful enough or lacked the features they wanted. Developers stepped in to meet the needs of this P90 customer. Over time the platform's native Finder got many of these features and you don't see as much demand for Finder replacements.

Platforms must always build for the P50. Since markets aren’t static, and technology commoditizes over time, the maturity of users is constantly evolving. Since new platforms attract early adopters the P50 of its first users is the P99 of the general public.

We saw this with VR. The earliest users of VR were the most demanding gamers and VR zealots. Even the most average user of the Oculus DK1 or Rift was not the average consumer.

It is easy to get trapped here, held hostage by your first users. User and market research can create a distortion since asking these people what features they want will cause teams to pursue even more advanced features. This will limit the growth of the platform since it optimizes for the P99 which is a small segment of the overall market.

As platforms mature they consume features that were once the domain of third party experiences. This feels unfair to developers who wake up one day to find their software's use case is now natively part of the platform. This effectively puts them out of business.

But this should be expected. As the platform matures it must continually build for that average user.

It is a tricky dance. If developers pick use cases near the P50, they benefit from serving the largest number of users but are at risk of being in the direct line of the platform's roadmap. They can also be a victim of their own success. If they build an experience that was intended for P90 users only to have it become popular they effectively drive the use case into the P50 now making it ripe to be consumed by the platform.

There are two lessons for Designers here.

1) If you are building a Platform it is a common trap to design features that are appealing to the very demanding user (P95). This is natural, since many of the people building the platform are in that segment. They see value in these features and it seems logical to build them. Teams are also swayed by loud voices in the early adopter communities that demand the most sophisticated features.

2) Make sure there is a good delineation of what the Platform should offer and what Experiences should provide. Whenever possible have the platform provide enabling functions and let experiences fill in the rest. Find features that benefit the largest number of people and put those in the platform. For example, the print function. It would be terrible if every application had to build its own "print" feature. It is much better for the platform to offer it natively..

Platforms need to relentlessly pursue the P50 while experiences need to work on either side of that. If an experience gets consumed by the platform it just means value needs to be created elsewhere in the system.

Coda

My favorite example of how platforms and experiences co-exist and evolve is AirFoil by Rogue Ameoba AirFoil lets you send audio over Wifi from one computer to another. When it was released, only the most sophisticated people had this need. You needed to have multiple computers with one connected to a stereo, a WiFi network in your home, and some knowledge of audio routing.

Over time, this became a more common need, and Apple built it into the platform as AirPlay. Airplay eventually added video along with audio. This streaming feature is now available to all developers to use and creates tremendous value in the platform. Apps like Spotify or YouTube benefit from being able to get their content to other devices without the friction of having to download another app or building the feature in the application layer.

AirFoil still exists, offering a complex set of audio routing (but not video) features that only the most advanced users need. They focus on things that AirPlay doesn’t offer.