The Five Traps of Software Ecosystems

Software ecosystems and platform businesses are the new black and several of the companies that I work with are, in some form or another, working on more strategic engagements with their ecosystems. Although the ambition to position oneself as a keystone partner in a software ecosystems and to provide a platform for others in the ecosystem is a laudable one, I see companies fall into a number of traps. Five of these traps are the most common and below I discuss these in more detail.

Descriptive versus prescriptive trap: The first trap that several companies fall into is assuming that the ecosystem as it exists today is “cast in stone”. The assumption is that the current boundaries between different ecosystem partners and partner types are a given and immutable.

Of course, static ecosystems are a misconception as everything changes all the time. One has to understand that an ecosystem is balanced by forces. These forces cause boundaries and power and control positions between different ecosystem partners to balance out to a certain equilibrium. When the forces in the ecosystem change, the boundaries and power positions of ecosystem partners change as well. Consequently, companies should experiment with changing the forces in their ecosystems in order to proactively bring shifts in the ecosystem.

For example, imagine a company in a regulated industry that relies on suppliers that provide pre-certified subsystems. This tends to cause for more power to reside with the suppliers because the amount of knowledge, expertise and resources required is quite significant. This results in a small selection of suppliers that have significant pricing power. If the company would incorporate the certification of subsystems as part of its system certification process, the requirements on suppliers would be significantly reduced, allowing for more suppliers being able to offer solutions, resulting in less pricing power for suppliers and a lower cost for the company.

Assumptions trap: Especially keystone partner companies often assume they understand the needs and wants of their ecosystem partners and all ecosystem partner types. Based on this incorrect understanding, companies take decisions concerning the business strategy, architecture, ways of working, etc. that are fundamentally at odds with the real interests of the majority of their partners.

To address this issue, it often helps to explicitly model your ecosystem in terms of the relationships between ecosystem partner and partner types (and not just to your company). As part of the modeling, the value exchange, both pecuniary and otherwise, should be expressed explicitly as well. This will surface the assumptions about partners that your company holds. Once these assumptions have been made explicit, it often is quite feasible to find mechanisms to test and validate these assumptions.

For example, many ecosystem evangelists stress the ease of deploying apps or extensions to their platform to third party developers and believe that this is a key differentiator. Apple has clearly shown that this is incorrect. Their submission process is complex and a pain for developers, but developers still prioritize iOS over other mobile ecosystems. The reason for this is simple: iPhone users spend much more on apps than Android users. Developers accept the complicated app submission process as they know that the likelihood of making money is much higher.

Keeping it too simple trap: Several companies that I work with treat an ecosystem partner, such as another company, as a single entity. Consequently, they miss that even within a single company, there are multiple roles inside the organization that affect decision making and behavior within the ecosystem.

The solution is to identify and model  the various “interfaces” the ecosystem partner has to the ecosystem. For instance, the procurement function, the security officer and the R&D organization will have fundamentally different drivers to support or refuse to participate in an ecosystem. Especially keystone partners need to understand the different roles and functions within the partners they look to engage. Based on this, one can develop hypotheses of the wants and needs of each “interface” and subsequently test and validate these hypotheses.

For instance, many banks are engaging with FinTech startups to bring new, exciting functionality to their customers. These FinTech startups demand access to the financial information of a bank’s customers. The information security and compliance functions of the bank as well as several standards in the banking industry significantly complicate this ambition. Failing to satisfy the needs of these functions will break the ecosystem before it even started.

Doing it all at once trap: When seeking to shift or disrupt an ecosystem, for some reason most companies assume that all partners can and will move at the same time just because the company asks them to. It’s almost as if the traditional reorganization model applied within the company is also applied to the ecosystem. Obviously, without the hierarchical control enjoyed within organizations, partners will only change and shift their position in the ecosystem if there is a significant benefit that overcomes the always present inertia.

Although one does need an understanding of the desired state, the transition process itself should take small steps where, first, the first partner type(s) to move are identified. Second, the company needs to ensure that there is a sufficiently powerful value proposition for these partners. Third, one needs to validate that the partners actually do shift when presented with the opportunity. Once this is concluded for the first partners or partner types, this process needs to be repeated until entire ecosystem has shifted.

For example, Amazon broadened its offering and the set of partners that it involved in a gradual fashion. It didn’t start its current ecosystem as it looks today fully designed and modeled and just pushed the button. This required continuous experimentation and iteration.

Planning trap: Many companies are hesitant to engage with their ecosystems. Their assumption seems to be that it is necessary to fully model and design the desired ecosystem before starting to engage partners. Of course, full modeling and design of what you may want to see is just wishful thinking and things will never materialize in this way.

The best thing to do is to just get started. First, set a high-level direction of what you’re looking to accomplish. Then, plan the first step in the general direction and experiment your way towards the first milestone. And while you’re iterating and experimenting, constantly adjust according to the emerging feedback.

As an example, especially startups seeking to build a two-sided (or multi-sided) marketplace need to build sufficient participation from both sides before their ecosystem reaches “ignition”. It is often much easier to first build up a user base for one side of the market by offering something of value in and of itself, even without the other side of the market being present. Once this is accomplished, one can expand to include third parties. For instance, Amazon, Facebook and similar companies first built a user base by offering a valuable service. Only then did they open for third party developers.

Concluding, positioning your organization as the platform provided and keystone partner in an ecosystem is a highly desirable position that many companies aspire to. In my work with a variety of companies, however, I have noticed that companies tend to fall into a number of traps, some of which I outlined in this post. Please share your comments and feedback and let me know if you have seen other traps that companies experience!