Platform tectonic shifts alter the partner+platform landscape very rapidly
From Product to Platform — Platform Revolutions (4/5)
From product to platform: A PM journey
Introduction
This post is the fourth part in a series of five regarding platforms and the key differences with products.
- Part 1: The partners
- Part 2: The complexity
- Part 3: The mental models
Revolutions or evolution?
Most of the time, a platform evolution is more subtle than a product evolution. One will have to read all the API release notes to try to make sense of the general platform direction. Different teams are in charge of these evolutions. Each team has its expected outcomes and business realities, which makes analyzing these changes even more challenging. Doing this analysis from outside of the platform organization is even harder because the analyst lacks context. We will discuss these subtle evolutions in the subsequent section.
Let’s focus on a more drastic way for a platform to evolve: platform tectonic shifts!
Revolutions: Platform tectonic shifts
The root causes of these significant changes are:
- an existential threat to the platform or part of the platform
- a major strategy shift
- customer expectations have changed fast
The tectonic shift has the same consequences for the partner ecosystem as a major seism in the physical world. The dissipated energy can be enormous and have a tremendous impact area or be more localized and only affect a few specialized partners. It depends on the partner distance from the seism epicentre as well as the nature of the tectonic shift.
In any case, for an impacted partner, these tectonic shifts have all the characteristics of a natural disaster. Usually, these changes happen because customers’ need evolved: they expect some previously partner provided functionalities to be part of the platform.
In its most extreme form, some partners are banned from the platform ecosystem (removed from the app store) and can not extract additional value from this platform.
Case study: Microsoft Windows and Internet Explorer
Let’s go back in time and use the Windows operating system platform as an example. Microsoft’s decision to create a default browser (Internet Explorer) instead of using Netscape Navigator for this part of the user experience was a tectonic shift.
As often in these situations, the platform team had close to zero expertise into the product, market, and technology they wanted to replace. The first iterations of the product were less performant/feature full than the product they are replacing.
After a few iterations, the product becomes decent and used by millions of customers. It could be argued that Internet Explorer was never really a success from a user point of view. Let’s review these events from a platform and partner ecosystem point of view.
Internet Explorer: an incredible commercial success
In retrospect, Internet Explorer was immensely successful even if its user interface and quality are debatable. The data speaks by itself Internet Explorer was used by 94.43% in 2003 (Wikipedia).
This tectonic shift triggered a lawsuit: the United States of America vs Microsoft. The US accused Microsoft of breaking customer consent by bundling Internet Explorer with the operating system.
Impact on the partner ecosystem
The effect on the partner ecosystem was terrible: Netscape was losing the war on both the server-side and the client-side aspects of the Web server and Web browser. From a dominant position (>90%) during the 1990s, it was gone by 2002. Microsoft had won the browser war … on the desktop.
It was a terrible blow to the partner ecosystem at this time. Being a browser editor at the time means that you could not derive any revenue from this platform anymore. Any partner needed to find a new niche, a new business model and evolve super-rapidly or disappear into oblivion.
The platform needs to remain valuable: users first, partners second
Today, we can all agree that an operating system without a browser is not an operating system. The platform did what its customers expected: it delivers a bundled solution that works out of the box.
Netscape found, almost by accident, another way to compete using an open-source model to remain relevant. While the company disappears (sold to AOL), the source code remained alive and became Mozilla Firefox. Mozilla Firefox was able to survive thanks to its lean business model and revenues from the default search engine shipped with Mozilla Firefox (Google search at the time).
Platforms wars round 2: Internet Explorer as a casualty
The new mobile operating system platforms (Android and iOS) used this playbook to create their browser (Chrome and Safari). An open-core that could be cross-platform (the HTML and Javascript rendering engine) and a proprietary layer owned by the platform so that no one can compete on the OS of origin of these browsers.
Android dominance as an OS created chrome browser dominance. It also explains why Internet Explorer disappeared on these new dominant platforms. For 15 years, Microsoft was not even competing!
Microsoft tried to become a first-class player on mobile. Billions of R&D and a failed acquisition later, RIP Windows Phone, RIP Nokia. Android and iOS crushed Microsoft platform-level competition efforts.
Microsoft is now a player in the cross-platform browser ecosystem world. Edge is bundled with Windows (of course!) but is also available on Android, iOS and even MacOS (beta for now).
Once again, Windows the platform delivers what its users expected for years: a cross-platform browser experience. The windows platform’s goal is that Windows desktop and surface users can use Microsoft’s default browser on other platforms. As a consequence, Edge has already more market share than Internet Explorer (4.51% vs 4.45% — Source: Wikipedia) and received way better reviews than Internet Explorer ever did.
Microsoft is an underdog in these markets. Without a vast user base, Microsoft can evolve faster, meet new user needs, delight users in new ways, and, if possible, disrupt the current equilibrium.
Platform Revolution
Based on this example, we can come up with some sound conclusions and advice for both platforms and partners of these platforms.
- A platform will always act based on its users’ best interests first and partner second (See part 1: the partners).
- Because of inertia, market dominance and unwillingness to compete on somebody else platform, the platform will always be trying to compete at the platform level. Being cross-platform for a partner is a way to mitigate risk.
- Impacted partners need to react fast and find creative ways to generate revenues. Adopting another business model, finding other revenue streams, becoming cross-platform saved lots of companies.
In general, it is fair to assume that platforms have no interest in disrupting their ecosystems violently. As a consequence, they rely on this strategy mainly because they missed some critical strategic decisions. The tectonic shift is a violent o course-correct. It is a manifestation of the decision to stop relying solely on the partner ecosystem for key and core functionalities.
Platform iterations
This type of iterations is way more frequent than the tectonic shifts described above. Iterations are the primary way platforms evolve and keep up with their user needs.
When user needs and expectations, as well as business reality, change slowly with time, platforms are relying on iterations to evolve. Platforms will either expand the functionality for specific partners’ type to create more value or move some of these functionalities inside the platform’s core offering.
These iterations create a perpetual tension between the partners’ single-function highly specialized offering and the broader/generic core offering by the platform. Both the platform and the partners are also actively monitoring what is happening on other platforms or products. In general, it is fair to say that the iterative approach is creating more value for the global ecosystem.
As the platform slowly incorporate some of the partner functionalities into its core, partners will have to innovate as well and provide to their customers a better value proposition. These ever-changing boundaries between the platform and partner functionality will help keep everyone honest and competitive as they both strive to meet the user needs and expectations.
In a healthy partner-platform community, these changes are discussed jointly with the partner and platform: the roadmap for these changes is well known and shared with partners. Most of the time, the boundaries (between app and platform) evolve organically, and while there is continuous change, there is also a constant displacement of the value creation from the platform to the partners.
How to decide what is a core functionality of the platform and what should be provided by partners?
In general, platforms avoid tectonic shifts. Platforms prefer an iterative evolution as it is almost guaranteed to deliver more value faster and also to maintain trust within the partner-platform ecosystem. The trust between the partners and the platform is the main value creation driver.
Strategy shifts, as well as legal or financial imperatives, are the root cause of tectonic shifts. Examples include a partner extracting to much value, a partner abusing its dominant position within the partner ecosystem or an existential threat from outside the platform ecosystem. In these situations, the platform needs to come up rapidly with a good enough solution and commit important resources to build, maintain and support the new functionality.
The Pareto principle applied to the partner and platform ecosystem
The Pareto law states that for many events, 80% of the effects come from 20% of the causes.
This rule can be super helpful in deciding which feature is core to the platform. Only the most important features used by 80% of your users (or providing 80% of the platform value) should be part of the platform.
Everything else should be implemented as an API so that partners can provide the remaining functionalities that are critical for specific users or markets. Quite often, these functionalities are exclusive to a small percentage of users. They are super-valuable and indispensable. Usually, these functionalities are deemed more advanced, are often more complicated than the platform and are also harder to implement, set-up and support. Most of the time, most of these functionalities are useless for most of the platform users.
Pareto law is only one mental model of many…
While the Pareto principle is super useful to capture the value creation aspects of the platform and partners, be careful to look at the complete picture. Use all the pertinent mental models (see: Part 3 — Mental models) for platforms.
As always, consider the desirability and feasibility and viability of these decisions:
- For viability: Make sure you know what the competition (other platforms) is doing and why. Run business analysis and have clear financial metrics and goals. Share this with all your stakeholders to make sure everyone is on board with the proposed changes.
- For desirability and usability, consider the user experience. For instance, does it makes sense for a user to install an app and a partner page for this feature? What are users’ expectations for this functionality: do they consider this is a basic one?
- For feasibility: is it realistic to have external API calls for this function? Will it slow down the application to a crawl? Can this functionality be down because of various network or partner outages? From a data integrity and accuracy point of view, who should own this data?
Feedback is a gift
You can reach me at Benoit des Ligneris.
- Did I miss some evolutionary path for platforms?
- As a partner, what tool do you use to decide on your strategy?
- As a platform, what tool do you use to decide on your strategy?
- Some unanswered questions?
Did you stumble on this blog post by accident? The beginning of this series may interest you:
1. Product to Platform (1/5): the partners
2. Product to Platform (2/5): the complexity
3. Product to Platform (3/5): the mental models
The next blog post (5/5) concludes this series and summarize some of the critical differences between platform product management (PPM) and regular product management (PM).
