A playbook for creating adaptive ecosystems

Nathan Furr & Andrew Shipilov

Ecosystems have become a critical part of how industry leaders create new growth and capture competitive advantage. But how we think about creating ecosystems has fundamentally changed in the last few decades. Whereas in the past it was sufficient to play the role of broker at the middle of a centralized ecosystem (e.g., think how IBM used to sit at the center of an ecosystem of software, periphery, and service suppliers), today, smart leaders are adopting a more dynamic strategy: what we call an “adaptive ecosystem” strategy.

In an adaptive ecosystem, industry leaders cocreate new products, services, and platforms with a bevy of partners – often uncommon partners – working in more flexible and adaptive arrangements. These adaptive ecosystems can lower the cost and risk of creating new markets while increasing the likelihood of winning, as illustrated by the way that Didi and Tencent worked together to beat Uber or how Samsung is working with uncommon partners to create breakthrough products.

Adaptive ecosystems are not limited to private companies. Private-public partnerships can be at the core of an adaptive ecosystem as well. Philips built such an ecosystem when it joined forces with Salesforce.com and Radbaud University Medical Center in the Netherlands to create a platform for monitoring health and treatment compliance of chronically ill patients outside of the hospital environment. Salesforce provided data handling and analytics capability, Philips provided expertise in manufacturing medical equipment, while Radbaud provided both medical expertise and a pool of patients who were willing to enrol in the trials of the wearables.

But while we all understand the importance of ecosystems, the critical unanswered question is how to get them to work? For example, how do you identify the right partners, how do you get them to work together, how do you contract with them, and how can you get value out of the relationship?

Together, we have researched how to build ecosystems. This chapter is both a summary and an extension of our thinking on this critical question: the “how to” of orchestrating successful ecosystems.

Ecosystem foundations: back to the basics

The core of ecosystem strategy is the recognition that end customers prefer solutions, not products. For example, Apple did so well entering the crowded MP3 player market because it recognized that customers didn’t want an MP3 player, they wanted a solution for acquiring, managing, and listening to music. The ecosystem it brought together to perform these functions, combined with good design to make it easy to use, led to the dominance of the iPod. In essence, ecosystems are about bringing together all the parts and pieces (i.e., components and complements) for customers to capture value. Moreover, firms with strong ecosystems often beat out their competitors.

But how do you decide when and where to build ecosystems? The answer comes back to the most fundamental principle of innovation: what is the customer problem you are trying to solve? Ecosystems built on problems that customers aren’t willing to pay to solve (with time or money) in a differentiated manner will fail. For example, Blackberry and Nokia fell from glory not because their phones were technologically inferior to Apple’s iPhone, but because their phones did not provide differentiated propositions compared to the Apple’s ecosystem, which was centered on a full user experience in acquiring, storing, and managing a blend of information, communication, and entertainment services.

By contrast, the successful firms we studied spent time in advance to ensure they were solving a worthwhile problem. For example, Cisco’s Hyper Innovation Living Lab (CHILL), which focused on creating new growth areas by bringing together five to six partners (both corporates and startups), always began with a multi-month problem discovery phase. Specifically, after framing a hypothesis about a value creation opportunity, team members at the ecosystem orchestrator interviewed multiple leaders at each potential partner to validate and understand the problem to be solved. This is essential because like any business, unless you are solving a valuable problem (it’s a significant problem that customers can and will pay for), there is no business opportunity and no ecosystem.

Likewise, Mastercard’s International Development group and Mastercard Labs for Financial Inclusion worked with non-governmental organizations in developing markets to create Mastercard Aid Network. This digital platform for humanitarian response is built to provide financial services to displaced populations. The technology can be deployed in remote environments that don’t have access to the Internet (e.g. refugee camps), enable disbursement of cash safely to the affected populations, and enables people to send money literally anywhere in the world.

Ecosystem partners: sending out the bat signal and sorting your heroes

For an ecosystem strategy, the orchestrator of the ecosystem – the one who pulls all the different players together like an orchestra conductor – needs to identify, attract, and qualify the ecosystem participants. To identify partners, it can be useful to ask: what are all the parts of the ecosystem that need to come together to create value for the end user? It’s useful to distinguish between the ideal ecosystem of the future and what Ron Adner calls the “minimum viable ecosystem” necessary just to get started. At the start of an ecosystem, you are more likely to succeed if you focus on the minimum necessary to create value because you can create proof points earlier and with less money than if you try to assemble the ideal ecosystem from the start.

As you think about the necessary ecosystem, separate out which 1) parts are readily available for purchase, 2) those parts that might emerge on their own but require encouragement, and 3) those parts that won’t emerge on their own and thus need to be created. Typically you would use a buy strategy for the first, a partner strategy for the second, and a build strategy for the third. However, even though you might need to build some components, consider doing so with partners rather than doing it alone. As you do so, look beyond the radius of regular partners that you normally work with to consider uncommon partners: firms outside your normal scope, for example, in other industries or startups, to help you execute your strategy. For example, when Lowes, the hardware retailer, broke new ground using augmented reality to sell products, created exosuits for workers, and developed robots to do inventory in stores, it did not build these itself. Lowes also did not build 3D scanners to digitize all of the household furniture that it sold (which was needed for developing augmented reality apps). Instead it found uncommon partners –frequently startups – that could help it nimbly build new solutions.

Once you identify your partner needs, you need to attract them to you. Just as the fictional Gotham City used a “bat signal” to call for help from the superhero Batman, so ecosystem orchestrators call for partners using some kind of signal. Sometimes the signals are public and visible. For example, Lowes would sometimes post videos about projects online to attract partners. Alternatively, the ecosystem building unit at Sopra Steria, the global IT firm, openly communicates client challenges to attract uncommon partners. By contrast, other firms choose to be more conservative in broadcasting their plans. For example, Samsung often puts together a conference around a potential development area without announcing its intentions publicly. It then invites potential partners and then during the conference evaluates those potential partners to see if it should explore further cooperation. Whichever path you choose, you need some mechanism to get to know the uncommon partners, and the common partners, necessary to develop a successful ecosystem strategy.

Finally, you need to evaluate your partners to make sure they can work together. For starters, you need to ensure that partners are ready to collaborate. If you have experience creating collaborations between corporates and startups you probably already know that there are massive cultural and operational differences between the two types of companies. These differences can be so severe that working together is not only difficult, but often described in terms such as “they don’t even speak the same language.” But this gap can be addressed and prepared for. For example, Sopra Steria’s ecosystem collaboration group begins with a brief assessment to see if the corporate is “start-up ready” and if the start-up is “corporate ready.” The assessment poses questions to understand the corporate’s prior experience working with startups, the structural elements to work with a start-up (such as an innovation unit or budget to pursue innovation), and the ease of working with a start-up.

In addition to overall readiness, we have found that adaptive ecosystem success is founded as much upon finding the partner as upon finding the right people within the right partner. The “right people” are typically described as someone who “gets it” (meaning they understand the ecosystem is an experimental innovation effort to see if value can be created), they have some level of budget control, and they are ready to take action (as opposed to waiting a year or two). Finding this person inside the partner organization can be the keystone to success and for a partner who is absolutely critical, it may be worth thinking through redundancy at multiple layers of the organization (i.e., there is a mirror-image tie between top, middle, and operational people at each organization).

Governing the ecosystem: incentives and contracts

One of the biggest challenges creating an innovation ecosystem is governance, particularly contracts. Because most corporates have experience contracting for more formal, centralized ecosystem strategies, they get stuck trying to create a massive contract with performances, penalties, and clear delineation of value capture. While these contracts make sense for more known and predictable projects, most adaptive ecosystems are built to explore and innovate and so it isn’t clear at all who will do what and how to slice up the pie. Sadly, many ecosystem efforts die trying to decide how to slice up a pie that doesn’t even exist yet.

Instead, in adaptive ecosystems we see short, multistage contracts focused on high-level guidance around value creation and capture. So for example, typical contracts acknowledge that partners are in an exploratory phase to determine if there is value to be captured. Furthermore, contracts specify that partners retain IP created before the partnership, that IP and value created during the partnership will be shared based on the contribution of a partner to the effort, and that future value created can be negotiated according to the level of investment partners are willing to bring to the partnership. To accomplish this it often helps to acknowledge a multistage contract: phase 1 is the exploratory phase and if we discover there is a something of value we will renegotiate in phase two. Furthermore, for the first phase, partners agree on what constitutes a contribution (e.g., cash investment, hours investment) that is fair and representative.

These contracts tend to be short – between three and six pages – and capture the spirit of the agreement. In these contracts, it is important to clarify who contributes what and gets what payoff, but not to get too stuck on it. For example, when Sopra Steria works with a hospital and a start-up to develop and commercialize a solution that could be sold to other hospitals, the parties agree to contribute 1/3 of the costs each while also agreeing to receive 1/3 of the revenues. Given that neither partner can go it alone, it makes no sense arguing whether one partner is entitled to 45 percent of the revenues whereas the other two are entitled to 27.5 percent. But that doesn’t mean everything is equal in every way because Sopra Steria has an eye on the long-term value creation while the startups need cash right away. Working out these different needs can be an important part of the contract.

In addition to the contract, there needs to be a “glue” that connects partners so they keep working together. The “glue” could be a set of incentives partners receive, such as a revenue share. Alternatively, the glue could be a technical platform or resource that all partners benefit from. Samsung used this strategy when creating new devices – partners collaborated around the technical platform. For Philips HealthSuite, this glue comprised the common learnings from patient data that it collected by working with Radbaud Hospital and Salesforce. But even with a well-designed glue, it is important to recognize that partners have different kinds of needs, and some partners may require extra support. To illustrate, for startups cash flow is king and they need revenue with an urgency that is different from a corporate with many revenue streams. As a result, the orchestrator may need to support some players over the short term, recognizing how they might capture value in the long term. For example, as Google developed its AR Core with a bevy of uncommon partners, it explicitly set aside funds to sustain critical start-up partners that might struggle with cash flow.

Finally, orchestrators should think through a delivery vehicle for the ecosystem effort itself. Ecosystems rarely organize themselves: they need focused effort and the orchestrator may want to consider what is the best vehicle to deliver the solution created by the ecosystem. Who should own it and in what format? One way to think about it is to determine the complexity of the integration of the ecosystem to deliver value and the stickiness of the partners. In other words, how easy is it to swap out one partner for another?

Table 1 provides one view of different strategies for delivery vehicles. This table is organized along two dimensions: partner stickiness and integration complexity. High partner stickiness reflects the extent to which an ecosystem needs a set of specific partners to create value, while low partner stickiness means that value can still be created when different partners can come and go. Integration complexity refers to the coordination necessary to deliver a solution. If high coordination between partners is needed then complexity is high and if it is more plug and play, then integration complexity is low. Thus, when partner stickiness is high as well as integration complexity, the orchestrator needs to have a heavy hand in bringing all the pieces of the ecosystem together and so probably must play more of an integrator role, like Sopra Steria does, by providing the final step of integrating the contributions of the different partners into a workable solution. By contrast, when integration complexity is high but partners may need to be swapped in and out, like Google did in the development of the AR Core, the orchestrator plays the central role of a keystone, around which all the other partners build. As partners come and go from the ecosystem (because stickiness is low), the one factor that holds the ecosystem together is the keystone, often in the form of a platform. When partner stickiness is high but integration complexity is low, the challenge is keeping critical partners working together (which brings up incentive conflicts if one partner takes too heavy a hand), so it might be good to spinout the ownership of the ecosystem into a separate entity. Finally, if both partner stickiness and integration complexity are low, then a loosely confederated community around some interaction point, such as an incubator or consortium, can work well.

Making the partnership work: barriers and facilitators

In addition to structuring the ecosystem for success there are a group of common barriers and facilitators we have observed. Typical barriers are challenges contracting, fear of sharing secrets/IP, or losing control. There are some remedies for these, or facilitators, and they can be grouped roughly into mindset and roles. In terms of mindset, it’s important to set expectations that the ecosystem is focused on creating value through rapid experimentation and that ideas are a dime a dozen. Therefore, don’t be so afraid to share ideas that you remain silent when discussing with your partners: remember that execution of the idea is all that matters.

In terms of roles, we have talked briefly about the role of orchestrator: a firm or individual who takes the role of bringing the different ecosystem players together like a conductor. This is a critical role without which many ecosystems fail or are inefficient. Sometimes this role is played by a single firm or, when there are incentive conflicts, by a consortium of firms. Failure to define the right orchestrator can lead to struggles in the ecosystem, like we have seen in GE’s struggles to create the Predix industry platform: each competitor vied to set up their own platform, creating ecosystem conflict in place of the needed coordination to get an ecosystem started. In this case, creating a third-party consortium between all the competitors may have been more effective. Whichever the right format for the situation, it’s important that the orchestrator has ownership, like an entrepreneur. In other words, if a corporate executive is given charge of orchestrating, in addition to a dozen other responsibilities, they will fail in the role. Usually it is better to give someone the motivation and responsibility of a founder to pull it all together.

Another critical role is that of the angel. This is the person who serves as the go-between, or bridge, between two partners, particularly startups and corporates. In this latter case, for example, the angel plays the critical role of protecting the start-up from the bureaucratic nonsense of the big company (for which they are often called the “crap umbrella”) and keeping the start-up doing its best work while also ensuring that the corporate is able to extract knowledge, lessons, and value from the start-up. For example, Avnet’s vice president for emerging business, Dayna Badhorn, works to protect acquired companies from the large organization’s inefficiencies while helping Avnet to learn how to be agile and run experiments with startups.

In conclusion, these are some ground rules – a playbook – for creating ecosystems that we have seen work well in the ecosystems we studied. They may need to be adapted for your situation, but what is clear is the value of an ecosystem strategy in helping defer the risk and increase the potential of creating new value.

Nathan Furr is a Professor of Strategy at INSEAD and coauthor of Innovation Capital (HBR Press, 2019), Leading Transformation (HBR Press, 2018), and The Innovator’s Method (HBR Press, 2014).

Andrew Shipilov is the John H. Loudon Chaired Professor of International Management at INSEAD. He is coauthor of Network Advantage: How to Unlock Value From Your Alliances and Partnerships (Jossey Bass, 2014).