208. Ultimate Guide to Platforms

Patterns and Practices in the Creation, Rise, and Fall of Platforms

The brass ring of product development is to create a platform. I say brass ring because by and large creating a platform is elusive for most products, at least at the scale we tend to think of when we think of platforms (Windows, iPhone, AdWords, and so on). In reality when, we look around there are tons of examples of platforms that deliver massive economics and powerful gains for those that bet on the platforms as customers and third parties.

While we all want to create a technology platform, we lack a common taxonomy or definitions. Once we have that definition, we can also look at the patterns that lead to the rise and fall of platforms.

The organization of this essay is as follows:

• What is a Technology Platform?

  • A note on economics…

• Models of Platforms

  • A note on stickiness/switching costs…

• Why do platforms fail at launch?

  • A note on failing to consider all the 4 Ps…

• Why do platforms succeed?

  • A note on platform moats…

• The Platform Lifecycle

What is a Technology Platform?

The simplest definition of a platform is a technology that serves as an ingredient for the success of others but is so important that it achieves recognition and a market position on its own. The market position is such that there are many attempting to offer the same complete product or service, but the platform defines the not-so-secret ingredient upon which most, or even all, of the end-products or services rely.

Limiting the discussion to relatively modern business, one of the earliest examples of a platform strategy was undertaken at General Motors (GM) with the advent of automobile product lines. Within GM in the 1950s and later, what started out as efficiency in supply chain procurement turned into a go-to market strategy. By relying on common assemblies and other subsystems of cars while differentiating on branding and option choices, GM created the illusion of serving many more customers with cars uniquely tuned to specific customer segments. This eventually led to separate businesses based on a common platform, for example the Camaro, Firebird, and Trans-Am were very different customers for mostly the same car. An eye-opening list of just how far this platform strategy went can be found on the list of GM platforms.

Deliberately platformizing (my word) an existing product and attempting to reuse it over and over again is something that incumbents do once they achieve success. OREO cookies or Hershey chocolate appear in a dozen different aisles in supermarkets. Clorox bleach-based products fill an entire aisle. In toys and entertainment, from Barbie to Star Wars we have seen these platforms expand. Thus, the Disney Corporation today is one of the great executors of a platform strategy.

Historically in software, Windows attempted this strategy with a notion of the Win32 API serving as the basis for the strategy. As did Java, with the virtual machine at the core of an expansive platform. Both of these serve as cautionary tales when it comes to a deliberate expansion of a platform strategy.

An example of an infamous Microsoft slide used over decades, “Windows Scalability” that shows the Windows platform going from mobile all the way to server clusters. At one point this diagram included phones, handhelds, even the Wallet PC, as well as high performance scientific computing. (Source: personal)

While those behind strategies above are lauded, it is hard to escape how much of the success is execution compared to creation. The most interesting platforms emerged not from the deliberate expansion by an incumbent or even building a product with the explicit desire to be a platform. Rather the biggest and most successful platforms simply started out as trying to solve a problem.

The key is that the solution was obvious to at least a small set of people and it delivered an immediate win. This small set of people are not always what we think of as builders or software developers but are simply users.

Perhaps the most ubiquitous modern productivity tool is the spreadsheet which at first did not seem to be a platform but was “just an app” or even a “killer app [for a platform]” but definitely not a platform itself. Over time spreadsheets added programmable macros and even very complex add-in architectures requiring professional programming, but compared to just using a spreadsheet these tasks did not dominate. Still, the spreadsheet is a platform. It serves as a foundational ingredient for the whole of finance, consulting, science, and more broadly analysis, not to mention tracking everything in most every job category. Today, people engineer work processes around spreadsheets baking them into final goods and services.

Sometimes a platform emerges from an internal technology like the ones created by GM to become a new platform on its own. Adobe PDF represents a journey to ubiquity. In the earliest days, PDF was derived from Adobe’s own PostScript format to be a platform for publishers to use. Faced with the challenge of “converting” any variety of native formats to this format, the idea of printing to PDF ended up creating a universal document viewing format. In 2008, Adobe offered an open standard for the format solidifying its ubiquity albeit giving up much of the monetization. Today, PDF is an essential part of the workflow for nearly every official transaction and serves as the foundation for paperless signatures in nearly every work process. It is a platform without massive platform economics. Another lesson.

The web, HTTP and HTML and associated technologies, serve as the canonical example of a platform open and free from the start. It should also serve as an example of a platform taking on vastly more use cases or scenarios than when first envisioned as a way to share documents online. Much like the core internet technologies upon which it is based (namely TCP/IP, DNS, etc.) the ability for web technologies to scale and morph to support ever more and create the platform of our age is truly remarkable. There is a great lesson in this platform on the importance of architectural principles that underly robust and durable technology platforms. The Unix operating serves as another example of architectural choices for a platform that have endured.

With so many unique examples it becomes increasingly difficult to classify them. A most interesting thing is we remember platforms as well-defined and intentional entities and often attribute their success to a platform strategy. But often a platform strategy is one that emerged organically seeing how products are used or is the result of a very tight retroactive construction. Most successful platforms begin life as one set of scenarios and that success leads to using the technology for tasks that even the originators did not envision. While that is taking place the influence of competitors and introduction of new technologies nudge and bump the platform in directions not originally intended as well. In fact, that very evolution is an essential element of most successful platforms.

Thus, any description of a single platform works only for a point in time. The evolution and management of the platform becomes even more critical than the original designs and model.

A note on economics…

A hallmark of a platform is that economically it is a form of a two-sided market (for more on the topic, this Jeff Jordan interview is a good listen). A platform brings together buyers and sellers (developers and users, etc.) and acts as some form of intermediary.

Sometimes this is only within a company, as with the GM example. More materially a platform brings together different parts of a value chain. Most frequently, a platform offers a clearing house for value where it provides distribution and then packages up one side of the market to be consumed by the other side. The ad markets of Google and Facebook are platforms in this manner. These platforms expand horizontally by adding more and more features that increase distribution and consumption with a big upside for both consumers and advertisers. This positive reinforcement cycle of more consumers draws more advertisers draws more ability to invest in what draws consumers is a key element of these products, though it does not necessarily preclude competitors as we see with Facebook and Google and their duopoly situation.

In the case of Windows, the platform brought together parties both horizontally and vertically. We typically think of Windows as a platform for developers to build apps which then move further up the value chain reaching customers. Windows also reached down the value chain to component makers for PCs, working with them tirelessly to improve what they sell to PC makers further up the chain. Windows also works with many parties that effectively extend Windows horizontally by adding capabilities to the Windows experience. These companies might look like apps or hardware, that is until Microsoft chooses to implement those capabilities in Windows (or Office) itself. This combination of both a vertical and horizontal marketplace creates an external flywheel that amplifies the economics of the platform. The more the platform expands the more people want to join it. Bill Gates has been quoted as saying “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.” While this captures a wonderful ideal, it does not capture the inherent fragility of the full ecosystem when these economics were not the case, as was true for almost the entirety of Windows after version 3.0 as we will see. Historically, Windows ultimately captured most of the profits of the platform, not the partners—something arguably true today with Apple iPhone and some aspects of advertising.

Models of platforms

When designing a platform, even though most arise organically, it is critical to have a clear view of the model. While models are always evolving and a new technology can have the appearance of creating a new (and bigger than ever) platform, the evolution of that technology will tend to quickly converge on using one or more aspects of the following taxonomy:

• Application Programming Interface (API)

• User Experience (UX)

• App as platform

• Data Storage platform

• Horizontal v. Vertical platforms

• Plugins, Add-ins, and Extensibility mechanisms (customization)

• Connectors and Integrations

• App stores

• Marketplaces and Networks

• Open Source

In each case below, the most unifying characteristic is that the primary user of the platform will over time consider that platform their job, not just a thing to call on but quite literally their job. For example, many in marketing spend all of their time on demand generation thinking of Google and Facebook. Certainly, most developers at one time thought of themselves as Windows developers. Many businesses think entirely about Shopify as distribution, and so on.

The descriptions below also include some of the structural challenges that generally define the ongoing struggle of a particular platform model.

My intent here is not to define a complete taxonomy but to offer a series of platform types that encompass most products in the breadth market. While I would not assert this list is complete, I’d suggest that most platforms have a dominant element of one of these.

API. APIs are in many ways the original post-mainframe technology platform (FWIW, a programming language was by many accounts the primary platform of mainframes for a long time). APIs are aimed at developers primarily. There are however many APIs that are inadvertently used by non-professional developers. The no-code movement in a sense hides the API from the user though the resulting ecosystem is API-based.

Stewardship of an API platform over time is among the most difficult challenges in platform product development. When you offer an API, you are effectively offering a view on your implementation. Thus, changing the implementation over time means you’re held to the old architecture directly or indirectly. It is why many API companies build up massive redundancies or “n ways of doing the same thing”. The world of database and data access is almost comical in the evolution of APIs where routinely companies unveil a new API that is an attempt to clean things up but invariably just introduces a new “n+1” API. APIs can become especially vulnerable to competition from platforms who offer developers a “just good enough” solution and focus efforts working across multiple underlying operating platforms such as clouds or devices while offering a service that doesn’t exist on the operating platform.

APIs that exist entirely to provide abstractions of the underlying system, aka middleware, erode for the above typical API challenges but suffer from two other fragilities as well. First, these APIs provide a model to programmers independent of the underlying system. This works fairly well until the underlying system diverges in such a manner as to make it difficult to impossible to expose the capabilities of the that system. In fact, most platforms go out of their way to make it difficult for middleware to continue to exist on top of those platforms. Second, these platforms often necessarily abstract multiple underlying platforms (e.g., cross platform libraries). They will suffer from the preceding problem but in an n-way manner, creating impossible levels of complexity in their implementations.

That is why the more defensible API platforms provide a unique combination of breadth of capability while hiding some enormous complexity that no one wants to worry about. No one who just wants to collect money from the internet could hope to understand international taxation the way Stripe is able to, at least until some significant scale. When Windows emerged as an operating system, it was the diversity of printers and video subsystems that used to be a problem for every MS-DOS developer that simply became no problem at all for developers. In both cases, the API also replaced what some companies used to think of as intellectual property or an operating asset.

The most successful APIs broaden in scope to the point where an engineer spends most of their coding time working that API and the whole of the system grows. In effect, for that engineer the API is the abstraction that defines their job.

User Experience (UX). At the other end of the complexity spectrum exists the User Experience that becomes a platform. We do not often think about the experience aspects of a platform because they seem so much easier or more fluid but in practice developing a novel user experience as part of solving an important problem can result in platform dynamics and economics for end-users rather than engineers.

For the UX to take on platform dynamics it must also embody a set of capabilities that are difficult to impossible to copy. It is for this reason that some believe the UX can be viewed as a secondary cause for the success of a platform. Is Excel the wildly dominant spreadsheet because of the user interface or because of the vast array of capabilities that in total constitute the real platform? The same could be said of social networks where the small number of mechanisms for the UX are integral parts of the underlying dynamics of a network, onboarding, algorithmic feeds, and recommendation engines.

From a competitive perspective the best answer is it is all of these. The primary reason that direct cloning generally does not work when it comes to user interface is because it is the sum total of the whole UX that matters. Perhaps no products have been attacked for so long as Windows versus Linux or Office versus “clones” yet neither of those ever really made an appreciable dent in the end-user market. The practical issue remained that the clones might have had a UX that imitated but never duplicated the complete product experience.

The biggest winners economically in UX as a platform have been the mass market productivity tools from Microsoft, Adobe, Autodesk, and so on. Each of the companies created a rich experience combined with novel capabilities that came to define the platform for various professions. We’ve also seen recently how an entire experience can indeed upend these very strong platform dynamics such as how Figma upended the design profession. In software, no platform however dominant is afforded a permanent position.

By far the biggest challenge in maintaining a UX platform is how the customer base is so difficult to move to new experiences. When you think of finance people using Excel, consultants and educators using PowerPoint, or lawyers using Word, none of those conjure up images of people looking to acquire the latest and greatest product features to simplify their work if it means re-learning everything they did before. Transitions like the Office Ribbon or even the move to browser-based tools are few and far between in tools where the UX is the platform. Figma is an example where it took an entirely new product and new way of addressing the space to change the market.

One of the most significant challenges in platform technology is taking something that is an app UX platform and “opening it up” to become an API platform. Many apps go through a lifecycle where they first gain traction as an app or even a point solution. Then they gradually open up the app to enable plugins, connectors, or other customizations (see below). Finally, they have enough feedback from large technical adopters that they would like to tap into the magic of the backend, engine, or runtime of the app and build their own app experience treating your app as a block of reusable code. This almost never works, as appealing as it might be.

There are a number of challenges in this lifecycle stage. First, no matter how well a product might be architected from the start if you’re building a user experience first two truisms exist. First the UX itself probably pokes into the abstractions in unpredictable places, just in the crush to get the product working. Second, without the UX in place it becomes impossible to maintain the integrity of the data as you quickly learn how much of the integrity tier was developed or enforced in the UX. These are both solvable with time and rearchitecture all while most engineers on the backend or runtime are cursing the frontend team for violating the abstractions. This leaves the app/plaform in a bind which is the developers want complete control but the business wants to keep the brand and full capabilities of the product front and center.

Second, the economics of the platform will quickly fail. A customer or third party that builds an entire experience on top of the backend of a platform—one that cannot run with the standard frontend of the product—will be unwilling to pay the full price per user for every user of their system. Third parties will almost never want to bet on a platform if they know their COGS will also include a full-price license to a product. This generally leads to all kinds of arbitrage engineering efforts. Historically this plagued the earliest category of platform tools in PC computing, the desktop database. No one could figure out the best way to monetize a desktop database that was used primarily for the database engine and not the product UX. SAP and then Salesforce experienced this same dynamic as customers developed solutions that worked against the data—the customer generated data—but did not require a license for each user. Both companies ultimately changed their licensing but by then had amassed a significant UX and reworked the platform to provide the infrastructure to avoid the integrity problems described above.

App as platform. Some apps become platforms almost in spite of not having either a novel user experience or even end-users (versus IT) deciding to acquire and use a product. Business processes, particularly in medium to giant enterprises, often become platforms and exhibit economic returns as platforms simply by solving a business problem so well the products end up defining that process. From mundane tasks such as expense reporting to strategic processes such as staffing and budgeting, to mission critical work such as supply chain products put in place to run these processes are platforms for companies.

No product came to exemplify this more than the rise of SAP at companies such as Walmart, Apple, BMW, and more. Most today might not believe the cost and effort that went into “deploying” SAP but for most customers it involved several years and cost in the tens to hundreds of millions of dollars. When Walmart replaced in-house systems with SAP, the deal was signed in 2007 and the first parts of the deployment went into operation 3 years later!

In more modern times, Salesforce exhibits this same progression. Deploying the tool is as much an entire company process restructuring as it is acquiring a software product.

Apps that are platforms often attain their platform status by virtue of customizations and ability to mold the app to existing data and processes over the long course of deployment. These app features develop over many years of winning customers and deployments and result in enormously sticky to impenetrable fortresses of value. Over time every aspect of a business touches these platforms and a business itself essentially rides on top of the platform. Whole job functions are defined by what the tools are capable of and what information can be input to and extracted from the tool. Winning a sales with a platform this way is a win for a decade or more. Winning also means the ability to change the product dramatically is all but eliminated.

Most people first observe the immense value and trust customers place in these types of platforms when they try to sell against them and then soon realize the best approach is to sell with them.

As with API platforms, all the strengths of an app platform turn into weaknesses in times of major technology shifts. As businesses became more connected to their supply chain, SAP had to respond with more APIs and connections between different installations so that the supply chain could be fully automated. These connections were the hallmark of the Walmart installation (though not invented there). SAP itself has found it to be challenging to move to a cloud model for many customers. For many years, Oracle bemoaned the customizations of on-prem software as preventing the migration to cloud. Only now, however, most cloud installations have the customization capabilities—though implemented differently than providing database access as SAP did.

Data storage platform. Historically, the earliest and most hardcore platforms were data storage products. Data storage as a platform has multi-sided benefits in that it is a platform for both the end-customer and the developer. SAP for many years drove the largest in size and dollar value of Oracle customers until eventually building its own data storage layer.

Many enterprise customers and developers feel so strongly about the data storage platform that they will begin projects or product acquisition discussions by first fixing the data storage layer. In the old days of private data centers this was because the cost of acquiring and managing data storage technology scaled better with only a single vendor. As a result, Oracle achieved a platform level of economics by simply being the standard and every new product was required to play well with the data center and data ops employees of a company. We see this today with many enterprises specifying which cloud they insist all the products they purchase use, even though that might seem to be a hidden implementation deal to most vendors.

The role of the “raw” data storage platform has taken a bit of a backseat in the world of cloud/SaaS where now the focus has shifted to being able to bring together all the data used by all the different tools in an organization. With this we have seen a resurgence in data platforms at a higher level of functionality than block storage or SQL.

The platform nature of data storage comes from being the single source of truth in a company—the actual transaction data that matters. With the change in economics of storage and rise of the cloud we have started to see shifts in how the transactions themselves can be moved to different data platforms. These new platforms, like Databricks and Snowflake, have attributes of traditional transactional backends combined with the capabilities for analysis and reporting that used to be considered separate products running “on top” of the strategic database. In other words, the source of truth is starting to move. As the source of truth moves the platform leverage and economics move with it.

Horizontal v. Vertical platforms. We’ve seen how some platforms can serve both developers and end-users from within one product. This is a specific case of serving as both a vertically-oriented platform and a horizontally-oriented platform. Some products are platforms to a range of partners that fill-in or integrate with on the sides of a main product while also becoming critical to the workflow of the paying customer at the top of the product.

Data platforms are rich in this regard. As much as many modern SaaS apps try to avoid relying heavily on specific implementations within the cloud, preferring to use low level block storage for example, the replication and geohosting capabilities of the cloud platforms are key elements of how the cloud providers become more than base infrastructure. Tools for managing data for security, backup, compliance of all sorts as well as moving data between tools (ETL or data movement such as Fivetran) are themselves platforms in every sense of the word while they also use the platforms of the tools they work with.

Vertical platforms provide additional platform capabilities on top of existing products, and then become platforms themselves. Marketing automation, data analysis, and customer experience are examples of categories that are deployed on top of existing platforms (for example shopping) while also providing complete experiences for the professionals in those spaces to act on the data and interactions those tools track.

Such platforms provide critical capabilities to customers, yet at the same time they often compete directly with the platforms they serve. They are also beholden to the mechanism and capabilities of the platform(s) they connect to. From a customer acquisition perspective, the product needs to match both a customer’s underlying platform and the required process integration. More often than not, the largest platforms one wishes to connect to (as the provider or customer) are the least reliable or even hospitable to products that integrate both horizontally and vertically, so caution and fragility exist.

Plugins, Add-ins, and Extensibility mechanisms (customization). If there is one conversation I have with respect to platforms more than any other, it is about the topic of plugins, or the lighter weight implementation called customizations. The enthusiasm comes from a couple of places.

First, plugins seem like an easy quick win. Early users are always asking for minor tweaks or simple (even obvious) features so it seems easy enough. Even if it is well-known that a product will later add a feature it seems advantageous to begin the platformization early with quick wins. Often the early adopters or tech-savvy power users will also be the customers/users that most value little tweaks to a product that plugins often provide. It feels good to grow the community around a new product this way.

Second, plugins are often specifically designed to be super easy to create. Many of the newest and most exciting products quickly introduce a plugin architecture often with much fanfare. The product soon takes on the meme of a platform, even if most of this platform effort was trivial to do and often does a trivial amount of work.

Third, most of all plugins have the characteristic of being able to offload work that is necessary to a third party. This could be just to get to market quickly, or it can also serve to isolate gnarly intellectual property or licensing issues. Most media editing tools have a plugin architecture for dealing with various formats, enabling open-source tools to avoid dealing with MPEG licensing for example.

The plugin-heavy worlds of developer tools (going back to Emacs up to today’s VSCode), Chrome, or Photoshop can lead one to believe plugins are more strategic or a bigger win than they turn out to be in practice. The difficult reality is that plugins generate a good deal more heat than fire and it is difficult to find a platform that one claims is either successful because of or remains strategically sound due mostly to plugins. That is specifically not saying plugins aren’t appreciated, just that they generally are not causal to platform success. There are several factors that generally limit the strategic value of plugins.

• Easy. Plugins are by design easy to create. When something is easy to create it means the investment is very low and also means there is a limit to the capability. Conversely, many new products, especially at big companies, attempt to amp up their platform-worthiness by lining up a large number of plugins trivially executed. Such effort makes for a great press release but a messy platform as interest in minimal functionality wanes, discoverability by end-users is difficult, and developers abandon the plugins. Amazon Alexa and Apple Watch come to mind. I believe the OpenAI plugins will prove to be about as durable as Alexa skills.

• API. The plugin API is almost always very limited in scope by design. Generally speaking, plugins are designed to make it easy and fast for others to integrate and as such the surface area of the product exposed through the plugin API is minimal, mostly limited to a simple UI integration and access to some elements of data. A limited API means that minimal capabilities can be exposed and more importantly there are likely ways to accomplish this work via traditional (and more secure, predictable, reliable) methods.

• Fragile. Even though the API is often quite limited, plugins are often fragile with respect to durability over time. They often come to rely on implementation details of the enclosing application or “hacks” to enable more access to data or user interface than the API was designed to allow. As such they tend to break with significant updates to the app. Since they were often rushed to release or not a significant part of the economics, they are fixed rather slowly.

There are a few places where plugins solve genuinely hard problems and often lead to advanced and sticky “solutions”. Excel has long supported plugins that originally support to C++ and now there’s a full JavaScript framework. These provide deep connections to Excel data types and UI control. Adobe plugins for visual effects have long been a thriving ecosystem of specialized tools for photos and videos.

It probably isn’t enough to bet that a plugin platform strategy will lead to securing platform level economics or a durable strategic value.

Alexa skills were a huge fad at CES for about two years. This is a booth from the Automobile/Transportation part of the exhibits showing off all the skills built into cars—a lot more demonstration of momentum than actual shipping or usage.

There are not many examples of time-durable plugin architectures that also served to build a unique platform advantage. There are many examples of a blizzard of press releases touting momentum of plugins, but rarely do they tout the usage of those plugins. Over time the cruft in the store/library of plugins almost always exceeds the value.

Connectors and Integrations. Connectors and integrations are specific variants of data storage or middleware platforms that primarily exist in enterprise software/SaaS. As the name implies, these exist to connect one product to another. Connectors and integrations are both consumed within a product and offered up as a platform element. While they can be a strategic platform element when a product has a large market footprint and others are doing the work to integrate with or connect to, for the most part SaaS products rely on connectors and integrations to complete their product.

Some of the most successful and broadly deployed SaaS products bootstrapped themselves as platforms for connectors and integrations. Okta is a fantastic example of an end-run around the legacy on-prem directory service by building a platform of sign-on integrations with thousands of other SaaS (and legacy) products and then elevated that capability to a complete identity platform.

Integrations tend to rely on capabilities to access the data of another program, either to add data (such as pushing data from email or messaging to salesforce) or to extract data (such as moving support tickets requiring follow-up from Zendesk to Jira).

A diagram from pandium of the 15 largest SaaS companies (according to SaaStr) and how many integrations and extensions each has. (Source: https://www.pandium.com/blogs/integrations-at-the-15-largest-saas-companies)

Integrations have a unique challenge in that implied in the integration is the ability to provide the full or required user experience to deal with data validation and all possible values. Most platforms that provide an integration API also frequently update their own UX, sometimes the API lags or does not fully implement a new UX. What is sometimes called a natural tension exists where the most successful SaaS products prefer to be the sink for integration, meaning data flows to then, but are not always the best or more reliable sources for information. At the same time, most newer SaaS products hope to extract more information from the existing platform winners. In addition, from a customer perspective with thousands of potential SaaS products, there’s almost always one integration or connector missing for every customer.

In the consumer space, connectors and integrations are seen with device and accessory platforms such as Google Home and Apple HomeKit or with standards such as the new Matter. As any user of these knows, the potential and promise of integration is generally bolder and more reliable than the features one gets with the shipping product.

Products that rely on connectors and integrations, whether as consumers or hoping to be a producer as a platform, often end up implementing the most important third-party connections themselves. Early in the life of a connector-based product, it becomes pretty clear that few other SaaS companies will do the work to integrate no matter how light weight or even beneficial it might be. It goes without saying, but the largest and most established companies never provide “private API” access or any proprietary connection for a substantial period of time. They will receive too much pushback from customers to open things up more or connect to the long tail.

Unlike plugins and customizations that are nice to have but rarely define a platform, connectors and integrations are often essential to a successful product both as consumer and producer. Because they are essential, it is only in the rare case of an entirely new category or platform shift that a connector and integration play itself becomes a platform. It is, however, a great way to build a key part of a future platform. In other words, these tend to be necessary, but not quite sufficient to define a platform.

App stores. App stores (or App marketplaces, or just stores, not to be confused with the App Store from Apple) have a special place in the world of platforms. They are also a new tool in the creation of a platform, one that has gone from nice to have to every platform launches with a store.

The majority of the discussion surrounding stores falls to the perception of negatives: gatekeeper, arbitrary rules, lock-in, and of course the “tax” or “vig” or simply the take rate. For the purposes here I will not opine on the negatives, suffice it to say that having spent a lot of time in software before stores I am a true believer in the value stores bring to customers and would defend a platform’s right to have a store and to treat it like other features integral to the whole, not a separable part.

At first App stores were a place to simply get software. In the days of BBS, then FTP, and then web download sites, the hardest part of getting users for software was distributing the product to people, especially in an era before computers were connected or when software acquisition was a physical product. With iTunes not only did Apple make a store that was integral to owning an iPod music player, but it began to charge money. All parties of the store participated and benefitted. Music previously pirated could be discovered and purchased with revenue flowing to musicians. iPods had access to the world’s music catalog. Owners of iPods could build legal music libraries and so on.

The transformation of App stores took place with the 2008 introduction of the iPhone App Store. For the first time end-to-end a complete developer API platform was extended to include app distribution, monetization, payment, and most importantly an enforced consumer promise. It is this latter point that is overlooked the most. Conversely, most tend to overvalue the value of distribution, which in the age of the internet is minimal. This mismatch causes the take rate to be negatively viewed.

The critical point about the extension of the platform to a store is how it overlays the APIs of the platform with guardrails for proper usage of the platform, something missing from all other prior technology platforms. These guardrails enable a customer promise around the constellation of security, privacy, reliability, peripheral usage, data access, app isolation, battery life, robustness, accessibility, localization, and more. In addition, the store provides a secure payment infrastructure with guardrails including parental controls. While the iOS platform is not free of software that exploits holes in the APIs or app guardrails, relative to all other platforms (including Android) it is not unreasonable to say it is effectively free of the problems of exploits, malware, and abuse.

From a platform perspective, making a customer promise that the APIs do what they are supposed to do is one thing, but extending that promise to “and they are used to do what they are supposed to” has been an incredible and undeniable win for consumers. While the shift from desktop/laptop computing to mobile focused on the form factor, the real shift was the App Store. It is easy to imagine the alternate universe we would all face absent the App Store, of a constant patch Tuesday, malware, editing the registry, unable to safely add apps, unable to fully remove apps, constantly needing to do “clean installs” or reboots, and more.

Apple could have just said the APIs represent modern platform for iPhone when used correctly, but they did the work to build a value proposition including taking a lot of heat from developers about a lack of openness—developers who had previously exploited the Mac platform in ways not always aligned with the broadest base of customers. Likewise, Apple could have followed the paths of other mobile phones and carriers had provided a limited set of capabilities for a platform or forced far more arbitrary commercial arrangements on to a very tiny set of developers jockeying for position on phones. Instead, they built the most open mobile platform ever—at a time when they were only a year out of the gate with a single digit market share in phones against formidable competitors and limited distribution through carriers.

These glowing comments about the original App Store are mostly to remind platform builders and aspiring builders that an App store is a promise to those downloading the apps. It is a chance to build an API with a rich set of features while providing a mechanism to extend that API to that promise. That is what building a platform that includes a store is about.

That said, in the rush to platformize an asset many choose to build stores that are fundamentally about distribution. These often arise from existing platforms via a marketing effort to show the breadth of support. For example, a platform with connectors might have a “store” for connectors or a platform that has a number of vendors making tools for monitoring, deployment, or management of the platform might have a “store” of those tools. While there might be some value in these, they are what I would say are a weak form of store. The primary or even bulk of the value accrues to the existing platform and very few of the vendors end up benefitting. They rarely benefit the makers of those tools, and they almost never include a customer promise or even revenue sharing. In fact, more often than not the backchannel conversation around such “marketplace stores” is quite negative over the lack of real customer leads and the failed promises. A good rule of thumb is that a catalog of everything available is neither a store nor a marketplace, it’s just a web site version of a logo slide.

Marketplaces and Networks. For completeness, marketplaces represent platforms as well, with App stores as a special case of marketplaces that connect software developers to device owners. As described earlier, marketplaces are a topic that many have studied deeply and written about much more intelligently than I could. Marketplaces today rely on software and technology as the tool to bring together both sides of a marketplace and match buyers and sellers successfully. Unlike the above platforms they are not, however, primarily technology companies. The underlying commodity is the product and defines the market whether that is transportation, groceries, hotel rooms, or more.

Networks have similar characteristics to marketplaces in that the platform is composed of the underlying asset (a social network for example) and the network is the result of applying that asset. Like marketplaces the creation of a network asset using technology is a separate and deep topic (see for example, Andrew Chen’s The Cold Start Problem). Many networks also have APIs or UX as platform elements.

Open source. Also for completeness, open source is often viewed as a platform type. There is a taxonomy of platforms where the primary axis is the distribution or pricing aspect of the marketing mix. Open source provides a unique distribution and pricing mechanism, leveraging the “Price” and “Place” of the marketing mix discussed below. An open source project that forms the basis of a technology platform will be built using one of the models above. For a great discussion of the role of open source and the economic challenges please see Peter Levine’s Why There Will Never Be Another RedHat: The Economics Of Open Source.

A note on stickiness/switching costs…

The goal of building a platform is to create stickiness of a platform, to build something that people want, try out, and then just keep using. While the best case is to dominate a market in terms of some measure of share, that doesn’t have to happen to create a great platform. Many markets are large enough for several large players or diverse enough that a single dominant player, however naturally and legitimately it arises, does not make sense.

The mistake many make in building a platform is to start from knowing stickiness is the goal by engineering in high switching costs. No platform that has high switching costs started out by architecting a system with that as a priority. Customers are far savvier than to simply buy into a product knowing how difficult it will be to switch.

Even regulators realize this after the fact. A product that people want to stick with will also be one that will prove difficult to stop using. I would always argue that a product never needs to intentionally design stickiness because it will just follow naturally from a great product people want to use. In fact, over the long-term customers will come to value a product designed to be used as little as possible and as efficiently as possible to accomplish the task at hand. The more customers can accomplish the more they use a product and the more it becomes a sticky product, all without intentionally engineering stickiness. Some will say I am naive or Pollyannish about such a mindset. So be it.

One of the ongoing battles I had at Microsoft with BillG over the years was about intentionally designing products to be proprietary, or deliberately sticky. I just didn’t see the need when customers loved a product. Bill, a product of his earlier era, saw how IBM had used proprietary technology to its great advantage and always pushed this. Whether it was developing proprietary extensions to a programming language or creating data formats that were impossible to copy or translate. In Hardcore Software I wrote a story that took place during the antitrust trial. Office intended to use open HTML as a file format and that generated rather strong disagreement from Bill on the topic.

His exact words were “We have to stop putting any effort into this and make sure that Office documents very well depends on PROPRIETARY IE [Internet Explorer] capabilities. Anything else is suicide for our platform. This is a case where Office has to avoid doing something to destroy Windows.”

Let’s just say, I disagreed.

A rule of thumb I have developed about building products that help people while increasing stickiness for a company is as follows: source of truth >> code >> process >> individual skills. By this I mean that the stickiest platform is one where the source of truth for a business process exists only in that product. Once data is the source of truth, no matter how open (via API or ETL) the data is, the ability to move off a platform is constrained by the semantics of that data or the code, not simply the bits on disk. The next most sticky platform is one built on third party code. Writing code is a huge investment and while traditionally viewed as an enormous moat (as was described in the Microsoft antitrust case) we also have seen a sea change in how companies view code. Code is far more transient, and much more can be done with less code. Additionally, the cloud and browser have dramatically reduced the amount of unique code it takes to build on an underlying platform (for example AWS). Within a business the process used around a platform creates the next stickiest platform. It is always amazing how what seems too many to be a relatively simple piece of software can create an enormously sticky platform. Okta, Docusign, Box, and more are all examples that were often described (sometimes by famous people) as simply features of a platform yet by focusing on the process of work they created enormously valuable and sticky platforms. Finally, the least sticky, but still sticky, aspect of a platform is the user’s individual skills and investment in using/learning a platform. While any single person might be significantly attached to a product, organizations and people are far more willing to switch and learn something new than they are to change a process, write new code, or transport data. There is enormous cost to retraining an organization, especially in areas where tens of thousands of people execute an automated series of processes implemented in software, but people are the most flexible in the whole stack, so to speak.

Why do platforms fail at launch?

If being a platform is so great, why do so many of them fail? As with most of product development, defining and identifying points of failure is quite easy. Unlike most product failure, the potential failure points for building a platform are often not difficult to predict based on past behaviors. In other words, there are few exceptions to typical platform failures, certainly over time. There are always exceptions, but key to understanding exceptions is to ask if the existence of an exception is the cause for platform success or just coincident with an already successful platform. Product-market fit is a powerful force. Why do platforms fail at launch:

• Failure to solve a problem that platform consumers really have

• Asking customers to solve your problem not their problem

• No one wants to leverage it

• Experience v. API and “who is on top”

• Doing too much

• Doing too little

• Charging in the wrong place, the wrong way

The theme across all these failure paradigms is the lack of understanding that for a platform to succeed, customers will need to put in effort. The more effort they put in—the higher the opportunity cost for them—the more likely there will be a potential for success. The smaller the customer effort, the smaller the potential return.

• Failure to solve a problem that platform consumers really have. This might be the most obvious, but building a platform is also a matter of product-market fit even if the platform is a secondary effort. Even with the best intentions, it might just be that those that you need to invest in building your platform simply don’t see the opportunity. No amount of evangelism or opportunity-marketing can change their view.

• Asking customers to solve your problem not their problem. While not as obvious, the most common failure is that a platform doesn’t solve a customer problem, but it is designed to solve your own problem. Alexa skills did not solve a customer problem as most devices don’t benefit from voice control but having everyone do the 10 minutes of work to create a basic skill decidedly solved the Alexa problem of showing massive industry momentum. The marketplaces that surround many SaaS products do not generally drive customers or adoption (or deliver a customer promise), but they do make the SaaS product appear to have a strong market momentum. The worst case of this failing is when a platform, a plugin for example, exist to fill holes in a product. Enthusiasts love when they can assemble a complete product from various add-ins, but rarely does the mass market.

• No one wants to leverage it. What if you build a platform and no one comes? It is quite possible to build a platform and even with a ton of PR and massive interest, there’s just no demand for a platform in the space. Often the root of this failure is platformizing too early, before the whole (the whole product+device, or product+experience) has firm footing or a clear use case. The most difficult aspect of this failure is that the problem remains, but the platform offered just doesn’t ignite the fire required. The bigger the company the more difficult it is to honestly determine if this failure is the case. A large company always has at the ready some set of fans that will commit to a platform in some way (ActiveX or WinForms anyone?) Platform delusion is a real and serious condition in big and successful companies.

• Experience v. API and “who is on top”. Platforms created from existing purpose-built products often suffer from an inability to “get out of the way”. There’s a strong desire by developers and potential consumers of a platform to use the underlying data or compute engine, but the platform maker sees their app as needing to remain visible and front and center. The problem is developers want to own the full experience for business and usability reasons. With tiered architectures, the ability to maintain semantically viable data relies on knowing all the ways a user can reach data. If the full UX for a product remains it is likely it can break an application built on a platform.

• Doing too much. In order for a platform to gain traction it must be accessible to the consumers. It can’t require an enormous amount of specialized knowledge or crazy upfront investment. When designing a platform the “Hello World” equivalent must be a one hour or less experience and the next steps obvious. The transition to graphical interface, specifically programming for Macintosh, was enormously difficult for many people even though the computer was so cool. It wasn’t until tooling was upleveled that apps really took off. It is entirely possible for one smart person with knowledge and experience to architect a platform far too difficult for anyone to master. The good news is that if the platform is strong enough some people will commit and get products built and their input will help to improve tooling.

• Doing too little. Conversely far too many platforms simply do too little. What they do might be cool but given the opportunity costs and tradeoffs involved in committing whatever they do offer is just too little. When Apple Watch came out the ability to order an Uber from a watch was an incredible demo. Sure enough, any time I wanted to order an Uber I was also holding my phone. The same could be said by a significant number of Watch apps. As Apple increased the scope of the API and effectively the “tax” of making a Watch app, it is no surprise that those apps started vanishing from the store. At least they vanished and did not just hang around not working, though. Countless “add-ins” fit into this category, especially when the primary function of the add-in is to provide quick access to the full site/app as some sort of launching point. Those don’t get used and is hardly the difficult part of any use case.

• Charging in the wrong place, the wrong way. Good platforms aren’t free, but there are many ways to get paid—that’s the opportunity and the challenge. Figuring out the right place and right way to get paid is often the primary or only reason a platform fails. Technologists always ways think the best platform is the most technically superior. Technology, however, can have many attributes and people can disagree on which matters the most. MS-DOS was one of many operating systems available at a time when the industry believed the world will have some dominant computer makers and each will have an operating system. While IBM “blessed” MS-DOS it also provided CP/M and even a couple of other oddball platforms. It was the business model of MS-DOS, licensing it at a low price to other computer makers that made all the difference. That led to choice and cheaper computers at a time when most computer makers offered little choice and higher prices. Apple had vastly better software at that moment in 1984-89 but could never compete with the PC platform ubiquity. Every platform transition has a story about having the wrong price or distribution strategy. The biggest lesson is that the success in the previous generation does not necessarily follow. One need no better example than how Apple used the failed Macintosh strategy for iPhone, and it was a galactic success.

A note on failing to consider all the 4 Ps…

Platforms are products, not just technologies. All too often, however, they are thought of as primarily technologies and success, or failure is a technology argument. A shorthand that works well is “the best platform doesn’t always win, but what wins becomes the best platform”. Spending time immersed in the 4 P’s of the Marketing Mix and identifying how a platform addresses each of those, and how competitive alternatives fit in, will prove to be instructive in deciding what platform approach might work best for the market you are going after.

Why do platforms succeed?

Even with all these challenges, many platforms succeed. They become the basis for the economics of others and the place people go to get their jobs done or participate in a network, all while generating economic return for the platform maker. While knowing some of the factors for success can be a helpful guidepost, there still exists no formulaic approach. Product development remains a social science. I know, as I’ve failed.

There following are some of the attributes of successful technology platforms:

• Developers, Developers, Developers

• In reality, you’re building an ecosystem not just a technology platform

• Makes others successful without being a tax

• Enables domain specifics to flourish

• Gets out of the way

• Predictable

• Substantial and sticky

• Share is air. Be greedy when you’re dead

Developers, Developers, Developers. Steve Ballmer, the former CEO of Microsoft and not even arguably the person most responsible for the success of Windows, Azure, and Office 365 famously blew out his vocal cords at an internal meeting emphasizing his love for “developers” or engineers. Steve was never one for subtly. The amazing thing is that Steve used this same technique whether he was talking about partners, enterprise, or retail. It was not just his repetition or volume, but the maniacal prioritization needed to win, segment by segment, product line by product line. To win with a platform, one must walk in the shoes of the target customer. That is what he meant by repetition. The only thing that matters is to see the world as your customer does and embrace it and build for it. Check your own ego at the door and do the job of being a platform. He also had another saying he’d attribute to his parents, “if you’re going to do a job, then do a job”. I always took it to mean if you’re going to build a platform then by gosh build a platform.

In reality, you’re building an ecosystem not just a technology platform. Thinking in terms of an ecosystem makes you think about how the pieces fit together and the fact that no platform is single-sided (even though we define marketplaces specifically as multi-sided) or simply the technology. If the technology or code is the platform, then the ecosystem is everything around that platform and how the code is the accelerator for all the parties involved. Even if you build what some might think of as straight-forward enterprise software with an API used by developers to build apps, there are still channel partners, consultants, trainers, third party support, and other software or even hardware that surrounds the work process being implemented. Those make up an ecosystem. Each requires the same level of dedication and outreach as developers. Apple, especially the legendary marketer Guy Kawasaki, popularized the term evangelist to broadly encompass all the work that goes into bringing parties together for the success of the platform which you can read about in Selling the Dream: How to Promote Your Product, Company or Ideas and Make a Difference Using Everyday Evangelism. For a technical description of the value of ecosystems in product development, friend and Harvard Business professor Marco Iansiti authored a foundational book The Keystone Advantage: What the New Dynamics of Business Ecosystems Mean for Strategy, Innovation, and Sustainability.

Makes others successful without being a tax. A platform exists to make others successful. The most successful platforms help people to be successful on their terms, not on your terms. A winning and excellent platform feels like having a whole team of people helping you to achieve your goals, not like a tax or working with the government. This is very easy to say and early on it is easy, but at scale the view of other people at your own company comes to dominate every discussion and motion. Fight against this.

Enables domain specifics to flourish. One joy of creating a platform is seeing it used in wildly different ways than you originally anticipated. There’s amazing satisfaction that comes from building something that enables you to learn about whole other worlds. The greatest joy for me when I worked on Microsoft’s C++ compiler was seeing all the amazing things people built with it that I had never encountered. I met a person building a DNA sequencer with a Windows front end built with C++. I met people building line of business tools to run manufacturing floor tooling (and connect to SAP). Heck, I even met a guy at the University of Illinois building a new-fangled web browser. While everything on the iPhone seemed new, I’ll never forget that original launch demo of an app showing off medical brain images…on a phone!

Gets out of the way. The most difficult thing for anyone building a product is to fade into the background and get out of the way. Doing so enables those building on the platform shine. Successful platforms exist for the benefit of others and that is always important. When platforms are new it is easy to stay out of the way because there isn’t much there. Over time as complexity and surface area grows this becomes more difficult or even counter to your own goals. Fight it. One of the most difficult things I ever worked on was redesigning the Office user experience platform. The biggest goal was to get the UI out of the way and let the user’s work take up as much of the screen as possible. We did this same for Windows 7 and (yes) Windows 8. Just fade away. When we designed Windows 8, the primary design goal of the UX (and the Start screen and app API) was to turn over the whole device to the app and for Windows to get out of the way—developers were in control of every pixel on the screen just as games are designed. Nothing you think you might be doing that is useful is more important than what the users of the platform want to do, whether it is an API or user experience.

Predictable. Once other companies are betting on a platform then the platform is responsible for, perhaps indirectly, the revenue of other companies. To partners, once they bet on a platform the only thing that matters is predictability. This predictability takes on two forms in successful platforms. First, platform engineering partners are extremely sensitive to commitments regarding features and capabilities. Second, platform business partners are extremely sensitive to commitments regarding pricing and availability. Successful platforms promise and deliver. So much has been written (by me even) over the damage done to the Windows platform between 2000 and 2009. The failure to promise and deliver was a significant cause of the negative spiral of the platform, only masked by the enormous level of product-market fit. The converse of this has been how Apple has managed macOS and iOS, which by any account has been a remarkable engineering feat of predictability for 20 years. In this post I described it as relentless.

Substantial and sticky. By far this is always the most difficult to measure and discuss. There’s an inherent negative that comes with being either substantial—that is potentially too complex, having too much overhead, or just being too broad—and being sticky—in other words, high switching costs. It is easy to sound positively awful when using these descriptors. Reality is reality, however. Successful platforms have weight to them. They solve very hard problems, at least they seem difficult initially. Windows originally made it easy to print and use a clipboard, both rocket science on MS-DOS. When something is substantial and people make a bet on it, then by definition it is sticky. There’s no need to engineer sticky on purpose, which is cynical and kind of rude. Simply solve hard problems and make it easy for people to use the solution and the stickiness follows. Down the road everyone will think what you did was obvious and not all that difficult, yet no one will be able to copy your work. Platforms are amazing that way.

Share is air. Be greedy when you’re dead. Successful platform businesses are hardcore businesses. They fight for every dollar and unit. They are not charities. Still, they almost always focus first on being ubiquitous and gaining a solid market share. The reason is because the more entities that bet on a platform the more other like entities will bet. By becoming the share leader, you are built into the fabric of an industry, domain, or technology space. You remove the decision point and become the default. That is the ultimate goal of any platform. Steve Ballmer, in those riled up moments, would remind sales teams “share is air”. Even when we were winning, we fought to keep winning. The managers of ecosystems fought for every Windows developer, every Office seat, and every IT manager sponsor. Many don’t remember things the way they actually were, but Windows was always only a few percentage points of the price of a PC. Even when Netbooks arrived, Windows was nowhere near the cost of other parts. The reality of a platform that was never written about in Innovator’s Dilemma is that once the platform is out of steam, then it is the time to be greedy. Today, IBM still makes most of its money off mainframe computers. Oracle prices were bad in the heyday and today, yikes. There’s vastly more time to be greedy once you have a successful platform than you might think.

A note on platform moats…

No descriptor of platforms is misapplied more than the concept of having a moat. Investopedia defines a moat referring to the popularization of the term by legendary Warren Buffett as:

A business's ability to maintain competitive advantages over its competitors in order to protect its long-term profits and market share. Just like a medieval castle, the moat serves to protect those inside the fortress and their riches from outsiders.

Evaluating a mature business—a platform—by developing measure of how much of a moat exists is a favorite pastime of value investors, consultants, analyst, and MBAs alike. Platforms that are growing are creating moats, but we just don’t call it that. We call it growing. A platform that is shrinking doesn’t have a moat, rather the ground is just sinking all around it. There’s no need to measure anything but share to know if a platform has a moat. Platforms can’t be simply copied because they are not commodities. It is that simple and I admit I like to be simple.

The general problem in using the term moat to describe platforms is that even in value investing circles, a moat is a retcon, a retroactive construction. A moat is how a business is described either after it is successful or after it was previously successful and lost share or shrank. There’s no such thing as a potential moat. A platform either has a moat or it doesn’t. Save the moat talk for the MBA case study after the platform decline starts.

The Platform Lifecycle

With a shared understanding of the types of technology platforms, why they fail to launch, why they succeed, we should have a framework for the lifecycle of technology platforms. With this lifecycle in place, we can see the various opportunities to fail or where managing the platform goes wrong.

The Platform Lifecycle (Source: author)

A note on this is that no platform experiences each illustrative lifecycle step here. Some never make it to the end, while others skip over some potential pitfalls and race to the end. Some remain viable for long periods while languishing partway through this full lifecycle. Nevertheless, each of these phases is typical enough to describe.

• Launch a “Toy”. Most platforms launch as toys. Seriously, take a look at the original HTML/HTTP. There are a set of technologists or enthusiasts in any domain always on the lookout for the coolest new toys. They will run most anything through its paces and very quickly there will be a view on how exciting a potential new platform is. The easiest way to know is that a set of people have literally dropped everything, and every day new use cases and “apps” (for lack of a better word) emerge. In today’s context it is easy to see chatGPT and the associated APIs from OpenAI fitting this description. A new platform can seem like a bolt of lightning.

• Do Everything. No matter what domain, platforms evolve very quickly at this point even if the upfront time to get to the toy launch was several years. Early progress seems insanely fast. As soon as people ask for something it seems to show up. Then seemingly overnight the platform does most of what everyone thinks it needs to do. Debates are over the fringes or entirely new ideas not yet part of the platform but not necessarily universal in appeal. Even though it seems a blink of an eye, it does take a few years. Again, something to consider with respect to chatGPT.

• Disillusioned—can’t do everything. One of the craziest times in a successful platform is when people try to make it do things it just can’t yet do. They are almost certainly right about wanting to do whatever it is, but the timing is all wrong and some key pieces of technology do not yet exist. Mark Cuban made his name and fortune trying to broadcast sports audio over the internet, and RealNetworks did the same. It was the late 1990s and most people still used 56K modems. It was never going to work. Fast-forward and just a couple of years and we’re all watching live streamed video on work PCs and a few more years and everyone in a house is watching 4K video at the same time and people stream music in a moving car. Still, there’s a period of time when a platform becomes disappointing when it can’t do everything that was collectively hoped. Sometimes that is important, as I might suggest with the iPad and productivity tools. Other times it is more entertaining, as when people tried to make Windows games in Visual Basic. The browser is an example of a platform that people continue to try to make everything work and Google keeps making most everything work, where everything means everything that already worked on a desktop OS.

• Filled all the holes, but now is too complicated. Platforms keep at it, trying to make it do everything by filling in all the holes, adding new subsystems, reworking existing features and more. This is the stage when people start to complain. Developers are never sure of the right way to use a platform. The performance begins to degrade. If you work on the platform it starts to get difficult to find the best way to add capabilities.

• Partners/ Middleware introduce new ways to do old things. As platforms become so complicated that it is difficult to add things in the right or obvious way, partners begin to add features to the platform but on top of and not in the platform. Middleware starts to become the platform for many because it offers a simpler sandbox to develop within. These solutions provide new capabilities but also begin to offer new ways to do even the old things. Sometimes it is these changes that start to feel like a paradigm shift is taking place. The platform is losing control. The data storage industry saw this with the rise of multidimensional analysis and with blob storage, as an example. Certainly, on desktop PCs browsers evolved to be a simpler way to write what amounted to desktop apps.

• Everyone seems to be competing, lack of oxygen. At his point in the evolution of a platform it starts to feel like the platform itself is a battleground. Different parts of the platform solve the same problem. Or maybe the platform vendor has multiple approaches to the same problem, often just old and new, but the guidance about what to use is either vague or so draconian as to be impossible to follow. It is at this point the biggest news about the platform is how the platform is competing with partners. New features of the platform were previously features of the ecosystem. There’s just not enough oxygen in the room for all this effort.

• Nickel and dime partners, platform gets in the way. It is at this point the nickel and diming of partners starts. The most obvious place this might be is in pricing. Technical pettiness can also be the case when various APIs are too quickly sunsetted for example. Most of all during this phase the platform itself starts to get in the way. All the small requests or changes add up and at the same time the baggage of the platform gets in the way more than it solves problems.

• Overplay hand and ask too much of everyone. There’s often a moment in time in the evolution of a platform of a bridge too far, of just asking for too much. The list of “must haves” is too long or the changes required to maintain compatibility and performance too great. Or maybe it is just that the information becomes erratic or even commitments fail. Almost invariably when one looks at the history of a platform fails, there is a moment when the maker overplays their hand.

• Complexity becomes the norm, too much IQ required. The platform has evolved to a point where it is simply too complex. The easiest measure of this is that it is all but impossible for a new developer to enter the ecosystem. There is too much to learn with too many choices and too much IQ. Building an app or add-in requires a team, not a person.

• Partners just want compatibility and stability. From this point forward a platform is in a decline. It is almost certainly not a business decline, but a decline in viability. The life force is no longer there. The enthusiasm, the commitment, the new apps no longer appear. All the requests are to just maintain compatibility and stability. “Please don’t break anything” is the most common refrain. The platform development team almost always responds with “we’re listening to customers” and “feedback” becomes the norm.

• No one there to use new things. Finally, the end stage of a platform is when there’s just no one there willing or able to take advantage of anything new. There are new APIs, new scenarios supported, new user interface, and literally no apps, not bets, not ecosystem there to do the work. The remaining customers are the installed base maintaining what was already done.

It might seem sad or even tragic when a platform goes through this complete cycle. Having lived it multiple times, I prefer to think of it as the “circle of life” and part of the natural order. Platforms should not last forever. Better ways do come along. It is ok. It is better to build the next platform than do everything possible to keep a platform at a late stage of the cycle. I felt this so strongly I made a big bet that did not play out, though the reality of where the platform was has become more settled today. These are very difficult challenges, perhaps the most difficult in product development.

What we have learned is that technology platforms have two lives. They have the creation and run up to success which happens much more quickly than it might seem at the time. Then there is the demise, which counter to the “disruption” narrative takes vastly longer than most believe to the be the case. This long tail of a platform owes itself to the incredible product-market fit successful platforms attain. Literally there’s nothing one can do to make a successful platform fail sooner once it achieves success.

Since I referenced Warren Buffett earlier it is only fair I also reference Charlie Munger. Tren Griffin has a fantastic book on Munger, Charlie Munger: The Complete Investor, worth a read. Munger has this to say about companies in general but it most decidedly applies to platforms:

Well, over the long term, the companies of America behave more like biology than they do anything else. And biology, all the individuals die and so do all the species, it’s just a question of time. And that’s pretty well what happens in the economy, too.

All the things that were really great when I were young have receded enormously, and new things have come up and some of them started to die. And that is what the long term investment climate is. And it does make it very interesting.

Successful platforms might be biological, but they tend to be the most hearty of biologics, like a fungus. They are very hard to kill off. While we love the stories of Kodak, Blackberry, or 5” disk drives, most platforms are more like mainframes, horses, or bank branches.

Ultimately, platforms succumb to paradigm shifts. Not every technical innovation is a paradigm shift as most can be categorized as sustaining innovations. But there will be one. It is inevitable. I hope this essay can serve as a reference to the evolution of platforms. I promise to revise and update it as I am sure there are better ways to express what has been said and new ways to succeed or fail that should be amended.

—Steven Sinofsky (@stevesi)

# # # # #

For insightful feedback on an early draft, special thanks to Ceci Stallsmith (@CeciStalls) co-founder of Calyx Consultants, specialists in helping companies build winning platforms.