Platform Strategy Design

#Introduction

Before you begin with the hands-on step by step process we suggest you get familiar with some key notions and concepts of platform design.

This introductory part contains some essential elements you need to be familiar with before starting your journey:

• a methodological note, introducing the concept of designing FOR ecosystems and the main contexts of Platform Design;
• a recap of the phases of the Platform Design process to help you situate this guide and the Platform Strategy design process described in this guide more widely in the platform design process
• a note on the contexts of Platform Design;
• a glossary of the keywords we use in Platform Design;
• a description of the key roles that we use to model all the entities around Platform Design;
• a description of the two key engines of Platform Design.

#A Methodological Note: Design for Ecosystems

The more we run Platform Design workshops, the more we realize one thing: the most challenging moments always come at the beginning, when the team needs to figure out the scope of application of the methodology. 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.

One of the key points to understand is that we are designing for ecosystems: that the focus of our design strategy is external, it’s IN the Ecosystem, not inside our team, company or institution.

On the other hand, we also need to acknowledge that the difference between inside and outside may be more blurred than in the past: the very effort of trying to set a boundary to a design opportunity doesn’t make much sense anymore.

We always come to point out to the teams that work with us that there’s no more an inside or an outside to a company, 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).

This enormous, boundary-less potential, on the other hand, must push us to accept that — while the design scope might be wide — we need to begin by prioritizing and focusing on few points of view, and progressively iterate the approach at later times. That’s how you can tackle a complex design.

#The Phases of Platform Design

The work of a platform shaper can be roughly framed in four macro phases:

The step-by-step instructions contained in this User Guide will mainly revolve around phase 2. and 3.

#Exploration

In this phase, a shaper understands the existing context, as well as the strategic meaning and applicability of a platform strategy that could impact, shape and influence the context. The key question that is asked in this phase is: “What could be a fruitful context where we can apply a platform strategy, given our position in the ecosystem, our assets, and specificities as an organization or team?”

Box 1: The Platform Opportunity Exploration Guide

The exploration phase is not covered by this user guide which focuses on the Strategy Design and Validation phase. You can learn more about the Exploration Phase with the recently released Platform Opportunity Exploration Guide. To know more about how we approach exploration, please refer to: “Platform Opportunity Exploration Guide” https://boundaryless.io/pdt-toolkit/ “12 Patterns of Platform Design to kickstart Innovation Strategies.” http://bit.ly/PDT-UG-PAT “Exploring Ecosystems: The Patterns of Platformization.” http://bit.ly/PDT-UG-EXP

#Strategy Design

In this phase, the platform shaper maps and clusters existing entities, understands their individual context and explores the potential they have to exchange value among them. Eventually, the platform shaper designs the two key platform engines (the Transactions Engine and the Learning Engine) and selects a high potential platform experience – along with its sustainability model (business model) – that can be brought to the context and iteratively validated with the ecosystem (see next phase: Validation and Prototyping).

#Validation and Prototyping

In this phase the shaper conducts a series of interviews (this could also partially happen during the design phase, and is generally an iterative process) to get feedback on the riskiest assumptions in the design. Later the shaper makes actual MVPs (or just runs experiments, or builds prototypes) that are focused to validate or invalidate the assumptions in real life.

#Growth Hacking

After the validation has happened, the shaper applies tactics to help the strategy grow in the context (being it a market, or something different). By growing the supply and demand side of the system, generating network effects, the strategy becomes more relevant and valuable.

Box 2: Platform Growth Guide and Course in the making

The growth hacking phase is not covered by this user guide, as it’s still an experimental framework we’re building. This upcoming integration to the Platform Design Toolkit will include a new Guide and a new Learning experience on Growth, Network Effects and Defensibility that will also cover the “product” side of a Platform-Marketplace Strategy. Stay tune by subscribing here: https://platformdesigntoolkit.com/growth-subscribe To know more about how we approach growth hacking, please refer to the below selection of blog posts: The New Growth Landscape https://stories.platformdesigntoolkit.com/growth-landscape

#The Contexts of Platform Design

In our direct experience with hundreds of customers two typical contexts of innovating business models are recurring and can be framed by looking at Cicero’s triangle. The first approach is what we call “Ecosystem Mobilization” and is about exploring the market - or more generally the ecosystem - seeking new opportunities that aren’t necessarily related to an existing business line, product or service that the organization provides already . The second, that we call “Product and Services Innovation” normally starts by the idea of evolving, extending and integrating an existing organizational offering that the organization is already strong with.

#A. Ecosystem Mobilization

In this common context of application of platform thinking the organization is looking to shape and mobilize an existing ecosystem with a new platform strategy. As we often say, Platform Design is heavily rooted in the observation of the emergent: you actually can’t design a strategy for an ecosystem that doesn’t exist (where exists = already trying to create and exchange value).

The analogy useful to explain the nonsense (i.e. design a new ecosystem), if you’re familiar with the lean thinking approach, would be designing a solution for an inexistent problem: who would do that?

This consideration is at the core of this first context of applicability: if you see that value is being created and traded in a certain Ecosystem, space, or market (or any other social context that you don’t normally call like that, can be for example your organization or your space of impact, in a non-profit context); if you see producers and consumers of value that are organizing around value creation, and you think this market (context) is performing below its potential, then this context is perfectly worth of organizing through a platform strategy that amplifies its potential. We call this context of application, ecosystem mobilization.

This is a typical approach that we consider as a transformative or radical innovation approach in traditional strategic terms as the organization is trying to create a new set of products and services to mobilize customers in a market that it normally doesn’t serve. In this context the aim of the organization - as we’ll see below - is to leverage on existing assets and capabilities to gain advantage, and provide relevant services to an existing ecosystem that - most likely and hopefully - has not been mobilized yet by any other platform shaper. This is normally the context of most of the traditional marketplace “startup” initiatives; but we are in this case even where the organization is leveraging its assets and capabilities to explore other markets. As an example, if an organization is capable of providing the best in class expertise on dealing with complex mission critical systems’ maintenance in the aviation industry, a subset of its capabilities can be used to shaper a similar (in terms of needs) industry, like the Civil Railways transportation, or Hospitals facilities management, etc. In that case we should probably consider this an adjacent innovation context (addressing different markets by leveraging on existing capabilities), but it’s not the point of this guide to seek for a perfect framing strategy jargon-wise of such approaches.

#B. Product & Service Innovation

Another recurring case is that of an existing player trying to - instead - use a platform approach to organize a larger ecosystem of interactions that is already insisting on products and services that the organization already provides.

In this case, there’s already an ecosystem of entities using the product or service as a component of a value chain. So, the opportunity here is to move towards higher values systems: the platform shaper might want to better organize this ecosystem, facilitating higher value interactions. It’s then about product/service innovation through platformization.

This is a typical approach that leads to adjacent innovation in typical strategic thinking: the organization that provides the already known product or service is looking for another - similar - market that can benefit from its current offerings (the latter can be then updated, extended or modified to better fit the new market) and provide the ecosystem with the infrastructure, components and services that help the ecosystem to grow. The driver here is the understanding of the current value chain, and its integration by providing higher value services to the entities, reducing the cost of transacting, offering better services and products. In this way the shaper can provide new niche experiences and help third parties in its ecosystem to grow as well, creating solid defensibility for its core services, now embedded in the third parties’ business process.

Such an approach works well when organizations are capable of looking at the whole value chain beyond their existing products: as an example financial institutions are often aware that their customers are not looking for a loan or a mortgage per se, but more as a mean to achieve a life defining event such as moving to a new city to follow a career opportunity: that is the real value they are sensitive to. If this organization wants to climb the value chain, this is where it needs to go to leverage the ecosystem. Facilitating such an experience of “relocating to a new city and changing house” through a platform strategy that orchestrates all players involved is far more valuable than the single mortgage approval. If you’re producing sports gear, your customers are not interested in owning that specific product (a tennis racket, a smartwatch) but in using them to improve their performance, stay healthy, and have fun with friends.

If we look at the mentioned contexts a bit more broadly, we can quickly understand that there’s a third (shadow) context that is somehow mixed with the two. Indeed, there’s always an existing organization that:

• works as a complex network of interactions between internal and external entities (therefore being partially overlapped with the concept of an ecosystem);
• produces a certain process or product (subject to the process/service innovation context).

The inextricable mix between the platformization contexts and the organizational one is a teller of how difficult to separate organizations from products, and organizations from ecosystems.

Today, the boundaries between the inside and the outside of an organization  —  and even between a product or service, and the organization that runs it  —  are disappearing. Think of Airbnb as an example: where does the organization ends and the brand, experience, or ecosystem starts? Hard to tell.

To understand better how to address this initial moment of understanding the context of the opportunity the reader should refer to Boundaryless’ Platform Opportunity Exploration Framework and Guide.

#Platform Design Glossary

Here you find a glossary with some of the most recurring words we use in platform design. We suggest you get familiar with these notions as they will be useful while going through the step by step process.

Canvas — A design canvas is a pre-formatted sheet of paper that enables a group of people to work and think together, as well as having structured conversations around a series of key topics to ultimately produce a shared vision and rich knowledge output. In our workshops, we use design canvases to help the team members to apply step by step our platform design approach, get insights together and share outcomes clearly with their stakeholders.

Platform Design Brief —  A Design brief is a document for a design project developed by a person or team (the 'designer' or 'design team'). The brief outlines the scope of the platformization project including initial insights and element of the initial vision.

Platform (strategy) — a strategy, run by a "platform shaper" that wants to mobilize and help an ecosystem in creating value, with the aim of capturing part of this value. A platform strategy is made of a combination of different elements: narrative, technologies, rules, channels, contexts, enabling services, protocols and more.

Ecosystem  — a set of entities playing in a context (e.g. a sector, an industry, a market, an organization) interacting and exchanging value, leveraging resources, generating outcomes. We often use “system” as an alternative to “ecosystem”. Note that contexts often overlap and boundaries of ecosystems are hard to define.

Entity  — an individual, economic and social actor with specific objectives. It can be a person, an organization, an institution, a team.

Role —  in platform thinking, defining a role is a way to cluster several kinds of entities into the same category of players, primarily according to how much they share motivations to join, assets and capabilities (resources that they can leverage) and type of value exchanges they're looking for. Clustering entities into roles help you to apply platform thinking. As an example, modeling a healthcare platform-ecosystem, to facilitate booking and consumption of medical advice, one could model a general practitioner (GP) or a specialist under the same role of “medical professional” or “healthcare service provider”.

Transaction—  a transaction is an interaction between two entities. It happens in a channel or context and it involves an exchange of value units between the two entities. Transactions are already happening even before we deploy our platform strategy, however, the more the channel is well designed to reduce the coordination/transaction cost the more of these kinds of transactions will happen easily. A good transaction is simple, elementary, ‘atomic’. It is something easily repeatable, like filling out a contact form.

Incentive— one of the main pillars of designing and deploying a platform strategy is to deeply understand what would be the incentives we foresee for every entity to join our platform strategy. Usually, incentives have to do with everything that addresses the entities' performance pressures, life goals or generates more convenience for them. The more we understand incentives, the more likely is that they would embrace the "new rules of the game" embedded in our platform strategy.

Platform Narrative —  is the macro message that embodies the “new rules of the game” that a platform shaper wants to offer to the entities of a sector, industry, organizational or market context. The platform narrative aims at convincing existing players to join a platform strategy because it will be easier for them to produce and exchange value, as well as because they will learn and evolve much faster as compared to not joining the platform strategy. One way to describe it is what John Hagel calls a narrative of positive opportunities: “…an effort to broadly redefine the terms [..] for a sector through a positive, galvanizing message that promises benefits to all who adopt the new terms”

Network Effects — Network effects are the mechanisms, peculiar of networks, whereby adding a new user (or producer) makes the product/service/experience more valuable to every other user. Network effects are of many types. One example could be the network effect generated by adding a landline to the network (Metcalfe’s law).

MVP — in platform thinking this word stands for Minimum Viable Platform, besides the more usual Minimum Viable Product. The MVP is an initial iteration of the platform strategy that is focused on validating the riskiest assumptions: this is normally used to minimize the risk in designing and developing a whole strategy - investing a lot of energy and money in developing it - without actually learning and validating first if the ecosystem really exists and the strategy generates attraction and pull.

VUCA —VUCA is an acronym used to describe or to reflect on the volatility, uncertainty, complexity, and ambiguity of general conditions and situations in the modern world. It’s a key concept in Platform Design, as the shifting conditions of reality create the mounting performance pressure on entities in the ecosystem for which the platform strategy wants to be an answer.

#The Entities in the Ecosystem

When developing a platform strategy, one needs to address, mobilize and support an Ecosystem. To make it easier for platform designers to confront the complexity of designing for ecosystems, we’ve created a simple framework to frame the entities involved in a platform strategy.

We differentiate entities into three groups:

Normally, the strategic connection with the platform strategy grows as much as you get closer to the owners/shapers.

Demand players (consumers) are less strategically linked as they can leave the ecosystem easily, with little impact.

Producers are more tightly connected, with Partners investing a lot of energy and time to become the best, and therefore being concerned about developing a strong connection with the owners.

#Impact Entities

#Platform Owners (or Shapers) [PO]

Is the entity who owns the vision behind the realization of the market and ensures that the platform strategy exists, evolves and thrives. It can be a team, an organization or sometimes is a set of teams throughout different organizations in a form of committee or a consortium.

This category refers to the “owners” of the Platform. Owners are those ultimately responsible to ensure that the platform strategy exists and evolves. Normally we are talking about the firms - whether Startups or Scale-ups or corporate firms - that own the platform, but nothing prevents this from being a non-profit organization, a foundation, or even a cooperative structure that is open to the participants.

In the latter, peers or partners could also be owners of the platform in some ways: as an example, in the Bitcoin Blockchain ecosystem, peers collaboratively own the infrastructure that makes the platform.

Sometimes, and increasingly, we see the potential to separate owners from shapers. One player can design a strategy with the objective to craft a sustainable business model that is not necessarily related to owning the infrastructure of the strategy. This potential separation is reflected by several trends in the evolution of platforms, their governance, and the increasing type of players that can develop or influence the future of platform strategies.

#External Stakeholders [ES]

Stakeholders are entities that have a specific interest in platform success or failure, in controlling platform externalities and outcomes, in regulating it or in exercising rights in the platform governance.

This category normally includes, for example, all the actors dealing with the regulation and control of platform strategy on a local basis. It can also include the representatives of the plurality of peers and partners involved in the value creation, or any pre-existing institutions that can help the platform thrive. Additionally, this can include entities that can help distribute the strategy and help it grow. Normally, we’re talking about entities that are hit by the positive or negative externalities of the platform.

#Demand Entities

#Peer Consumers [PC]

Peer Consumers (PC) who we may also call users, are entities interested in consuming, utilizing, accessing the value that is created through and on the platform.

They are individuals but can also be small/medium business and single representatives or teams in bigger organizations. Eventually, in some cases, they may evolve into peer producers when they realize that beyond fulfilling a need they can seek evolutionary opportunities to produce.

#Supply Entities

#Peer Producers [PP]

Peer Producers (PP) who we may also call producers, prosumers, and providers, are entities – most of the times individuals – interested in providing value on the supply side of the ecosystem/marketplace, usually seeking for opportunities to improve their professionality and honing their capabilities towards a better performance.

Typically, these players produce value occasionally and not systematically. Often the same peer may behave as both consumer and producer in different phases of its relationship with the brand-platform. Like in the case of a traveler that also rents her house when she’s not at home, such a user may sometimes contribute to the value and other times consume it, depending on lifetime phases, contexts and more. Peer producers can as well be SMBs or individuals.

#Partners [PA]

Partners (PA) are professional entities – individuals and SMBs, most of the time – that seek to create additional professional value and to collaborate with platform owners on a stronger level of relationship.

Typically, partners are professional value creators that tend to specialize in a niche or advanced/premium product/service and become better and better within time. Partners sometimes also facilitate, cater and enhance the value production by acting as brokers, facilitators, connectors.

In particularly polarized platforms, where you substantially have two sides (supply and demand) the partner could be an evolution of the peer producer into a more professionalized role. This evolution is typically well received from the platform since partners drive more value than peer producers and are able to pull many other players towards a better overall platform experience.

We just presented you with a possible way to classify entities in your ecosystem. It’s highly possible that your ecosystem doesn’t feature a “full” picture: it may not, for example, have any peer producers (often the case in Business to Business ecosystems). Sometimes it is also hard to figure out who is a partner or peer producer, but we normally don’t care much about the difference. The reason for introducing the Partner and Peer Producer differentiation is to stress the point that - most of the time - real platform strategies mobilize wide ecosystems, involving producers of different types: some more strategic, professional, commercial (partners), some more informal (peer producers).

In the instructions coming later, we’re going to be back on mapping, and especially focusing on how to group “entities” into “roles”, to simplify and streamline your design.

#The Two Key Engines of Platform Design

In our understanding, any platform strategy is based on the creation of two essential engines of value creation. As a Platform Owner (or shaper), designing, building and evolving these two engines — and finding a sustainable model to do so — is the most critical challenge.

#The Step by Step Platform Strategy Design Process

#1 Mapping the Ecosystem

Practical Steps Guidelines

• Start by enumerating entities: if you’re in a group, try to diverge first, taking some time to brainstorm alone.
• Cluster similar entities together.
• Position PP/PC/PA based on the key value produced: are they consumers or producers?
• Choose a maximum of five entities in the PP/PC/PA (peers) spectrum. You can either cluster two similar entities (finding an overarching description) or just choose five you want to start with.

Suggestions

When you start mapping, most likely you’ll map “entities”, individual entities in your ecosystem that have a specific context, motivations, and expectations. To make your platform strategy more general and able to scale up, you’ll want to keep as much of the ecosystem's potential as possible inside the reach of your strategy. You can, therefore, cluster similar entities by giving them a “common” name: by allowing two slightly different entities to play in similar ways, you’ll design a more loosely defined “role” (instead of entity) that could be played by both.

As an example, you can define a General Practitioner and a nurse, both “healthcare professionals”. Any time you cluster a shared role for two or more entities, you’ll lose some detail but, as your platform strategy needs to be able to scale up, this is a good thing as they’ll find their own way to participate, and you’ll be able to keep both of them involved.

#An Example: Prosumer Energy Production

In the ecosystem of independent renewable energy production - referred to here as Prosumer Energy Production - we could map the following entities: Prosumer, Solution Advisor and Solution Provider (see canvas to the right).

In this example, the Solution Provider is essentially a company that can technically install a certain solution, whereas the Solution Advisor clusters professionals working in that field, like engineers, architects, a construction company…

Note that solar panel manufacturers are seen as stakeholders in this example, since their products are nowadays pure commodities and the value of this ecosystem is accrued elsewhere.

You can access the whole example here: “A Platform Design Example Explained”

https://platformdesigntoolkit.com/Example

Three Essential Tips and Tricks

• Use post-its, this will help you play around with entities, cluster them.
• Don’t obsess about PC vs PP vs Partners - it’s not so crucial, even if it’s a good idea to figure out what is the key value provided (renewable energy production, in the example).
• Remember that you want to map entities involved in the continuous interaction as PC/PP/PA and not those interested in the whole thing (these are platform stakeholders). Always ask: how many of them? If you can only mention one or two, it’s unlikely they’re PC/PP/PA.

What Do You End Up with?

How Does This Connect with the Rest?

You’ll have a list of all the entities that are already trying to exchange value in the ecosystem you’re trying to shape.

Starting from this list, you’ll explore their context more in depth and start evaluating what value they exchange already, and what they could exchange.

#2 Portraying Ecosystem’s Entities-roles

Practical Steps Guidelines:

• CONVENIENCE GAINS are all about any “easier, faster, cheaper” way to do things as compared to the current situation of the entity-role. This is going to be the part of a platform strategy that resembles more the …. solution to a problem.
• To identify the REACH GAINS the entities are looking for, ask yourself: “what is their other half of the apple” that these kinds of entities are seeking? What’s the perfect producer for this consumer (and vice versa)? REACH GAINS should help you explore what dimensions are important, inside your ecosystem, for entities to get in touch with the niche they’re looking for.
• Be sure you begin by first compiling the Entity-Role Portrait of the entity-role that seems the most interesting for your design challenge: for which entity-role are you designing for in the first stance?

Suggestions

Portraying entities is an activity that differs slightly from traditional user research approaches. In our framework, ecosystem entities are loose clusters (see the reflection above with “healthcare professionals”), that’s one of the reasons why we call them also Roles. If you come from a user research approach you may, therefore, experience some issues while getting to the details of let’s say a real user profile, a persona, etc. That’s perfectly fine! When you do platform design you want to design a strategy that pulls a much wider spectrum of participants in that market, niche or context. For each role, you want to design a value proposition that can capture different adoption contexts. Entity-Role Portraits are indeed a keystone exercise to craft the narrative and value propositions for your entities. Platform strategies have inherently multiple value propositions. The value proposition for an entity-role can be described as follows:

“I’ll be able to leverage my potential, to reach my goals and cope with performance pressures, while the platform will give me access to easier, faster, cheaper ways of doing things (convenience gains), help me find exactly what I'm looking for (reach gains), and gain more value - whether money or somethings else - while fully expressing my potential (value gains)”.

Finally: remember that you want to map what the entities you are looking to mobilize right now, not in the future when your platform will exist. In a nutshell, keep the focus on the ecosystem (outside-in), not on your “platform” idea. As an example: gains are those entities looking for in their current experience, not the gains you’re thinking to offer.

To understand this and other key questions of this canvas you may, of course, rely on your industry knowledge, intuition or, way better, on preliminary interviews. A platform strategy that is able to sustain participants while letting them express their potential, will be generating what we call the pull factor: a galvanizing attraction towards each of the entities. Each entity will, therefore, choose to play “inside” the strategy you’re going to offer, as it’s more convenient than—instead—staying outside.

#Two Examples

In this example, you can find an entity-role portrait for a Business Manager of a fictional consulting platform company called CONSULTIA.

You can access the whole example here: “How to Platform-ize existing Processes”

http://bit.ly/PDT-UG-PEP; the example of the EP for the Airbnb host is also available here: http://bit.ly/PDT-UG-EUG.

In the Prosumer Energy Production example we capture the Prosumer as highly motivated not only by economical returns but also by a green spirit, even if (s)he is currently blocked by the high entry barrier to having a renewable energy plant at home due to bureaucracy, hard-to-be-estimated costs, uncertainty and lack of trust on the vendors and suppliers side.

You can access the whole example here: “A Platform Design Example Explained”

https://platformdesigntoolkit.com/Example

Three Essential Tips and Tricks

• Use post-its, this will help you move elements around and get to a clearer view.
• Start by the potential and then move into the compressors (goals and performance pressures), and then gains.
• It’s a good idea to run a round of informal interviews (open-ended) with representatives of your entities groups, or even to get them to participate in the mapping exercise.

What Do You End Up with?

How Does This Connect with the Rest?

You’ll have a clear understanding of your ecosystem’s entities context (you’ve been wearing their clothes), and also a raw idea of your multi-sided Value Propositions

Remember to map the entities you feel more important, as further on in the process you’ll need to cross check your Platform Experience Canvas with the relative Entity-Role Portraits, to verify you can generate the “pull”!

#3 Analyzing the Motivations to Exchange Value

Practical Steps Guidelines

• Put your selected entities in the same order on the 1st row and column: as an example, the cell in row 1 and column 2 should contain what the entity in row 1 “gives to” (or has the potential to “give to”) the entity in column 2.
• Start by analyzing the value flows between entities of a different type, then move into the same entity types (middle diagonal).
• Not all cells must be full with flows, it may be the case that there’s not much value flowing or potential to flow: this should tell you something!

Suggestions

The Motivations Matrix is a highly divergent tool: you’ll need to map all the current and potential flows of value that you see happening (or potentially happening) between the entities-role. Keep your mindset open to see anything might be interesting and important. This is really a moment in which you listen to your ecosystem: listen to what they’re telling you. What you’re trying to map here is no more than what one entity can “give to” each other.

This exercise will help you let the most important relationships emerge, as we’ll see later: you may well be surprised by some relationships that you didn’t deem “crucial” for your design, but that can emerge powerfully as important.

#Two Examples

Look at the ecosystem of Airbnb:

It’s important to note that, in this case, the ecosystem existed before Airbnb (hosts, guests) but Airbnb helped more figures emerge.

Note that it’s very important to map reputation and feedback exchanges as these are powerful quality filters!

Look at the motivations matrix related to a subset of the ecosystem of prosumer energy production:

We can highlight here a very interesting interaction: that between prosumers and solution advisors. Solution advisors are experts on the specific technology and advise on the best technical and economical solution for the final users. Sometimes Solution Providers have an interest in playing the advisor role to the users, but making the two roles separate can provide a more transparent solution design process, and more competition on efficiency between providers.

You can access the whole example here: “A Platform Design Example Explained”

https://platformdesigntoolkit.com/Example

Three Essential Tips and Tricks

• Don’t ask if something is right or wrong: just map and generate divergence and abundance!
• It’s really important to map any possibility to exchange money, reputation, and feedback as these are powerful engines of value exchange and can drive up quality.
• Just ask yourself “what can A give to B?” and be surprised by the answers

What Do You End Up with?

How Does This Connect with the Rest?

You’ll have a clear understanding of the potential to exchange value in the system, plus an indication of what are the most powerful relationships (where most of the value can flow).

This exercise brings you to identify the initial part of the transactions engine potential: you’ll use the information from the motivations matrix to feed into the Transactions Boards, and consolidate the design of your transactions engine.

#4 Choosing the Core Relationships You Want to Focus on

Once you have your Entity-Role Portraits and Motivations Matrix ready, it’s time for you to start focusing in depth on what part of the strategy you want to first develop. Despite the fact that the ecosystem you’re designing for is - and always will be - varied and abundant (and being alive it will evolve in mostly unforeseeable directions) it’s a good idea for a strategist to find a core focus when developing the first steps of a platform-ecosystem strategy.

It’s important to note that one can unroll a platform strategy in different steps, for example by deploying different experiences within time, all carrying different business models, and target entities. At this moment of your design session, you’ll need to ask: what are the one, two, three key relationships I want to design for? It’s very important to start thinking in terms of relationships because relationships are the roots of the experiences you will design.

Let’s go back into the Prosumer Energy Production ecosystem. Among the many players that we identified, there’s an abundance of possible relationships that are worth exploring. If you focus on the relationship between a Prosumer and a Solution provider, what would be the experience you end up designing? Most likely a “Get Powered and Save Money” (or ‘Setup Home Power Grids’, if I look from the other point of view) experience.

What happens if, instead, you focus on the relationship between a Solution Provider and a Solution Advisor? Most likely the experiences we end up designing will be about local brand ambassadors or finding financing sources for the installation.

To understand what are the relationships worth focusing on is not an easy catch: this will depend on your interests, priorities and existing reach, but also from what the ecosystem tells you about the potential value flows.

As we anticipated above, in the Prosumer energy production ecosystem it may be worthwhile to focus on the relationship between the two sides of the market (Solution Advisor - Solution Provider), ending up designing a professional collaboration experience.

It’s normally a good practice - according to our experience - to pick a triangular set of relationships, and try also to identify a “Core Entity”.

You can access the whole example here: “A Platform Design Example Explained”

https://platformdesigntoolkit.com/Example

The core entity that you’ll identify might be the one you prioritize for: for example the one from whose point of view you'll likely design the first experiences.

It’s a good idea at this point to double check if you've got the Entity-Role Portraits for all the entities you’ve chosen in your core system (especially the “Core Entity-Role”). If you don’t, it’s important to come back to portraying the remaining entities as it will be essential for you in the reality check phase on the potential that your strategy has to generate pull!

We recommend you to read “Design for Ecosystems: Emergence & Attraction“ (see: http://bit.ly/PDT-UG-DFE1) to understand more of how to prioritize entities, and why it makes sense in this open-ended process that is platform design.

#5 Identifying Elementary Transactions & Channels

Practical Steps Guidelines

• Identify the relationship you’re exploring and try to focus on one relationship at a time. We suggest you run a Transactions Board for each relationship you identified in your “Core System” first.
• By looking at the elements emerged in the Motivation Matrix, enumerate all the elementary, atomic transactions you can see already happening in the ecosystem, as well as the ones that may happen if facilitated enough. Think of how you can reduce transaction cost for these interactions to happen in an easier way.
• If two transactions don’t make sense being separated from each other, you can group them (eg: book and pay in advance in Airbnb).

Suggestions

The Transactions Board should help you, once you’re focused on a given relationship, to enumerate all the transactions that happen already, or might happen if facilitated by a platform strategy. One of the key roles of the platform shaper (owner) is that of creating channels that can reduce the coordination/transactions cost. When thinking of improvements you can bring to the channels - for interactions to happen at scale in an easier way - and what components & features should these channels have, try to not stick to software-based thinking. Often reducing transaction cost means reducing unnecessary steps and bureaucracy (think of vanilla contracts, process wizards, offer-templates, payment channels, etc.). Also, it’s a good idea to focus on atomic transactions, because essentially we want to enable them to happen at scale.

Sometimes this exercise may sound awkward and counterintuitive (too simple or at a too low level), or you may end up asking, “what am I designing here?”. The key to understanding this exercise is to understand that your mission here is to identify what transactions & channels already exist, how they can be improved and what new ones you need to create to enable interactions and transactions at scale. Furthermore, this “low level” design exercise will be incredibly useful when assembling the Platform Experiences. It’s also very important to understand that we’re moving from value flows into value units so that it becomes very important to try being specific in describing the type of unit of value that gets exchanged. In this way, we can be precise when envisioning (later) what value/business model we can attach to a certain platform experience.

#Two Examples

Look at the first core of transactions enabled in Airbnb, between the first entities (relationship)

It’s important to note that the Airbnb transaction model, at the start, was extremely simple: this helped Airbnb scale quickly and easily.

Simple transaction engines are quicker to grow: as we explore higher value ecosystems, and more complex relationships we may have to confront more complex interactions.

Let’s look for a moment at the transactions board related to the relationship between the solution provider and the solution advisor in the prosumer energy ecosystem. As you can see here, we’re more or less mapping what’s happening already in this industry: here our mission is more that of understanding how we could improve the channels and how we can consolidate the value units exchanged.

A new channel can be established, enabling ratings and feedback exchange. This is a direct advantage for the consumers, who can finally choose the best suppliers for their needs and select the offering based on their special needs. Of course, on the other hand this would let the best producers emerge, contributing to the improvement of the quality of the services exchanged.

You can access the whole example here: “A Platform Design Example Explained”

https://platformdesigntoolkit.com/Example

Three Essential Tips and Tricks

• Don’t be too restrictive in what a channel is or is made of: a channel is everything that makes an interaction easier to happen (an event? A template document, a contract etc.). Don’t think too much in terms of software (websites and apps), because we know that platforms are not only technologies, they’re mostly about reducing bureaucracy and unnecessary waste so that ecosystems can manifest their potential.
• Try to think in terms of “actions”: a transaction is most likely being modeled as an action/verb.
• Use the arrows to determine the directionality, sometimes transactions can also be bi-directional.
• In the “notes on channel improvement” focus on how the new channel you’re envisioning may positively impact (with a reduction of) the transaction cost.

What Do You End Up with?

How Does This Connect with the Rest?

You’ll have a simple model of atomic transactions, and a list of channels that you’ll need to build as a platform owner.

The Transaction Boards will provide you one type of bricks you will need to combine with other types of bricks, in the constructions of the Platform Experiences.

#6 Designing the Learning Engine

Practical Steps Guidelines

• Place each entity-role using a box on the left column and start exploring how they evolve through the three steps (ONBOARDING, GETTING BETTER, CATCHING NEW OPPORTUNITY);
• After that, imagine how there could be an evolution between different entities-roles: how can a consumer become a producer? How can a peer producer (less strategic) become a partner (more strategic)?

Suggestions

Why do we talk about a learning and improvement engine when we talk about platforms? As we live in complex times, entities in ecosystems are subject to continuous performance pressure. The Learning Engine Canvas provides you a three steps process framework to design services (broadly defined) to support your entities at every step: every step comes with a key challenge - like for users initially: finding the right type of service for their needs - what can you design to provide them with the right aids to overcome the challenges? Focus on one (or few) key challenges for every step, and one (or few) key services. This is where you design most of your platform strategy as an owner: the way you support your ecosystem entities to become the best they can be!

#The Airbnb Example

Three Essential Tips and Tricks

• Practical onboarding steps for consumers are normally: understanding what they can consume (checking the menu), while in the getting better they can explore more advanced consumption patterns (eg: bundles)
• Practical onboarding steps for producers are: explaining to the ecosystem what they can offer (writing the menu!), and getting better normally means offering more complex things, sometimes in combination with others (bundling) or with the platform (eg: badged roles, see Airbnb’s “Superhost”)
• Try to identify connections with consumption and production sides of the marketplace: if you’re lucky to have a potential evolution path that connects the two you may have an internal growth engine!

What Do You End Up with?

How Does This Connect with the Rest?

At the end of this exercise, you will have a structured idea of what kind of services (broadly speaking) should your platform strategy provide to the entities, to allow them to improve continuously.

Learning support services are the other essential set of Lego bricks you will use to compose the platform experiences: this set of bricks is all about the relationship between platform (owners/shapers) and entities, while the transactions are the relational, peer to peer, bricks.

Additional Reads, from Our Blog:

“Why Platforms need to be Engines of Learning”

Despite being a bit old, this post will introduce you to the idea of offering an engine of learning as an answer to the continuous disruptions of the interconnected age.

http://bit.ly/PDT-UG-ELE

#7 Assembling Platform Experiences

Practical Steps Guidelines:

• Give the experience a name, choosing the entity of which you're using the point of view (core entity)
• Use the canvas without restrictions
• Use different post-it colors to identify entity-to-entity and platform-to-entity interactions
• Use post-its to play with the steps so that you can move them around until you reach a good flow
• Explore the business model only at the end, when you can see the full flows of value

Suggestions:

The Platform Experience Canvas, is the tool we use to consolidate most of the previous insights and conversations. To build the platform experience one can use three essential types of bricks:

• The services that the Platform Owner provides for continuous improvement as part of the Learning Engine
• The atomic transactions happening between the entities in the ecosystem
• Further elements of consumable services, functionalities, support services that serve to complement the experience.

#The Airbnb Example

Let’s look at the simplicity of the hosting experience on Airbnb; it all starts with the host onboarding steps (registering, getting a photoshoot) and then moves into the interaction: booking, hosting and reviewing. As you can see, yellow post-its represent interactions with the platform (owner) and blue ones represent entity to entity interactions.

#The Prosumer Energy Production Example

In the Prosumer Energy Production example, by reducing the paperwork, and the friction generated by the lack of clarity on expectations and offerings, we step into a win-win game. The overall installation turnover is increased, consumers are happier since they could evaluate serenely an investment opportunity and hopefully stay in the approved budget, solution suppliers (advisors and providers) can emerge according to their professionality and quality.

In this example, we have a clear transactional business model, since the platform can charge users with a fee per transaction and, for this reason, it’s offering free learning (i.e. free information and guidance) to all the interested parties. This opportunity to learn and improve is a strong attraction point towards the ecosystem and that is why it’s important not to hide it behind a monetary request. On the other hand, it’s possible to imagine different sustainability models: for instance, if the platform strategy focuses on producers, maybe they will appreciate membership-based access to free networking and partnering opportunities, or to curated catalogs of solutions.

You can access the whole example here: “A Platform Design Example Explained” https://platformdesigntoolkit.com/Example

Three Essential Tips and Tricks:

• Describe the Value proposition as something that resonates with the Entity-Role Portrait of the core entities-roles: allowing them to leverage on their potential, to achieve goals and respond to performance pressures, getting relevant gains in the process while expressing their craft.Choose one point of view, in a relationship: keep an eye on the relative transaction board, to pick all the interactive elements.
• Focus on the onboarding and getting better parts of the Learning Engine Canvas: most likely the transformative (getting to the new opportunity) event, will be part of ... just another experience.

What Do You End Up with?

How Does This Connect with the Rest?

You’ll have a tangible sign of your platform strategy: if someone asks you, what’s your platform, a platform experience is a good candidate as an answer. The platform experience is what you want to bring to the ecosystem.

One or more platform experiences will be part of your MVP, and will drive how you build the experiments you want to build (if your strategy is already existing).

#8 Setting Up the Minimum Viable Platform

Practical Steps Guidelines

• Start by defining what are the experiences you want to feature in the MVP.
• Understand what are the key assumptions in these experiences.
• Imagine how you can build the leanest MVP possible, and how this MVP is going to test the assumptions.
• Pick the most unbiased criteria for validation, e.g. testing measurable conversion rates, for example from invitations to a temporary social media group.

Suggestions

Setting up the Minimum Viable Platform is, essentially similar to setting up a Minimum Viable Product: the biggest of the differences relies upon the fact that a platform strategy is an “interactive” product and that the platform value normally grows with the generation of network effects. Normally we suggest validating, as soon as possible, at least the following assumptions: business model, trust and attraction.

Is it clear what the business model assumptions are? (i.e. is the business model actually working?) What is the attraction assumption? (i.e. is the value proposition working? Are the entities feeling the attraction towards the platform?). The trust assumption may be more complex to understand. With trust assumption, we intend every assumption related to moving from consuming a solution coming from an industrial player to consuming a service in direct interaction with a peer. People are used to booking a room in a hotel, but would they travel to a stranger’s house? Apparently yes.

#The Airbnb Example

How would an MVP for Airbnb be if we should prototype it today? We could use a Facebook group and Paypal for escrow payments and make a so-called “concierge” implementation (an implementation of an MVP where you don’t prevent the user from understanding that you’ve built a prototype and that some of the work happens ...manually.)

Three Essential Tips and Tricks:

• Start always by looking at what you have: you may have some resources ready that you can easily combine in an MVP, or just leverage on (eg: a list of contacts)
• Don’t procrastinate the validation of your business model assumption
• Enumerate the assumptions with your team and only after you’ve listed them all, try to identify the riskiest!

What Do You End Up with?

How Does This Connect with the Rest?

You’ll have a clear setup of an MVP, something that you can now go prototype and use for learning if your riskiest assumptions are true or not..

Validating or invalidating the assumptions in the MVP should help you to get back to the design and potentially make different choices. Once your ecosystem-platform fit is validated then you’ll need to think about your growth strategy.

A HANDY DASHBOARD: THE PLATFORM DESIGN CANVAS

Recently, we’ve been using the Platform Design Canvas in an increasingly limited set of cases, in any case less and less as a design tool. We noticed, on the other hand, that our community played with it mostly as either as a tool providing a quick way to recap the ecosystem potential and the platform strategy (some sort of “dashboard”) or to quickly explore platform potential without diving into more

complex processes.

The Platform Design Canvas can essentially be used as a dashboard:

• You can use the PDC to step by step consolidate the insights you generate by using the toolkit into the canvas itself (especially in the steps going from 1 (the Ecosystem Canvas) to 6 (the Learning Engine).
• As an alternative, you can grab a PDC and quickly brainstorm (or map an existing platform strategy) in one single sheet.

The example above covers an early version of Airbnb and is provided for illustrative purposes.