Another week on the road and another set of discussions around business and software ecosystems. Although it is clear that the ability of a company to build an ecosystem around its business is replacing company size as a, or perhaps the, key differentiator, I notice that there is a lot of confusion about what being an ecosystem-centric company actually means in practice.
The confusion around the practicalities of being an ecosystem company is fourfold. First, the proponents of an ecosystem in the company seem to have a strong preference for a collaborative approach. Second, typically confusion exists about competition between the ecosystem partners and the keystone company. Third, it is often unclear how the platform underlying the ecosystem can evolve and what functionality is suitable to be included in the platform. Finally, the strategic business rationale for being in the ecosystem is frequently unclear and unaligned in the organization. Below we discuss each of these topics in more detail.
The notion that an ecosystem is inherently collaborative seems to originate from the open-source community as well as other collaborative communities such as the one around wikipedia. However, although my prefered definition of business ecosystems mentions topics such as symbiotic relationships and co-evolution, the fact is that parts of ecosystems can be highly competitive. This is true in natural ecosystems as well as in software ecosystems. For instance, on the appstore for your phone, there are dozens, if not hundreds, of apps for task management that compete with each other. The key decision as the keystone player is to decide where to use collaboration and where to use competition.
Second, some seem to assume that the keystone company, i.e. the company providing the platform for the ecosystem, can not compete with others in its ecosystem. The argument is that this would discourage partners to join the ecosystem. In practice, it is about clear rules rather than about competition. Most companies will end up with three areas of functionality on top of the platform that they provide for the ecosystem. The first area is where the company provides functionality on top of the platform and it does not allow for competition from others. For instance, for a long time, Apple did not allow other browsers on its iPhones. The second area is where the keystone company competes with ecosystem partners. For instance, Microsoft allows other document, spreadsheet and presentation applications on Windows, but does compete directly with these applications with its own Office suite. Third, there are areas where the company decides to not compete with its own solutions on top of the platform. Here the ecosystem partners have the playing field to themselves and only compete with each other. Clearly defining, and then communicating, what functionality belongs in each of these three “buckets” is a critical strategic decision.
The third topic is a common misconception that the keystone company can never incorporate functionality into the platform that currently is provided by ecosystem partners. It is important to remember that any platform is constantly sinking into the morass of commoditization and needs to continuously incorporate new functionality in order to stay competitive. The best way to do so is to identify functionality currently built on top of the platform that is broadly used and that is commoditizing at the application level. Once identified, this functionality needs to be incorporate into the platform and this will likely affect ecosystem partners as well as the app teams working at the company itself. Not incorporating this new functionality will cause the platform to become irrelevant over time.
Finally, one of the topics that never fails to surprise me is the frequently total lack of alignment on the expected purpose of adopting an ecosystem approach. Smaller companies often look to build an ecosystem as a competitive response towards larger companies that offer a broad suite of functionality that the smaller company can not afford to build by itself. A second argument frequently used is that a successful ecosystem will drive sales of the core platform and thus generate indirect revenue. A third argument is direct monetization through app stores or the like and capturing a certain percentage, typically 30%, of the revenue generated by ecosystem partners. And finally, companies under attack by competitors with successful ecosystems adopt an ecosystem strategy as a defensive strategy. The lack of clarity concerning the strategic purpose of the ecosystem initiative will cause significant amounts of discussion, confusion and disagreement.
Concluding, as the title alludes to, ecosystem strategies can be very diverse in their realization and it requires significant effort, in my experience, to achieve clarity and alignment on the strategic intent of the ecosystem and the operationalization of this strategic intent. Your ability to build successful ecosystems around your key products and platforms is increasingly the differentiator that is replacing company size. Small companies will successful ecosystems can disrupt large companies, but of course large companies with successful ecosystems will have a significant moat around their business. So, if you’re not good at this already, you better start building the capability to build and evolve business ecosystems.
To get more insights earlier, sign up for my mailing list at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch) or Twitter (@JanBosch).
