Abstract

Last year has 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

Subscribe to our newsletter if you don’t want to miss a thing!!

---

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
• Defining the Go-To-Market and Liquidity approach (this post)
  
• 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 third macro-problem, that of Defining the Go-To-Market approach. 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 Go-To-Market and Liquidity approach (MP3)

Macro-Problem Description

This macro problem regards moving forward after a first platform idea has been evaluated and tested (possibly with an MVP) and consists of figuring out how to define the target market type and size, progressively trying to achieve scale around one or more high-value relationships between different entities

What are the key questions you need to answer?

Typical questions one needs to ask in this phase are:

• What are the key characteristics of the marketplace I’m trying to scale?  
• Should I go “vertical” or “horizontal”?
• What are the “canonical units” of liquidity (meaning the contexts where progressive liquidity should be created) of my platform/marketplace strategy?
• What side should I focus on?  
• What tactics should I use as I approach the launch (solving the chicken-egg problem)?

When you are supposed to work on this:

Key questions on approaching launch and Go-To-Market techniques come for a team partially before Problem-Solution fit (at the very, very early stage) and partially after. More specifically, it’s advisable for a team to understand the structure of its market and network at the earliest stages even before MVP as some of the characteristics of the market pre-exist your strategy, and are related either to the opportunity (the incumbent competition) or the nature of the relationships underlying the network. Certainly, understanding the characteristics of the market and prioritizing the launch context is essential after MVP and is a key challenge of the passage between Problem-Solution fit and Product-Market Fit.

The question about the potential to develop a horizontal or vertical marketplace and the inherent structure of “canonical units” (the multiple contexts where liquidity will need to be sought progressively) should be addressed as soon as possible cause they give indications on how to constrain the initial market for testing the liquidity. In marketplaces, product, and liquidity (thus go-to-market) are notoriously difficult to untangle: an illiquid marketplace will never be able to deliver the product promise. 

After Problem-Solution fit is somehow demonstrated and you’re heading towards demonstrating Product-Market Fit or more generally proving your growth hypotheses: then a new class of challenges exists that is more technical and tactical. Choosing the tactics to launch in the initially constrained market, and spilling over initial liquidity to other areas or categories will be crucial to get the ball rolling and demonstrating you can successfully grow. 

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

Three key techniques that can be used in this phase are:

• Understanding the marketplace type, breadth, and properties: with dedicated heuristics  TQ3.1
• Understanding how liquidity can be built with the Liquidity Canvas TQ3.2
• Choosing growth tactics with the Growth Tactics Cards and Cheat Sheet TQ3.3

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

Understanding the marketplace type, breadth, and properties – with dedicated heuristics (TQ 3.1)

Platforms and marketplaces are all different but certainly fit in some categories, boxes that – if identified – can help us tune our approaches to go-to-market. Let’s assume that – as a starting point to this phase, before asking questions about how to approach the market – you’ll have a definition of the product value proposition. We can reasonably assume that you can describe your “platform idea” as a mix of a core product bundle that you plan to offer to your “core customer”, potentially reinforced by a number of “scalable” relationships that can be powered through a marketplace, a “transaction engine”. 

These would possibly be:

• the relationship of your customer to her own service providers (or suppliers more in general) 
• the relationship of your customer to her own demand
• the relationship of your customer to independent software vendors that can develop extensions to your product 

Of course, not all of these need to be present together – and indeed it’s very rare to see one that could fill in the whole three. One example could be Shopify: 

• the “Shop” app, can generate demand for its core users 
• the core product is the e-commerce stack 
• that core product is extendable with apps 
• the expert marketplace connects core users with their suppliers

If you are unfamiliar with how to get there (your Platform Strategy Model and possibly more detailed abstractions of the platform experiences you’re seeking to build), read the previous two installments on techniques to explore the market and define the platform experience.

The first thing you’d need to think about in such a phase is that each of these “marketplace” interfaces (between core customer and service providers, between core customer and demand, between the core customer and ISVs – Independent Software Vendors) represent a certain marketplace-related network that has its own characteristics.

As you “design the experience”, you’ll get help from your early validation, to gather the contextual signals that will tell you how the experience of transacting on the marketplace should be enacted. There are three major types of marketplace experiences according to Josh Breinlinger:

1. Marketplace Picks: In this type of marketplace, the platform itself selects and endorses products or services, ensuring quality and relevance for the buyers. This model relies on curation and quality control by the marketplace.
2. Buyer Picks: In this type of marketplace, buyers have the freedom to choose from a wide range of products or services based on their preferences. The marketplace focuses on providing a variety and options, allowing buyers to make their own selections.
3. Double-Commit Marketplaces: This type of marketplace requires both buyers and sellers to commit to the transaction before it takes place. This model increases trust and reduces the risk of transaction failure, as both parties have a mutual interest in a successful completion.

Despite things can change widely depending on the context, and your objective during the validation should be that of assessing the expectations of the parties involved, there are recurring patterns of marketplace type depending on the marketplace interface you’re creating. 

For example, is rather unusual for an extension marketplace (connecting ISVs to your customer through plug-ins or apps for your SaaS for example) to not work as a buyer pick: we cannot really think about the platform “choosing” what applications a customer should use. This choice will be rather based on the customer’s ancillary needs to complement the core product functionality. Also, an ISV doesn’t explicitly need to “accept” to let a customer install an app such as in a double-commit.

 

As we’ll see in another upcoming piece, understanding the characteristics of each of the marketplace interfaces you’re building (or you want to build, step by step, likely starting with one) is useful to choose the right metrics to measure and even some tactics to solve the liquidity issue. Each of those networks of relationships indeed needs to be launched separately and you’ll need to reach liquidity for each of them. 

So what? Moving into launch

As a short reminder for the reader, let’s recall what liquidity is in the context of a marketplace (an interface between supply and demand). 

Marketplace liquidity refers to the ease with which participants in a marketplace can find and complete transactions with one another. In the context of an online platform or marketplace, liquidity is often associated with the balance between the supply (sellers, products, or services) and demand (buyers or consumers) sides of the marketplace. 

A high level of marketplace liquidity typically means that buyers can easily find the products or services they are looking for, while sellers have access to a large pool of potential customers. This balance results in a higher likelihood of successful transactions and a better overall experience for both buyers and sellers.

After these initial steps, you’ll know how your product design works and how your marketplace interfaces are supposed to work. Most likely, your marketplace functionalities are an important complement to your product side (if any), and therefore your first problem in launching your product on the market – or more generally growing it besides the initial early problem-solution fit – will be to make the marketplace liquid. As we said already, always consider that if you’ve multiple marketplace interfaces you’ll have to seek liquidity for each of them, one by one. For example, the liquidity on connecting your customer to her demand is a different problem than the liquidity on connecting your customer to her suppliers albeit they can be related because it would be certainly easier to achieve liquidity on a second marketplace interface. Think about how Airbnb launched experiences after short room rentals, targeting the same customers and thus having a headstart with liquidity.

Vertical or Horizontal?

One of the first questions that emerge as teams move to tune the design of the experience and seek liquidity (the two are interrelated) is often that of understanding if the platform should aim for the “horizontal” (larger numbers, more generic transactions) or “vertical” (possibly smaller numbers, but more specific transactions). Normally the heuristics we use in this phase are the following.

Are there horizontal players? If yes, how are they faring?

If there’s a horizontal incumbent that doesn’t mean you can’t target that market. As Sarah Tavel explains in her essay on “white spaces” there are several ways you can approach a market where an incumbent exists. One approach is to redefine what she calls the “atomic unit of supply” by exploiting an existing issue with the incumbent. In this case, according to Tavel you can redefine the core interaction with the aim of “dramatically expand the addressable supply”: an example that Tavel makes is that of Airbnb expanding and leapfrogging Homeaway by adding new categories to the short-term rentals (rooms) vs the existing supply (entire homes) and still manage to target a horizontal market. 

In some other cases – always according to Tavel – you can effectively disrupt the incumbent marketplace by offering a far superior experience solving – for example – trust issues that – if solved – can unlock a vast superior market opportunity: the example here is GOAT that successfully targeted a market where authenticity concerns weren’t addressed by eBay.

In other cases, the value in the vertical part of the business process is just massively broader and hasn’t been identified yet by the incumbent. Tavel suggests that one looks into the vertical categories that are being served with a low NPS as a good signal of this.

 

The picture above depicts an after all quite good opportunity to expand in the vertical but you’ll rather have to deal with a situation where the horizontal marketplace could be fragmented into several verticals that have a broader specificity. 

A market with this shape though would make it rather difficult for you to spill over into other verticals: in this case in fact, rather than having different categories you may be dealing with different thin vertical spaces. This would leave you with the need to expand your capabilities to serve the vertical you choose more deeply, typically by creating additional services that can cater to the specificity of the vertical market more strongly, at the same time generating further opportunities for monetization.

Clearly, depending on the marketplace interface you’re exploring, the idea to go vertical or horizontal and the considerations we made above are different. The considerations on exploring the breadth of the market are easily applicable to a Seller to Buyer interface (Core Customer to Demand) which is the traditional scope where marketplaces have reached the market. 

Such a set of heuristics would also be partially applicable also to the Seller to Service Provider. In the latter you can decide how to tune the services or product access you facilitate for the professional: for example let’s say you’re building a marketplace to serve professionals in the home construction industry, focusing either on sourcing hardware parts and materials or finding ancillary professional services (eg: architects) may imply substantial changes in strategy. 

When thinking about the Core Customer to ISV, typically you won’t have much thinking to do but rather analyze what tools your customers are using in parallel and combination with yours and try to integrate them intentionally at first. Over the long run, with extension marketplaces you’ll have to create self-service extension programs that the ecosystem will populate autonomously: rather than you choosing them, the ecosystem will help you “sense the future” and tell you the direction where new apps should be created or onboarded.

 

We’ve explored a bit more deeply the Core Customer to ISV relationship and “what goes into your extension strategy” in our The 4 Key Problems that hinder growth in Platforms and Marketplaces where you can find more on the topic.

Implications and dependencies

This work of understanding your marketplace characteristics, and the properties of the market you’re targeting can be executed at any point in time. Having a deeper understanding of the experience you want to create (see MP2 – Defining the Platform Experience, and Flywheels for Defensibility) can help you be more specific about your market segmentation but many of the underlying market characteristics are intrinsic in the nature of the relationships, more than attached to the particular nuances of experience you want to design.

Understanding how liquidity can be built – with the Liquidity Canvas, growth tactics cards and cheat sheet (TQ3.2)

Once we’ve fully characterized our intentions to build in a given market, possibly having also characterized what we expect from network effects (as explained in technique TQ 2.2 – Identifying the network effects and defensibility model) we can now approach the challenge of understanding how liquidity can be built. Strategically framing the problem of liquidity building is made of two essential steps:

• understanding the canonical unit 
• understanding both sides and where to focus

What is your canonical unit? 

The first step of getting to liquidity often deals with “constraining” the market to a context where you can kick-start liquidity more easily. At the early stage, it is indeed very hard to kick-start liquidity in the whole unconstrained market context. 

Typical approaches to constraining marketplaces have historically been around geographies (start from a single city – à la Airbnb) or categories (start from books – à la Amazon). More specifically, in our recently released Platform Growth and Product guide we popularized a concept previously introduced by Dan Hockenmeier, the idea of a canonical unit. 

The canonical unit is essentially a convergence of the different “dimensions” or “categories” in your market and is essential for two major things: constraining the market during the early search for initial liquidity and more generally understanding what is that your customers are really looking for (their “value unit”). But let’s look more closely at what it is.

Normally, the canonical unit has a geographical element – especially for services that depend on two players meeting physically – and multiple categorization layers.

Imagine you’re building a marketplace for servicing white goods. One could think for example of someone looking for:

Such characterization will tell you that when a customer looks for a service, such customers:

• is looking for a service in a particular geographic area (first dimension of the canonical unit)
• is looking for a service that can operate on a certain type of machine
• is looking for a service she’s looking for a service that can operate on a certain brand 

It’s easy to assume (but this should be subject to research) that one operator would rather serve diverse types of machines and – most likely – be able to operate on different brands. If that assumption is verified by research we could assume that our initial “canonical unit” may just be a geographical one. In this case a city: assumes that a service operator can accept customers in the city area.

Such a canonical unit characterization may lend itself for you to kick-start liquidity starting from white goods repair services in Rome (and later expanding into other cities). If instead research will tell you that service operators rather operate on sub-categories (washing machines, fridges…) you may have to start building liquidity in a more constrained context.

The assessment of the canonical unit can be approached with the help of the Liquidity canvas top left quadrant as highlighted below

Understanding the canonical unit can also be very important to optimize your SEO strategy: if you understand that your customer is searching for “a plumber in New York” your SEO (eg: page URL structure) should resonate with that. 

To go deeper into SEO-related questions we suggest:

• Lessons from Founding and Scaling Thumbtack with Sander Daniels (the original context from where the plumber in New York example is taken
• Sharetribe massive SEO for Marketplaces guide

Understand both sides? 

There are several launch and liquidity-related elements that depend on understanding the two sides of the relationship. First, you’ll have to understand if your platform-mediated relationship is addressing the key drivers of value creation, meaning: solving fragmentation, beating existing alternatives, and addressing the most valuable use cases. Not doing so may generate a weaker attraction.

Secondly, you’ll need to assess if there are relevant blockers that are creating a shortage of supply or demand and thus understand where you need to focus your efforts in terms of onboarding. For most marketplaces, it’s safe to assume that you’ll be supply constrained and thus focusing on onboarding suppliers may be a good general choice. Nevertheless, it’s worth asking key questions. On the supply side, typically a potential lack of suppliers can be due to expensive/rare qualifications needed, high investments needed to onboard the platform (think of cognitive investments as well), or dramatic habit changes needed. On the buyer side instead, you could think about lack of trust, or – again – dramatic habit changes needed. Another element you should consider is also the value that demand can bring to the table: if extremely high (for example if your demand side is highly strategic, think of large players that can generate massive demand for many suppliers) is normally a good idea to focus on onboarding them – think of enterprise customers.

Finally, last but not least once you onboard them (both sides) you’ll have to think about what’s required to keep them engaged. Typically on the supply side, you’ll have to take care of granting a sustained flow of orders (typically Minimum Order Flow is a good metric to keep in mind – more on another post), and on the customer side, the depth of choice or the density/readiness of supply is essential to fulfilling the customer needs. If a recently onboarded customer will fail to fulfill orders regularly will likely churn  (typically Search To Fill and Time to Fill are good metrics to keep in mind – more on another post).

To answer these questions one can use the remaining quadrants of the Liquidity strategy canvas.

A deep explanation of the canvas and an overview of how to use it is provided from page 82 onwards of our growth and product guide.

You can find an example of the use of the canvases as part of a streamlined go-to-market process here: 

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

Implications and dependencies

Clearly, dealing with liquidity is something you can wrangle with only if you’ve achieved Problem-solution fit and developed an MVP that is somewhat ready to scale. It’s also important to be prepared to track metrics, as your growth could pick up at any point (more in an upcoming post – the fourth). 

Choosing growth tactics – with the growth tactics cards and cheat sheet (TQ3.3)

Once you’ve figured out how vertical or horizontal you want to go, what canonical unit you want to start with, and how to frame both sides involved, the only thing left to do is figure out some “tactical” approaches to launch. Your objective in this phase is essentially that of moving past the “critical mass”, solving the so-called chicken-egg problem for the particular canonical unit you’re targeting.

In our growth guide, you’ll find two major artifacts that can help you in the process: a set of growth tactics and a cheat sheet that will help you connect the properties of the relationship network that is underlying the experience you’re trying to launch, with the suggested tactics you can use. Note that we introduced the characterization of the network properties in our previously released piece Defining the Platform Experience, and Flywheels for Defensibility, in the explanation of Technique 2.2: Identifying the network effects and defensibility model.

In our Platform Growth and Product guide, you’ll find a description of 10 growth tactics and a handy cheat sheet that helps you connect the ten tactics with your network properties. Remember that your objective would be to achieve liquidity inside the canonical unit that you’ll be targeting at that time.

Let’s assume for example that you want to achieve liquidity for a marketplace connecting construction works SMBs with materials and service providers and that your preliminary research showed that your canonical unit starts from a mix of geography (a city) and type of goods (construction raw materials, electrical components, and heat pumps, services…). 

This would be likely an insight coming from running interviews or research: imagine that suppliers are vertically specialized and that one that sells raw materials doesn’t provide heat pumps for some reason. It’s very likely though that the same buyer that needs to source raw materials will likely need heat pumps or professional services in other phases of the workflow. 

This situation would lend itself to:

• use growth tactics to achieve liquidity on one canonical unit
• tip your demand into a new canonical unit and generate immediate attraction for supply

You can find an example of choosing growth tactics use of the canvases as part of a streamlined go-to-market process here: 

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

Implications and dependencies

We highly recommend performing an analysis of the network properties before focusing on the growth tactics: the cheat sheet provides some initial heuristics that can be very helpful in prioritizing the growth tactics. Despite that, we believe that only a deep understanding of the marketplace interfaces you’re working on at the time can give you a real headstart in prioritizing tactics. Achieving a full understanding of the marketplace you’re building, its characteristics, the canonical units, and the properties is the very point of this post and it’s essential to craft your way toward achieving liquidity and getting the wheel spinning.

 

---

Conclusions next steps

In this third release of a series, we presented the list of 5 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
• Defining the Go-To-Market and Liquidity approach (this post)
  
• Achieving and measuring growth
• Validating key assumptions along the way
• Executing and evolving the organization

For the third one Defining the Go-To-Market and Liquidity Approach, we show in this post three key techniques that should be used. These techniques can largely be used apart from each other even if some interdependencies exist that facilitate adoption (for example, understanding your canonical units well is heavily advisable before jumping into choosing tactics).

In the coming weeks, we will release three more posts, focused on the other 3-macro problems.

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.