Apply Value Chain Analysis with Wardley Maps to identify a Platform Opportunity

Abstract

In this post, we share our latest advancements in the integration of Wardley mapping with our Platform Design Toolkit, and more specifically our Platform Opportunity Exploration part of the framework. In an upcoming webinar on May the 10th at 1:00 PM GMT featuring Wardley Mapping expert Ben Mosior we will explore further these topics.

Feel free to reach out if you have any experience to share: we always keep our users posted with our methodology’s progress, therefore subscribe to our newsletter if you don’t want to miss a thing!

The first framing: C to Z-shape and the Six Platform Plays

It’s since 2018 that we research to create an encompassing theory of how Wardley Maps – definitely one of the most powerful existing techniques for understanding value chains, and articulating business strategies – could interoperate with our Platform Design Toolkit and be helpful for those of you into developing platform-ecosystem strategies.

In 2018, our integration of Wardley mapping started from a premise: platformization is about transforming existing value chains, to provide a way to run scalable business operations while at the same time avoiding sacrificing the personalization that is typical of the artisanal, pre-industrial tradition of business: services and products produced by “platforms” could be at the same time bespoke and sustainable at scale (from a business perspective).

The great assumption that was behind our early understanding of platformization was centered around acknowledging how allowing personalization, the expression of long-tail economics is important for users. When users dramatically value user-level personalization of experiences – something that is impossible to provide from an industrial standpoint (bureaucratic players are optimized for mass production and planning for risk reduction) – platform strategies offer a way to empower players to self-organize contextually around problems and solutions, instead of trying to serve customers with an “average” solution that instead of proverbially “fitting all” rather doesn’t fit anyone.

At that time, in 2018, the focus of the platform economy seemed to be on pretty much all marketplaces: playing the role of the aggregator was everyone’s focus. The aggregation opportunity seemed too attractive to not be prioritized: the promise was to run an asset-light business that could let go of owning inventory and controlling suppliers and instead focus on aggregating demand and supply, playing a hub and spoke model, taking a cut of the transactions.

We identified how industrial value chains could be abstracted through a fairly simplified (probably simplistic) C-Shaped structure, in Wardley map terms, and how applying the recurring value chain transformations (that we identified in Six platform plays) could characterize, even visually with the aid of a Wardley Map, the transition from a pipeline organized market (with industrial incumbents) towards a platform enabled market characterized by a marketplace.

We abstracted the shape of an industrial Value Chain in the following way:

• a fairly commoditized user and user need (after all, with industrial players “you can have any color, as long as it’s black”);
• a series of custom built (unique) key elements of a business, mainly distribution, purchasing, quality warranty, and business process (slightly more evolved according to the trends of Business Process Outsourcing);
• all relying on fairly productized, modularized, commoditized suppliers, and resources (all substantially hidden from the customer).

We knew already that not all industrial industries fit perfectly into the picture (for example one could argue that, in the context of FMCG/retail, distribution is a product), but this overall structure served us as a good reference for what to expect by mapping incumbent industries.

The Six Platform Plays

Our library of Six Platform Plays included the most recurring transformations we saw platform players apply repeatedly. A synthetic description of the six platform plays follows below, and really looks like the Airbnb playbook:

• PLATFORM PLAY 1 (PP1): provide the possibility for the consumer to receive a fully personalized customer experience;
• PLATFORM PLAY 2 (PP2): bring producers on top of the value chain, consider them as actual users, and give them full visibility without “proxying” them;
• PLATFORM PLAY 3 (PP3): apply standardization and streamline otherwise unpredictable and complicated transactions to ensure that producers and consumers can interact at scale;
• PLATFORM PLAY 4 (PP4): embed the otherwise complex pieces of a fragmented business process, into a simple to execute set of workflows, and provide them through a “Software as a Service” pattern or more generally as a service bundle;
• PLATFORM PLAY 5 (PP5): enable participants to use their unique identities and capitalize on their reputation on both sides or at least on the supply side;
• PLATFORM PLAY 6 (PP6): aggregate supply and demand into a marketplace providing at least filtering, and booking capabilities.

By applying the six platform plays in their entirety, we argued, one would be able to envision how an industrial (c-shaped) value chain could be transformed into a marketplace-mediated, platform-organized value chain (z-shaped) a la Airbnb.

Adaptations of the original framing

We later integrated – mainly inside our 2020’s New Foundations of Platform-Ecosystem Thinking whitepaper – some of the key elements of the more recent evolution of the platform industry. Most specifically, we integrated in our thinking the progressive emergence of different approaches to marketplaces, according to the affirmation of two main trends:

• verticalization with marketplaces moving increasingly into more specialized contexts thanks to an increasingly connected number of users making smaller market niches more interesting;
• the reinforcement of managed marketplaces (see for example this research update) with marketplaces progressively re-bundling key pieces of the stack to ensure to deliver a real “step function” in the experience for the customer (see below).

In our recent “Value Propositions in Business Ecosystems – Products, Marketplaces, Extensions” we deeply explained the gradual “rebundling” of the marketplace stack, therefore we suggest the reader check it out.

As said, this work has been covered widely on our blog and Chapter 1 (“Marketplace Pervasivity”) of our 2020 Whitepaper contains a clear description of how this value chain shape can slightly change based on the marketplace-platform nature (see below and refer to deepening box 1.2).

How we practically used this technique

The Platform opportunity exploration guide updated in April 2021, includes a clear process that explains how to use Wardley Maps as part of the Platform Opportunity Exploration stage, and in this post, we want to offer a complementary review of how we’ve been using it learning along the way.

The first step we normally take when we approach exploration relates to defining the Arenas. We recently shared a couple of posts on defining arenas and ecosystem scop:

• the first one, Defining the Ecosystem Domain gives an overview of how ecosystems can be broken down into smaller pieces;
• the second one and more recent Adopt Outcome Driven Innovation and the Jobs to be Done framework within Platform Design gives a little refinement, and frames Arenas as so-called “systemic jobs” where multiple entities cooperate to achieve shared outcomes.

We’ll write more soon about how we are integrating the Jobs To Be Done theory and PDT, but this is the key point: we tend to look into the ecosystem as a composition of various arenas that represent “systemic jobs“, and once a breakdown of the arenas is set, we produce Ecosystem Scans of all the arenas.

Ecosystem scans are used to identify and collect all the information a team has with regards to the current interactions happening in the ecosystem that is the target of the strategy: ecosystem scans help map elements according to three key layers, the long tails of interacting entities, brokers and mediators, and used resources and components. This mapping helps to create the basis of information that is later used to fill up the Wardley map.

A key question that always comes in once there is: how many Wardley Maps to use then? But the question should rather be about how many value chains we see emerging: some of the heuristics we are using at the moment follow.

• Make a Map for each Arena: as arenas are “self-contained” substructures it may make sense to start articulating a platform value proposition inside each one of them. After all, the application of the Wardley Map is targeted to getting a first grip of the combined set of value propositions we can build: what product side and for whom? What type of marketplace? What extension platform? If you’re not familiar with these three key elements of the value proposition for platforms check this post out.
• Make a Map for all arenas that share the main entities: let’s never forget that a Wardley Map starts from a user, and so does a value chain, so sometimes picking and coupling arenas that share the key users (producers, consumers) may be another good starting point.

It’s always important to keep in mind that platforms tend to privilege simplicity and graduality. Airbnb didn’t launch its combination of different marketplaces and services all at once, it started from a very basic arena and interaction: booking a stay. It didn’t deal from the start with what you would do once there – as it does now with experiences – or with booking flights or deciding where to go for holidays. It was rather focused, a strategy that normally pays off when starting.

Once we’ve picked the arenas – or better the ecosystem scans pertaining to the arenas we pick – we normally start building our Wardley Map (or Maps).

What information does a typical Wardley Map of an existing arena (non yet platformized) offer? How to apply the Platform Plays then? A step by step guide to proceed along this process is provided in our Platform Opportunity Exploration Guide (more specifically on page 39) and you can leverage the guide to understand practically:

• how to extract information from the scans;
• how to populate the map;
• how to apply the platform plays.

Therefore in this post, I want to indulge more in the strategic considerations on the platform-product strategy one can extract and how they are reflected by and prompted by the maps.

What to bundle up in the product side?

The first key question we want the Wardley Map to help us answer is always that of what elements need to be integrated into the product side of the value proposition of the platform. You’ll have to roam the map and try to understand what are the services, and products that the existing players in the pre-transformed market are using to deliver their own value proposition.

Those elements are good candidates to be embedded in a product/service bundle (typically a SaaS) that you would then provide to the “producers” in the market.

By bundling enabling services up, depending on the stage of the market we’re looking to “platformize” we can:

• help suppliers overcome an existing gatekeeper that is hiding them from direct contact with the customers; this is the typical situation of building a DTC (Direct To Customer) alternative to a retail-mediated market, and such a pattern can be also seen in how Booking.com and other OTAs (Online Travel Agencies) have enabled independent accommodations players to compete with capital intensive Hotel chains;
• (in a market that may not be characterized by gatekeepers, but where suppliers still have to face capital intensive infrastructurization or even the need to manage a highly fragmented suite of support products and functions) empower more players – and ideally nicher ones – access the market more easily to deliver niche VPs.

In the context of the analysis of this product/service bundle will also be important to understand what complementary, ancillary services and products are being used on the top and in a combination of the core ones. These elements can give a precious hint towards understanding what a potential “extension-platform” strategy may be that complements the core functionalities that we’re keen to bundle up in the product side. These complements will qualify as great plug-ins for a standardized SaaS or service pack. Especially when these complements are highly valuable but have a hard time reaching the market an extension platform strategy needs to be taken into account: providers of such solutions will often be eager to integrate with your platform on the promise that your platform strategy can bring them more high-value customers.

What transactions should be streamlined?

The second key question to ask is: what are the transactions that are currently unoptimized, leaky, or fragmented? This is a key difference from the element identified above: these are not services and products being used by the producers – being them on industrial incumbent or many unorganized providers – but instead, we’re talking about transactions happening between consumers and the producers.

Normally in an industrialized market dominated by industrial incumbents transactions may be highly proprietary while in the situation where the market is characterized by many fragmented producers transactions may be fairly standardized already although complicated to manage and disconnected, and depending on elements and services that affect cost predictability, speed, and may depend on geographies (a different way of transacting may be needed depending on where you are – think pre-uber taxis) or product categories (different transaction depending on what you’re buying). At the end of the day, these high-transaction cost transactions will oblige customers to accept sub-optimal experiences and producers to invest time and money in getting things sorted out: these transactions are certainly the most suitable for standardization and incorporation into a marketplace pattern.

In our public example dedicated to the market of solar capacity installation, we explain how a key transaction to standardize would be that of “integration of solar capacity” (PP3 below) into the utility network: this is a process that normally takes a long time, and deals with bureaucratic players and documentation; providing a flawless and standardized integration – likely by creating a dedicated partnership with one or more utility providers – of the newly developed solution would constitute a substantial upside to all the players involved.

What considerations to make on the lower value chain layers?

Finally, the last “area” of the Wardley map where we usually devote more attention, during and after the application of the platform play, is the lower level of the map, the most distant from the user. These areas normally will contain poorly enacted standards or de facto ones, basic building blocks, operating system layers, and other commodities. It’s important to assess what roles such layers have as they may have strong ties with go-to-market.

For example: let’s imagine we’re building a platform strategy around services for video production of events. Most likely, in the lower part of the value chain, you’ll have typical software solutions, certain A/V standards, etc…

These pieces lend themselves to be either:

• as said before, connected with the transactions engine and product engine: integrating access to such commodities that otherwise can require relevant effort and thus waste, with respect to the value that they actually bring to the experience, will be a powerful driver of value perception in the users (imagine integrating native support for certain A/V standards in the SaaS for video production mentioned above);
• integrated in an open specification, a protocol, and modules constituting an operating system that can be used to drive adoption of the product being developed above: think of what Google did with Android, creating a de facto open source standard for handsets.

In the illustration below, you see a typical result of a first round of Wardley Mapping an existing space: in yellow we highlight the recurring set of fragmented products and services being used, suitable to be bundled in a SaaS or similar offering, while in red, the typical position of the poorly enacted standards or de facto ones, basic building blocks, operating system layers and other commodities.

Below is a screenshot of a Wardley Map from a real case, as you can see these are the typical dynamics.

Addressing and leveraging strategically such enabling, and low layers is opening up to the new possibilities emerging with the our gradual understanding of web3.

We described how to enact a strategy leveraging the interplay between a protocol layer and the platform layer in a recent post (a strongly suggested read) and we’re keen to think that the future of platforms will entail a much higher tendency towards adopting common low layer protocols, that to some extent bring ontologies with them. This is now more achievable due to the affordance of the blockchain, which makes it possible to create permissionless and untamperable data layers. The threat of a centralized player first providing and then discontinuing API-based access to a data layer representing a certain domain and state (Twitter is an examplary case here), has represented for ages a limitation of the ecosystem’s freedom to innovate.

Once this threat is removed – thanks to the nature of blockchain-based protocols – the case to build on shared standards, data spaces makes a lot more sense, especially when such layers achieve substantial adoption. The emergence of cooperatively governed DAOs that manage such protocols and provide collective decision-making contexts for users to participate also in participatory domain specification also makes it possible to converge at an ontological level allowing more players to intentionally decide to develop on top of shared ground. This all makes sense from a point of view of conservation of attractive profits:

“When attractive profits disappear at one stage in the value chain because a product becomes modular and commoditized, the opportunity to earn attractive profits with proprietary products will usually emerge at an adjacent stage.”
Clayton Christensen

We can imagine that if an ontological model and a common data layers can be trusted, developers will strive to build value at higher layers of the value chain, thus building platforms on top of the protocol, and creating their defensibilities through network effects and aggregation at the marketplace level (when possible), or through other defensibility strategies such as embedding (into the user’s business process). This push for ontological convergence could be also dictated by emerging requirement for increased efficiency and efficacy for such platforms in a context of a society facing inflation, and peak of resources.

Conclusions: more work on our Platform-Ecosystem’s Value Chain analysis technique is due

This recap, on how and why we use Platform-Ecosystem value chain-analysis techniques it’s good to give readers a stronger understanding and a few hints into practically using these techniques that often prove to be a hard catch, especially for first timers.

On the other hand, a series of new trends (web3 is exemplary) will influence our framework, and we’re working to frame into additional platform plays. Here are a few that we believe are going to be crucial to be analyzed:

• Embedded Finance: playing an increasing role in transactions standardization, and enriching transactions with additional value, by leveraging on embedded insurance, instant credit, and more;
• Web3: as anticipated above, Web3 will be essential in the process of standardizing ontologies and domain models, commoditizing data layers, and will reshuffle how we value information, potentially making it more scarce (as transaction costs for writing on blockchains are typically higher) but at the same time crucially enhancing the value of it from many other perspectives, including trustability, reach and sovereignty. We expect web3 to also impact other key elements of our value chain framing, including identity and reputation, and general inter-platform interoperability. This will have profound impacts on what pieces of a platform strategy will make sense to differentiate, own, and invest upon. The third direction of impact of Web3 will be that of embedded ownership and decision making, with the penetration of the DAO model mixing up organization and business model in unprecedented ways.
• Organizational unbundling: this latter point is connected to the above and regards the trends we’re seeing in terms of convergence on organizational models based on small units more easily contracting between them even across the boundaries of organizations. As we will see more interoperability at the ontological and technological layer, organizational models will have to fit into this new reality, and DAOs can represent a new frontier of organizing that incumbent organizations will have a hard time ignoring.

An upcoming webinar

We will explore these and other trends and put our whole framework into question during an upcoming webinar on May the 10th 1:00 PM GMT with me (Simone Cicero) and Wardley Mapping extraordinaire Ben Mosior – check out the links to access the streaming of the webinar here, and stay tuned for upcoming toolkit releases!

Are you curious about developing mastery on the application of such techniques, accessing our beta tool releases, and more?

Join us at the upcoming Platform Design Bootcamp in June:

https://boundaryless.io/event/online-platform-design-certification-bootcamp/

Before You Go!

As you may know, everything we do is released in Creative Commons for you to use. In case you’re getting value out of these reads and tools, we encourage you to share with your friends as this will help us to get more exposure, and hopefully, work more on developing these tools.

If you liked this post, you can also follow us on Twitter, we normally curate this kind of content.

Thanks for your support!