Although platforms can be used purely for internal purposes, many reach a point where they’re opened up to third parties, becoming an ecosystem platform. Ecosystem platforms serve, by definition, two- or multi-sided markets. This means that you have multiple stakeholder groups to support to make the platform successful.
When thinking about ecosystem platforms, I often distinguish between the ‘operating system’ class of ecosystems and the application-centric class. An operating system ecosystem needs to be built up by encouraging app developers to provide content and users to use the content. But both stakeholder groups have no interest in the platform until the other group is sufficiently large. In this case, you have no choice but to fuel the ecosystem by heavy investments in paying app developers to create content for a tiny user base in the hope that this content will entice new users to join and existing users to stay. As you can imagine, it’s very hard to achieve this stage and there’s a winner-takes-all pattern in the industry as the network effects are extremely strong in these types of ecosystems once you get to the ‘ignition point’ where users and app developers join the ecosystem without needing to be encouraged by you.
The application-centric ecosystem, on the other hand, provides value to users even without third parties providing content. In general, the best way to create an ecosystem platform is to first build the customer base to a level that makes it sufficiently attractive for third parties to provide extensions.
The challenge is to know when the time is right to start opening up. In my experience, it’s best to wait until you get inbound signals. These can be requests from customers or third parties for APIs or it might be signs of others trying to integrate new functionality into your system using creative means. For on-premise software, this might include third-party developers intercepting calls to OS functionality and inserting functionality there. For online software, this often becomes visible through atypical calling patterns of backend APIs.
Once there are clear signals that there’s an interest in opening up the platform, you need to carefully design the APIs, deal with proper authentication, set up proper security measures, and so on. However, the main factor for most companies is to create a sufficiently large addressable market for third parties. In many companies using a platform for a portfolio of products, the variation in functionality and the capabilities of the products can be significant. This can easily lead to a fragmented market where the ecosystem APIs aren’t available for all products or the behavior behind each API is different between products. That decreases the ease with which a third party can develop complementing functionality for a sizable group of users. Harmonizing the public APIs for the entire portfolio is very important as an enabler for creating a successful ecosystem platform but will initially be experienced as countercultural in the company.
Getting a multi-sided market to the ignition point where the ecosystem fuels itself without constant investment by the platform provider is extremely demanding and expensive. Rather than trying to build all sides of the market simultaneously, the better approach is to build the market one stakeholder category at a time. In practice, this means first building up a customer base of sufficient proportions based purely on the platform functionality and only then opening up to building up a second stakeholder category of third-party complementers.
Like what you read? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch), Medium or Twitter (@JanBosch).
