Design for Ecosystems: Emergence & Attraction

By Simone Cicero and originally published at

Engage Ecosystems by Amplifying Participants Potential

The more I run Platform Design workshops, the more I realize one thing: the most challenging moment always come at the beginning, when the team needs to clearly figure out the scope of application of the methodology and approach.

Scoping, setting the point of view and delimiting the opportunity we’re addressing with a platform — an ecosystem mobilization strategy — is an extremely challenging task.

I guess one of the key points when designing for ecosystems, is that the very effort of trying to set a boundary to the design challenge doesn’t make much sense anymore. I always come to point out to the teams that work with us, that there’s no more an inside or outside to a company, an organization or a brand, and that strategy must be seen more as boundary-less and as a continuum (inside, at the edge and outside the, blurring, context).

You can use many names, but the truth is no boundary exist anymore: you’re designing for a continuum — where control doesn’t reach you can exercise influence through incentives and narrative.

Therefore, what is the context we’re trying to address when designing a platform strategy (for ecosystem mobilization)? What are the economic opportunities and what players are we designing for?

One key thing we must acknowledge when designing for ecosystems is to accept that — while the design scope might be wide — we can still begin by prioritizing and focusing on few points of view, and progressively iterate the approach at later times. That’s how you explore complex systems.

Entities versus Roles

In writing extensive guides and posts about the Platform Design Toolkit we’ve often used two terms interchangeably: roles and entities. There’s, by the way, a not-so-small semantic distinction between the two, and I’ll try to explain briefly how these two meanings differ, and combine. You can usually get to map an ecosystem from two different standpoints:

  • you have a blurry, macro idea of an economic opportunity that exists (e.g.: a market you want to address) or of an ecosystem potential that is latent and could be empowered (you design for emergence);
  • you already have a wellformed idea of a platform-powered, value-creation process, or you’re designing for an existing context and your challenge is to design the incentives to shape it or re-shape it (you design for attraction).

An example of the first could be that of a team that wants to design a platform (strategy) to power the market of, let’s say, craft baby clothes and amateur sewing.

A huge movement, market and ecosystem potential exists behind craft baby clothes and sewing kits, a potential target for a platform strategy that aims at designing for emergence.

An example of the latter instead could be that of applying platform design thinking to an existing organization or process (“I want to rethink our sales strategy as a platform”), or to pivot existing platforms, that are already providing tangible experiences to users. In this case there is already a clearer understanding of the roles that actors might play, while, in the former, one could bring more of an exploration mindset and just map the entities without speculating much beforehand on the role they could play.

The difference between mapping entities and roles might be summarized by the following example: if we take the example of Airbnb, householder is the entity (that exists before the platform), while guest is the role (in an envisioned process-experience of travel).

The essential meaning of the Platform Strategy

In both cases the strategy you are crafting needs to be designed for pull. To pull participants from an ecosystem to join a platform (strategy), you need to generate attraction and to resonate with their context.

The platform strategy needs to provide them with expanded opportunities to:

  • leverage on their available potential (the assets and capabilities they’ve access to);
  • respond to the continuous pressures they experience (in a techno-socially disrupted world);
  • achieve their strategic goals;
  • provide them with relevant experience gains (easier, cheaper, faster ways to achieve their objectives, and get access to larger audiences of peers).

The most important thing to understand, whether you are designing for emergence or attraction, that platform strategies should provide an amplification of a participant’s context, and that they need to resonate with their existing needs and goals, not merely providing plainly new perspectives.

Here lies the narrative of “expanded opportunity” that John Hagel praises in truly shaping strategies (platforms): convincing entities that they’ll be able to amplify their potential, reach existing objectives in smarter ways, achieve their fullest.

Above you can see how different parts of the Entity Portrait Canvas can help you focus on building the pull value proposition for your Platform Strategy: the promise that you’ll amplify their potential and help them respond to pressures, while achieving their goals, by leveraging on their potential.

Choosing the Core Entity and Point of View

As you’ll find in our updated User Guide we normally suggest to choose what we call a Core Entity in your ecosystem. Despite in our available documentation you often find it dubbed as the most important or the bigger group, I can tell you that, the more we facilitate these workshops, the more we realize that there’s not an entity or role that is more important than the others.

We tend to use use now the concept of the core entity acknowledging that platform design is an inherently evolutionary and open ended process. In reality, what you face when you design a platform, is a — virtually endless — abundance of points of view: starting from one is often just a design choice that is subject to change and be integrated along the way.

In the last few months we’ve been suggesting adopters — after mapping the ecosystem, and after diving into the entities’ context with the Entity Portrait — to choose just one entity, the one that feels the most important to start from, and identify then a couple of core relationships that should feature the chosen Core Entity as an endpoint.

Note that this is just a moment in a continuous design process, and that you should be sure to get back and iterate, with different choices, so to explore the full potential of the ecosystem.

An Example of Point of View and focus centered around the Guest Experience in Airbnb: plenty of other relationships exist that can be explored later.

Normally, in a two day workshop dynamic (which is also the one you can experience at our upcoming masterclasses in Milan and Barcelona), we use an approach based on the identification of one Core Entity and two Core Relationship(s). This is essentially the point of view, the angle, you choose to look into your ecosystem, at least temporarily, in a first iteration.

After choosing the set of entities you want to focus on, the first iteration of your platform thinking effort, as we normally suggest, is to evaluate the give-to potential. This exercise aims at identifying what value units could entities exchange thanks to the Ecosystem’s Motivations Matrix (that normally includes also other peripheral entities, to a max of five). An important aspect that needs to be kept in mind when exploring the give-to potential in the Motivations Matrix, is that you should aim at evaluating both potentials: what entities can exchange intrinsically, given their nature, and through the platform strategy you’re — at this point — starting to envision.

Normally then, the potential emerging in the give-to can effectively be shaped in a set of elementary transactions via one or more Transaction Boards. We normally suggest teams create one Transactions Board focusing on each core relationships that are subject of exploration.

Starting from the abundant material you’ve created before (essentially the potential to exchange that is in the Matrix, and the full description of the entities contexts (in the Entity Portraits) and try to converge in a transaction board could, sometimes, feel a bit weird: compressing all the potential you can see in an ecosystem in a set of punctual transactions (peer to peer interactions where some value unit gets traded) doesn’t feel natural at all.

But it’s important to understand that we are designing networks, and not industrial strategies. Platform (networks) have a huge potential for growth and market shaping just because they’re built on elementary, replicable, transactions combined in experiences. This essentially makes platform strategies easier to evolve (in continuous improvement), and scale (with growth hacking) and generally more complexity friendly than old industrial strategies.

After having imagined the transactions that make up the transactions engine — one of the pillars of a platform strategy, the markeplace-ish part of it — we normally suggest our adopters to look into evolutionary path with the Experience Learning Canvas, focusing on the three main steps of a participant’s evolution in a platform: onboarding, improving and trascending (the learning engine).

The use of the Experience Learning Canvas (here’s the blog post we used to present it a few months ago, while a bit old is still a good read) will help you create an additional set of bricks that you’ll be able to combine later: all the punctual services that the platform strategy needs to provide participants in crucial moments of their experience.

Combining Transactions and Services in a Platform Experience: your tangible Idea

A recap of one of the potential processes one could follow: download the hi-res PDF here

The last bit of envisioning how the ecosystem potential could play out — if supported by a platform strategy — is all about combining pieces together. We normally ask our participants to focus on the Transactions Boards (to pick elementary Entity to Entity transactions) and on the Learning Experience Canvas (to pick elementary services to be provided at some point of one entity’s experience): combining them with complementary platform-to-entity service elements — let’s call them platform features — one can easily get to a well formed, step by step experience that will be the first tangible form you will give to your platform strategy.

Based on this experience prototype, and the business model it should have, you will be able to move on into setting up your Minimum Viable Platform and start validating your ideas.

A Platform Experience Example from one of our workshops: the combination of Transactions (entity to entity) and services (platform to entities).


  • in Platform Design Thinking you design for emergence (if the context you design for doesn’t exist yet) or attraction (if you’re designing for an existing context);
  • in Platform Design Thinking you must convince participants that the platform strategy will amplify their potential, give them extended reach, and help them achieve their objectives and respond to the pressure they feel in a techno-socially disrupted world;
  • Platform Design Thinking is a never ending, evolutionary process, you can add points of view continuously, and there’s no real core segment you design for: your design progresses by evolving and adding experiences.

Republished with permission of the author.

Featured Image/graphic link added by Enlivening Edge Magazine