Abstract

It’s been quite a year for Platform Design Toolkit and in general for methodological updates here at Boundaryless. In 2022 we indeed released:

• a new guide and canvases set – the Platform Growth and Product Guide
• one key update to one of the Guides, the addition of the Arena Scan to the Platform Opportunity Exploration Guide
• one new structured framing of what Value Propositions one can build in Platform-Ecosystem settings and a new Canvas that allows you to describe your VPs in this way – the Platform Strategy Model Canvas
• one new update of the 3EO Toolkit now includes an adoption guide to help you embark on the process of unbundling your organization into entrepreneurial, autonomous and accountable teams

In this series of posts, we’ll progressively offer an updated, dashboard-like, view of the Platform Design Toolkit and explain all the modular techniques that make it the most versatile methodology to date to design, experiment and grow platform strategies. We’ll explain how it can be used by designers, and entrepreneurs and also, later on, highlight its connection with the 3EO Toolkit for organizational evolution and with other strategic design and validation techniques that we often use in combination.

---

Let’s start from the basics: what can you do with Boundaryless open-source methodologies? Our methods can help designers and entrepreneurs engage with at least six macro problems:

• Understanding Ecosystems to create the right Value Propositions
  
• Defining the Platform Experience, and Flywheels for Defensibility (this post)
• Defining the Go-To-Market and Liquidity approach 
• Achieving and measuring growth
• Validating key assumptions along the way
• Executing and evolving the organization

To support such work, we use different combinations of our canvases and heuristics: some of these canvases are more mature than others, and some are still “experimental” and will be released in the coming months as we did with others in the past. In many cases, we also experimented with other complementary techniques.

Note that we see these macro-problems as circularly related, and not necessarily to be seen as a step-gated process, we, therefore, assume that a team will have to come back and forth on these problems. We’re currently developing a new experience format called Platform Design Sprint that will be launched in 2023 that will help teams go through these phases on a continuous journey – subscribe here to be kept up to date as soon as the program launches.

Today’s post covers the challenges and techniques related to the second macro-problem, that of Defining the Platform Experience, and Flywheels for Defensibility. The inaugural post can be found here.

To receive timely updates related to the other four macro-problems please subscribe to our newsletter here.

---

Defining the Platform Experience, and Flywheels for Defensibility (MP2)

Macro-Problem Description

This macro problem regards moving forward after a first platform idea and consists of figuring out if it would be possible to design something that: can scale around one or more repeatable interactions around a high-value relationship between different entities, and can soundly generate network effects and defensibility in the process.

What are the key questions you need to answer?

Typical questions one needs to ask in this phase are:

• what are the most important entities and relationships in the reference ecosystem and where should I start building scalable experiences?
• how are flywheels for network effects going to be generated and how is value going to be compounded to build defensibility?
• how can transaction costs be reduced to make interactions more efficient and scalable reducing friction?
• how are entities in the ecosystem going to be onboarded in the platform and how does their path evolve from occasionally and initially interacting into building reputation, growing their potential, and eventually catching transformative opportunities?
• what are the core experiences we’ve to make scalable? and what’s their business model?
• What channels do we need to build?

When you are supposed to work on this

These questions are normally quickly coming up as key for a team. Teams normally come up with a synthetic overview of what is their reference ecosystem and what macro-value propositions they can build often either during a proper exploration phase (of which the related techniques have been explored already in this post) or sometimes after a more informal mapping of the player in an ecosystem that often implies the type of relationship that the platform will be centered around. A good example of this could be mapping the entities around the medical checks ecosystems: you’ll have a doctor, a patient, and maybe a studio rental, and the relationships you’re implying there are likely booking a visit, renting the studio, paying the fees… etc. Irrespectively if your exploration work is solid and based on extensive mapping or it’s intuitive you’ll always have to ensure that you have a convincing growth path (a set of flywheels) that they can build defensibility for the strategy and that you can design a scalable experience around the most important ecosystem relationship, and experience that flows better than the existing alternative (reducing transaction cost) and that gives participants opportunities to learn, improve, develop a reputation and – in the end – catch relevant and exciting opportunities.

What techniques to use, and how can the tools help? 

Three key techniques can be used in this phase:

• Understand Key Relationships and Value Exchanges – through the PSM model, the Ecosystem canvas, and the Motivations Matrix (TQ 2.1)
• Identifying the network effects and defensibility model – by using The Flywheel Sketching Canvas, the Flywheel cards, and the Network properties and NFX Canvas (TQ 2.2)
• Designing the key elements of a platform experience – with the Transactions Board, the Learning Engine Canvas, and the Platform Experience Canvas (TQ 2.3)

Let’s see the details below on how canvases and other tools can help you achieve this.

---

 Understand Key Relationships and Value Exchanges: the PSM model, the Ecosystem canvas, and the Motivations Matrix (TQ 2.1)

Every time we approach the idea of building an ecosystemic value proposition we face the unavoidable complexity of having to deal with a relevant number of user types. To add more complexity the essential unit of a platform strategy is rarely a user but rather a relationship between multiple users. The Platform Strategy Model canvas is a powerful synthetic tool that gives you the possibility to describe up to five users in an ecosystem and, for each of them, quickly describe the “product-side” value proposition (a value proposition that is strictly targeted to such a user) but also graphically represent the relationships that exist between users – and mainly with the user that we define as core, which is normally the principal recipient of our platform value proposition and narrative, around whom the other types of users revolve often as a provider of services, other times as demand generators and sometimes as creators of additional modules that can be plugged in to extend the core product we’re offering to such a “core customer”. 

Before the introduction of the PSM model, to visualize a map of all the user types and their relationships, the Platform Design Toolkit featured the Ecosystem Canvas: the canvas breaks down user types (entities) into three macro categories, peer consumers, peer producers, and partners. This way of breaking down entities has gradually lost significance in the application of the methodology – at least in our direct experience – but it’s always a useful way to see what posture all of the users have towards the platform. For a deeper explanation of the differences one can refer to the Platform Design Toolkit Strategy Guide but in a few words: peer consumers are mostly interested in consuming value while peering producers and partners are interested in providing it, with the latter normally more focused on professionalization. The Ecosystem Canvas can still be a precious resource, especially for those that didn’t perform a full arena-ecosystem analysis and value chain analysis yet as it provides a very visual representation of all the ecosystem entities at a glance with no embedded affordance for focus (which the PSM has by limiting the entities to 5), or definition of who is at the “core”. In any case, it’s important when dealing with platform strategies to progressively select what relationships are the most interesting to intermediate and amplify: the Motivations Matrix – a tool designed to describe carefully what certain entity can “give to” another one – has the capability to let you visualize quickly the intensity of relationships in terms of the value that is (or can be) exchanged. This is very useful, especially in those cases where a proper value chain analysis hasn’t been done yet. We normally use the Motivations Matrix to prioritize the relationships: imagine you’ve identified a system of three entities and therefore you potentially have three relationships among them; with the aim of prioritizing the experiences you’re going to build (around each of those relationships to make them scalable) you can reasonably start from the ones that show the most intensity of exchanged value. Of course, other priority drivers can also be used, for example, the team’s existing domain expertise or leverageable assets. The picture shows how the different cells of the Motivations Matrix can be referred to a specific relationship (two-way).

 

The Ecosystem Canvas and the Motivations Matrix are widely covered by the Platform Strategy Design guide available here while the PSM canvas is a draft canvas not yet finalized and featured inside a guide. In any case, you can find some practical advice on the tools mentioned above in the following posts:

• A Platform Design Example Explained – Boundaryless where you can find an explanation of how the Ecosystem Canvas and the Motivations Matrix can be related and used; 
• Identifying a Platform Strategy Model and its potential go-to-market strategy: a streamlined process – Boundaryless

Implications and dependencies

The PSM and the Ecosystem Canvas can be easily produced as an output of a proper exploration phase – of which the techniques have been previously explored here – but can also be used autonomously, especially when you’ve to make an impromptu evaluation of an ecosystem. Oftentimes starting from who’s part of the ecosystem and what is the value that such entities are (or can) exchange can be very conducive to solid ideas in terms of what relationships should a platform amplify and facilitate and the PSM can offer a handy way to draft out the key idea in terms of product design, and value proposition. Of course, a solid exploration phase ran before prioritizing relationships, and thus experiences to build can give you a more grounded perspective on how value is perceived by the entities in the ecosystem.

---

Identifying the network effects and defensibility model – by using The Flywheel Sketching Canvas, the Flywheel cards and the Network properties and NFX Canvas (TQ 2.2)

Normally after having at least roughly identified what are the key relationships that should be supported by the platform strategy one can start to figure out if these – likely two-sided – relationships can generate growth flywheels and network effects. The basic element of flywheel-based network effects is normally the fact that – in a system where one of the core value creation comes from the possibility to meet the right party to transact – the more entities join the network the bigger the value will be perceived by another entity that joins. Of course, several types of relationships exist but the most recurring are the ones based on the so-called two-sided network effects, characterized by a producer of value and a consumer of it. Sketching flywheels is extremely important to figure out if a platform strategy will have the potential to:

• create a virtuous cycle that reinforces the perception of value super linearly as new players join the network
• create additional defensibilities on top of the basic network effect, due to economies of scale, brand perception, data or technology advantages, and more.

This information can be extremely useful in the early stages of the construction of the strategy for both operational reasons and communication reasons. Operationally speaking, understanding the key mechanics of growth can provide a great guide in terms of priorities for the development of the initial prototypes, while from the perspective of communication, it can be fundamental to identify the potential for growth and defensibility and thus create a convincing message for investors.

The flywheel sketching canvas is part of the Platform Growth and Product Guide we recently launched where you can find a comprehensive explanation of all core and advanced flywheels. The importance of the flywheel sketching in relationships is also partially covered in the following post:

• Identifying a Platform Strategy Model and its potential go-to-market strategy: a streamlined process – Boundaryless

As a follow-up to the flywheel analysis, one can pick each of the two-sided relationships envisioned and characterize the relationship further. Thanks to the Network Properties and NFX canvas one can in fact characterize each relationship along seven key properties and identify how such properties are expected to impact the behavior of the network effect, either reducing defensibility or as we’ll see in a later post, impacting the approach to building liquidity.

For example, a relationship where the supply is rather commoditized may imply that network effects are “asymptotic” meaning that – at some point- adding more suppliers doesn’t improve the perception of value. An exemplary case is that of Uber: once you have a density of drivers such that a driver can come and pick you up in a reasonably short time, adding more drivers would just make their experience worse (more competition) and yours as a rider won’t change much.

Network properties can be analyzed at any stage of development: they’re rather a characteristic of the underlying relationship than the platform-mediated experience. For example, in a ridesharing environment, the fact that a driver can serve many riders (asymmetric) is a given of the type of relationship and service process, not of the platform that intermediates it.

An introduction to Network properties and to the NFX canvas can be found in our Growth Guide around Page 57 onwards.

Implications and dependencies

To be able to sketch a platform’s flywheel one needs to be able to understand the basic mechanisms of value creation. It’s certainly possible to sketch it even with just a map of entities and an understanding of the key relationships (e.g. I want to build a platform for trainers to be able to connect with trainees on one side and gyms on the other) although if one has an understanding of the services and product bundles that are also going to be built and the key mechanisms of transaction cost reduction, and continuous learning, this can provide hints for additional defensibilities. As an example let’s assume we’re building a platform for medical professionals to connect with potential studio rentals real estate and patients, and that as part of the solution we will provide a centralized purchasing service for medical supplies and a rental service for diagnostics machines, we can see how such a service could generate a strong lock-in for both the studio provider and the medical professional due to the complexity of managing rentals and medical supplies purchasing on their own. Therefore, having sketched the PSM (potentially after a full value chain analysis) can be quite insightful before sketching the Flywheel and understanding the properties.

The growth flywheel on its own is a core element of platform strategy and is prophetical to the launch, go-to-market, and growth phase as we’ll see in the upcoming post on “Defining the Go-To-Market approach and achieving and measuring growth”.

---

Designing the key elements of a platform experience – with the Transactions Board, the Learning Engine Canvas, and the Platform Experience Canvas (TQ 2.3)

Platforms are known to be highly scalable systems where interacting entities can develop their reputation around a certain task or transaction, improve continuously and potentially catch emerging development opportunities. The key questions we should be asking ourselves when moving into prototyping something more tangible such as an MVP (Minimum Viable Platform) is: “How do I design the scalable experience?”

So far we’ve seen how ecosystems are essentially systems of intertwined mutual relationships, and how important is to have even a rough idea of who are we mobilizing, and what value exchanges can happen. When moving into a more tangible expression of a platform strategy (essentially our own way to organize, augment, and empower the ecosystem) we’ve to think in terms of what experiences we want to build. Platform experiences are indeed what you bring to the market (or ecosystem) and a platform strategy can be essentially described and recognized as of sum of several experiences. As an example, Airbnb can be seen as a sum of

1. booking a room or house 
2. booking an experience
3. selecting and enabling a co-host,

and a few more. These experiences are similar to “use cases” and are normally brought to the market incrementally (for example, Airbnb started from the 1 above and then extended to 2 and 3). Each experience has its own flywheel and they can be composed to create a reinforcing flywheel effect: for example, a new traveler joining Airbnb to book a room will automatically become a potential experience guest and every host a potential co-host. 

Designing the experience

A platform experience can be described as a sum of an interactive user journey where different entities interact between them and with the platform, and its business model. Generally, a business model should be attached to an experience, especially given that – in platforms – business models are often based on take rates that are eminently attached to every single experience. As the reader might recall, we define three major components of a platform strategy: the product/service bundle targeted to a core customer (often the provider in the ecosystem), one or more marketplaces connecting the core customer to its supply or demand, a so-called extension platform, connecting the core customer with third parties developed extensions of the core product such as apps, plug-ins, templates. A platform experience is essentially the way we intentionally describe the interactive experiences, normally related to the marketplace and the extensions. One can design a platform experience to describe for example how:

• buyers and sellers find each other, negotiate prices and book a certain service;
• app developers publish their apps and customers pick them and deploy them into the core product
• a consumer books service in a managed marketplace where the platform picks the provider

In Boundaryless’ framing of Platforms, we’ve always identified two essential pieces of a platform experience. It needs to reduce the transaction cost that would exist in a non-platform mediated experience (as it’s normally available in the ecosystem before the development of the platform) and create engines of learning to allow every party involved to learn, and improve based on supporting services, for example, onboarding, coaching, infrastructure provisioning, publishing, training and more.

By mixing up elements of transaction cost reduction and continuous learning we can create great platform experiences: as one can see below the transactions board normally provides the “interactive” experience bricks (in blue, transactions) and the learning engine canvas can provide hints on the essential services that need to be created to sustain the journey. Of course, if you’ve gone through the Arena and Ecosystem Scan technique you should always look back into what you mapped as existing in the ecosystem (likely you’ll find a lot of hints re what transactions do exist in an unmediated ecosystem) and use it as an inspiration for the transactions board. Clearly, the learning engine canvas depends less on what you can map in the ecosystem cause it’s more focused on the role of the platform itself: the learning engine canvas can offer powerful complementary insights to the PSM which is more focused on the substantial elements of product you’ve to build. In a few words, a platform experience is a mix of interactive Peer To Peer transactions (in blue) and platform-provided steps (in yellow). The latter can be either elements of the product/service bundle or elements of the learning engine, focused on driving the entities in the platform through the three fundamental steps of onboarding-getting better-catching transformative opportunities. While the elements of the former (the P/S bundle) are normally strongly hinted by value chain analysis – where the application of Wardley mapping powered by platform play helps identify the key features that need to be packaged into the P/S bundle (see here for more details) – the latter is more a fruit of a creative analysis of how we can respond to the progressive challenges that the entity faces as it progresses through the platform.

The Transactions board, the Learning Engine Canvas, and the Platform Experience Canvas are both widely covered by the Platform Strategy Design guide available here while the PSM canvas is a draft canvas not yet finalized and featured inside a guide. In any case, you can find some practical advice on the tools mentioned above in the following posts:

• A Platform Design Example Explained – Boundaryless where you can find an explanation of how the Ecosystem Canvas and the Motivations Matrix can be related and used; 
• Identifying a Platform Strategy Model and its potential go-to-market strategy: a streamlined process – Boundaryless
• Apply Value Chain Analysis with Wardley Maps to identify a Platform Opportunity – Boundaryless

 

Implications and dependencies

The consolidation of a set of Platform Experiences is a powerful way to close a design phase and make yourself ready to prototype. The natural step that having the Platform Experiences sketched out enables you to do is prototype an MVP. After the MVP gives you solid feedback that a platform-ecosystem fit exists (see this post for more info) you can extend the design of the platform experience with more traditional service design tools (such as more detailed customer journeys, service blueprints) or a deeper understanding of the business model implications that can also prepare you for more detailed analysis of your pricing strategy, that you can do through the business model canvas and similar tools.

In some cases, we’ve also used a complementary practice called Eventstorming as a tool, an alternative to the platform experience canvas, to design the actual experience we wanted to build. Eventstorming is one of the most adopted practices in DDD (Domain Driven Design) and can be used to construct a detailed description of an experience that is easier to translate into a software development implementation and backlog (more soon on this).

---

Conclusions and next steps

In this second release of a series, we expanded on the second of five macro-problems that platform entrepreneurs have to approach when developing a platform strategy and bringing it to market. These macro-problems are:

• Understanding Ecosystems to create the right Value Propositions
  
• Defining the Platform Experience, and Flywheels for Defensibility (this post)
• Defining the Go-To-Market and Liquidity approach 
• Achieving and measuring growth
• Validating key assumptions along the way
• Executing and evolving the organization

For the second one Defining the Platform Experience, and Flywheels for Defensibility, we show in this post three key techniques that can be used. These techniques are scarcely dependent on each other and can be also used singularly while some interdependencies exist that facilitate adoption.

The first herein the coming weeks, we will release three more posts, focused on the other 3-macro problems. You can find the first installment on Understanding Ecosystems to create the right Value Propositions here.

To stay tuned on:

• the release of four further deep dives
• updates on the new techniques we use and are releasing, especially regarding validation
• the release of the Platform Project Work Board (a digital tool that will allow you to track your work project-wide)
• and the opening of the inscriptions to the Platform Design Sprint, a new format where we will help you adopt these techniques to bring your own project forward

Subscribe to our newsletter here