Editor’s note*: This post has been written following a provocation by Venkatesh Rao, in the frame of my contribution as a guest lecturer at the Summer of Protocol program. Furthermore, many of the elements of the past have emerged following conversations with Justice Conder that also provided a review.

Abstract

In the last five-ish years, the debate about the differences between developing platforms and protocols has taken center stage in the business and org development context.

The term “protocol” can be used to refer to many things, but in the context of this essay, we will focus on its role as a potential evolution and integration of the platform concept, driven by the emergence of web3 technologies. In contrast to the centralized platforms that dominate today’s digital world, protocols – many argue – offer a decentralized approach that is, on one side reminiscent of the early days of the internet – on the other, potentially enabling an approach to building digital services that is more democratic, trustable and socially beneficial.

Protocols were the foundation of the Web 1.0 era, enabling users to access and share information using open, decentralized systems. Examples of these early protocols include the Hypertext Transfer Protocol (HTTP) for browsing web pages, File Transfer Protocol (FTP) for transferring files, and Simple Mail Transfer Protocol (SMTP) for sending emails. While these protocols still play a vital role in the modern internet, the emergence of the technological landscape of the so-called Web 2.0 subsequently led to the rise of the centralized, large-scale platforms that dominate the scene today.

As the digital landscape continued to evolve, platforms emerged as dominant forces, moving from a purely technological focus to encompassing use cases, workflows, and business processes. This shift can be understood through the “Pipeline vs. Platforms” narrative, which frames the phenomenon as an evolution not only in technology but also in the structure and shape of organizations themselves.

Platforms emerged as a response to various enablers and drivers that transformed how businesses operate in the digital world. One of the key enablers of this shift was the reduction in transaction costs, which allowed for the seamless exchange of goods, services, and information between parties. In addition, access to affordable production tools and, in some cases, low marginal costs of production facilitated the entry of new players into the market, further driving the platform revolution.

Concurrently, the drivers of this transformation can be attributed to the rise of the long tail phenomenon and the decline of the “one size fits all” narrative. The long tail, popularized by Chris Anderson, refers to the idea that niche products and services can collectively create a substantial market opportunity, thanks to the near-infinite reach of the internet. This concept challenged the traditional model of mass production and mass consumption, paving the way for platforms that cater to diverse and specialized user needs. As consumers sought tailored experiences, platforms provided the necessary infrastructure for businesses to deliver value by connecting users with the products, services, and information that best suited their unique preferences and requirements.

Platforms have thus enjoyed immense success, in part because they facilitate economies of scope, enabling businesses to deliver personalized experiences without placing an overwhelming burden on the organization. Delivering tailored offerings in a traditional bureaucratic organization can be prohibitively expensive, as the associated costs would skyrocket. Rather than by centralizing production, platforms overcome this challenge by connecting diverse users and providers in a seamless and efficient manner.

By narrowing their focus on specific business processes and vertically bundling these processes, platforms have managed to deliver niche experiences while still maintaining profitable operations. Their ability to scale while delivering scope and niche experiences has given platforms a competitive edge over traditional, vertically integrated organizations.

By aggregating resources and minimizing redundancies, platforms can more effectively respond to the evolving needs and desires of their users. In turn, this fosters a vibrant and dynamic ecosystem that encourages innovation and growth, further solidifying the dominance of platforms in today’s digital landscape.

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

A (more) rigorous recap of what a platform is

The platform word has been used to describe a plethora of artifacts and organizations, so let’s make an attempt to clarify what a platform is and what it does.

If we look at the platform economy, we can section the market into three major layers. At the lower level, we see “infrastructure” providers: players that provide modular enabling technologies that are ubiquitous. You can think of cloud (AWS), logistics (UPS), telco (Twilio, Carriers)… These players are normally seeking economies of scale and provide their modular services to power upper layers.

Above such a layer, there’s another one we call the “aggregator” layer. This is the space where we normally situate “platforms.” Players that operate in this space normally have a triple VP (value proposition) that we described largely in a previous post.

Such triple VP is composed by:

• some Product elements consist of a bundle of services, targeted to a particular type of user, that are valuable per se, not depending on any other user connected. Normally these take the form of a SaaS, sometimes a hardware component (eg: a Point of Sale), or some other bundled services.
• this product side is potentially and sometimes extended through a developer ecosystem, through apps, templates, extensions, and complements to a varied extent (workflow compatibility, data compatibility, fully integrated UX) – we covered this pattern recently in an extensive post
• on top of the product side there could be a marketplace component that tops the core product elements with either demand generation (a la Airbnb) or connection to suppliers and providers (e.g. Shopify experts).

We call this layer the “aggregator” layer because both the marketplace component and the developer ecosystem enjoy aggregation dynamics, thus generating flywheels that create network effects and additional feasibility on top of basic economies of scale (check out Ben Thompson’s seminal Aggregation Theory to understand more). Within the years, we have identified seven defensibility flywheels in our growth guide.

Often, in the jargon of digital products, the word “marketplaces” is used to describe aggregators with a shallow product side, and no developers’ ecosystem (especially demand generation marketplaces such as Airbnb). Instead “platform” is used to describe products that have a strong product side and a developers’ ecosystem that creates plugins, and apps. Often these “platforms” do not have a demand generation or service providers marketplace (for example WordPress).

Although it’s very rare to see one player that fills in the whole three elements – these features can coexist in a single aggregator. An example of a fully-fledged aggregator that sports all these functionalities is Salesforce Appexchange, that sports a consultants and developers marketplace and a product that is fully extendable through a third-party apps ecosystem.

Also, Shopify can fit into the description

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

A product or an org?

In more general terms, when we speak about a platform (e.g. Airbnb) we are speaking of two partially overlapped things: i.e. the complex interworking of value propositions we just described and the organization that provides all the supporting functions that execute the value proposition itself.

The value proposition of a platform is complex and ranges widely across different functions. On the value proposition side, we’ve quite a lot of value drivers for customers:

• the product side (single user value)
• the matchmaking provided by the marketplace features (for selling or buying services and for connecting to third-party extensions providers)
• the actual inventory (sometimes platforms hire or play the role of supply, sometimes just onboard it)
• building trust through insurance or other risk-reduction strategies
• the ecosystem support services needed to onboard new users, nurture them and make them grow and express potential
• designing and evolving the ontology behind the enabled workflows, the identities, and the object and data model
• defensibility moats that make it hard for an alternative platform t be perceived as providing the same value
• and the legitimacy perceived by the customers regarding how trustable the platform is, with regards to – for example – policing and other key functions

On the other hand, to produce all of the above and more, the organization behind the “platform” must provide a certain set of core functions:

• Go To Market: all the marketing, sales, and growth-related efforts that differ a bit depending on the type of value proposition (for example, the growth and sales in a product-centric Saas may be product-led while marketplaces normally have different growth engines, depending on the stage of development)
• Design, Strategy, Innovation, Evolution, Management, Engineering, and all the (often doctrine-based) capabilities that a company has to provide, think of synchronizing discovery and testing with feature development.
• Decision making: all the expressions of real-life decision-making happening daily inside the organization
• the organization Sociotechnical architecture, defining how work is distributed, hiring, and creating incentives through skin in the game (eg. ESOPs, etc…)
• Raising capital and capital allocation
• Building and running the infrastructure
• Defining and evolving the company ownership within time
• Executing any compliance-related process and incorporating legally

We often use the word “platform” interchangeably to describe the complex interdependencies of both these stacks the value proposition one and the org one. To make things even muddier is the fact that often – due to the effects of Conway’s law (you basically ship your org chart) platforms often are organized internally in a way that resonates with the product experience they want to deliver.

As a result, platforms often remain a single product company rarely venturing out to build a portfolio. Some of them successfully embrace a “super-app” perspective where new verticals are built, sitting on quite different workflows but powered by similar core capabilities (see for example the story of Uber, Uber Eats, and Uber Freight).

The bad and good things about platforms

Platforms have been touted as the bad guys of the Web 2.0 era for a long time and the superiority of Web 3.0 and protocols has been heralded as a liberating force. Chris Dixon notoriously created the following pictures to explain how – even if they start on good footing in terms of relationship to users and complements (eg. third parties that develop plug-ins) – over time they tend to extract value and compete.

I’d complement Dixon’s comment with the following breakdown:

• Platforms exert lock-in for users normally by creating reputation and attaching it to (sometimes verified) identities, making it hard for users to roam to other platforms bringing their identity and reputation with them; Additionally, assets generated inside a particular platform (beyond reputation, think of assets gained during participation such as gaming assets, IP such as templates and other User Generated Content) are constrained to that particular platform.
• Closed interfaces: since interfaces are closed (you can’t execute a transaction if not through the walled experience they provide) there is no way that users can connect and transact across different platforms or that a new marketplace interface can be created and instantly leverage on existing inventory. Similarly, different Platforms can’t cooperate and demand originating in one platform can’t connect to supply available on another one.
• The exploitation of users: Platforms – especially those that have a thin product side and rely on marketplaces and developer ecosystems for the bulk of the value – notoriously avoid retributing users or generally give them skin in the game in the platform’s success.
• Componentization of complements – platforms tend to apply innovation cycles based on capturing the signal coming from the ecosystem, in terms of emergent behaviors, and progressively componentize them into services that they can provide directly, effectively pushing players in the ecosystem out of the market (think for example Amazon basics).

These are notoriously problematic elements of platforms. On the other hand, there are some specific dimensions according to which platforms are recognized for their superior capacity to deliver.

Innovation Cycles

More specifically, as a counterpart of the issue with componentization of complements, platforms have generally proven good in fostering ILC cycles (Innovate-Leverage-Componentize). Some platforms even push it to actively support some of the key ecosystem players that are being commoditized to move on to new offerings (see our interview with Brinker). In some cases, they actively buy out complements in M&As.

Network effects and consolidation

Another thing that Platforms proved to be very good at is achieving strong network effects by allocating capital generating compounding value that provides not only strong defensibility to the platform but also a good amount of perceived value to the users: at the end of the day users love reduced fragmentation.

Finally, Platforms proved themselves good at reducing competition through what we normally call the “winner takes all” paradigm: the more you achieve network effects inside a certain market niche the harder is to displace you.

Platforms have been quite efficient in saturating their target markets and recently what we’re seeing is that competition is emerging rather than from direct competitors though “unbundlers” i.e. smaller platforms (marketplaces) that address a specific sub-vertical.

The unbundling of the platform market though, is showing to be harder than expected. Dan Hockenmeier speaks about an “unbundling fallacy” to describe the tendency we often have to say “everything will unbundle because you can create a better UX in the specific vertical” (by adhering to a more specific workflow, market, or process)” thus discounting all the other benefits related to breadth, most specifically the fact that a larger pool of participants provides better network effects, more frequent transactions (across categories) and more.

A double-edged sword: Policying, moderation, and de-platforming.

Last but not least, something that platforms can achieve well thanks to their centralization of policing and moderation functions is controlling things such as abusive behaviors, hate speech, and related issues. This can also be seen as a “double-edged sword” if we ponder that de-platforming can be extremely impactful for players that are used to operating on a platform and may have created a strong reputation, assets, and eventually a livelihood. Is it a good or inherently bad feature? The debate is open on this, and it’s generally hard to come to a conclusion.

Enter (Web3) Protocols

Let’s now assess what is that we call “protocol” (at least inside the scope of this essay) and what contribution can the “protocol” approach bring to the table: in what ways can help us improve the way we address markets, and enable ecosystems?

The concept of protocols recently regained popularity as a consequence of the emergence of new enablers related to the Web3-blockchain world.

When we speak about a protocol – at least in this essay – we’re generally talking about a system that is a variation around the archetype below:

We have a protocol (an abstraction of a domain, describing entities, and transactions…), the protocol manages a stateful representation of the domain and often provides key functionalities directly to the users with the aim of making these functionalities product/implementation independent (for example identity verification).

Products interact with the protocol, and a DAO manages protocol evolution, consistency, security, and governance, in different ways. This is of course a simplified representation.

We could certainly talk about a broader definition of a protocol: for example, in a recent essay, Jesse Walden made an explicit difference between what he calls libraries and networks (libraries are not stateful) and we could certainly assume that libraries as well can be considered sort of “protocols”, but for the sake of this essay let’s assume we’re talking about web3 protocols.

So what are the new enablers and affordances that this kind of protocol provides?

Tokenization

First of all, these implementations allow the creation of both fungible and nonfungible tokens that add a few new capabilities to the table. Most specifically, tokenization allows new types of capital collection and allocation, secondary markets for assets (tradability), and the possibility to program and attach distributable rights to the tokens (utility, governance).

Tokens have allowed the emergence of so-called automated market makers (such as liquidity pools) that have disrupted the traditional approach to capital raising through liquidity events allowing some sort of “continuous” and fluid access to capital and valorization.

Furthermore, the inherent tradability of tokens have made it possible for secondary markets to emerge quickly where players can trade their asset without necessarily having the consent of the “protocol” owner.

Trustware (smart contracts)

The second massive new affordance in protocols vs platforms is the emergence of programmable and untamperable incentive structures and rules set. Smart contracts essentially transform and reduce the need to trust third parties (both the ones we are in interaction with and the ones running the system) in favor of trusting the system or rules itself.

Additionally, the emergence of trustware – open, clear, untamperable self-enforcing rules – made it possible for protocols to allow for pseudonymity and generally being more protective of freedom of speech for the absence of a trusted middleman to enforce identity verification and moderation.

Open Source Access

This is not inherently a new enabler (open-source approaches have existed for ages) but besides the openness of protocol source code, web 3 protocols introduce the possibility to make the actual data being produced transparent and accessible.

Such characteristics make a difference not only in terms of transparency and inspectability of code but also in terms of forkability: forking a protocol and being able to fork also the state of it makes forking an inherently more viable option.

It is also to be noted that new approaches are emerging that make it possible to obfuscate code and data and reduce open access (zero-knowledge proof) maintaining security and trustability.

How can protocols add or transform the way we build scalable products and strategies and mobilize ecosystems?

At this point in the conversation let’s enter into the key questions: how can the new setup that is emerging around web3-enabled protocols help us fix the inherent negative aspects of platforms and how can it improve or deliver better results in fields where platforms instead are providing good outcomes?

Let’s now look into how the various responsibilities that normally the “platform” would be in charge of (as a mix of value proposition and organizational features) can be provided by the complex system made of Users, complements (ecosystem), Products, DAO and Protocol that we introduced above.

As a way to read the pictures below, let’s consider that:

• with DAO we mean the organization;
• with Product, we mean the company/organization that develops the products that are using the protocol;
• with Protocol, we mean the capabilities of the protocol to execute its ruleset and incentive structures autonomously.

Let’s look first at the value proposition side:

Here we can see how the protocol approach can bring some interesting new capacities. The most interesting are:

• the possibility to matchmake across different products: demand being generated in a certain product can connect with supply coming from another product (using the same protocol). If entities are “registered” through the protocol then most of the network effects would accrue at the protocol level, and a new coming product may directly leverage the inventory, focusing on improving UX, improving the transactional experience, etc. The differentiation between products would decisively move more into UX versus other defensibilities.
• product defensibility is harder to achieve: at the same time, products have to be less concerned about defensibility because the capital needed to kickstart network effects would largely be a protocol problem.
• a massive improvement of protocols vs platforms lies in a generally more important role in the process of domain specification: the nature of the protocol as an open “self-executing” domain model (the mix of workflow models, entity models, transaction models…) makes it a great basis for extendability through complements and makes it generally much easier to build around, especially for protocols that convey enough legitimacy.

These emergent capabilities certainly open up the design space. On the other hand, we have to acknowledge the broader fragmentation across different entities that would make coherent execution more difficult.

If we focus now on the organizational functions, we can see that the same fragmentation of contribution exists. Notable differences introduced by this new paradigm are the following:

• Go To Market is a notoriously problematic task for protocols, to the extent that some relevant players in the space recently wrote extensively encouraging protocol developers to address this point (check Mason Nystrom on Variant’s blog). The problematic nature may be inherently driven by the highly tactical, top-down nature that most of the successful GTM approaches developed by platforms have, something that generally creates resistance in the self-managed, self-emergent cultural space of DAOs
• Executing platform strategies often involves high levels of a fairly specific management doctrine (a rather specific body of knowledge is emerging in the space, check for example Reforge’s or Boundaryless’) and DAOs have so far proved fairly resistant to embracing existing doctrine (see this reflection from Pet3rpan on an approach to solving the DAO strategy problem).
• The sociotechnical reality of DAOs and the interplay and overlap between the DAOs and the product teams building on the protocol doesn’t make it easy to execute punctual strategies. DAOs tend to be distributed and sociocratic/holacratic and having multiple product teams building on a shared infrastructure adds up one fractal level more of distributedness on top. According to Conway’s law (you ship your org chart) this makes for different outcomes than with more centralized and vertically integrated/bundled organizations that can optimize their organizational model to resonate with the product model (see more of product-centric organizational models and how shape resonates with market function by reading this piece)
• On the capital collection and distributing ownership side, the new world of protocols opens up massive new possibilities though also introduces some regulatory uncertainties and concerns. As a consequence of the uncertainties but also of the inherent systemic interplay between different players, it’s often unclear to understand where the value accrues across the stack (protocol tokens, product tokens, voting rights, product equity)…

Partial Conclusions: on the role of protocols moving forward

Moving forward we can certainly see protocols having a role in the market. Historically the emergence of web3-powered protocol situates in a moment where platforms seem to face different threats. On one side, according to Hockenmeier, we may be hitting some kind of S-curve plateau where new entrants with the dream of unbundling the existing market may find it hard to generate the right unit economics (CAC, LTV) to justify an unbundling.

What does it mean for protocols? Protocols may have two spaces where to attack the market then:

• disrupt and substitute the horizontal
• go after vertical markets (with the additional hurdles explained above)

The overall nature of protocols – like the pilot study identified – makes them “typically only codify a common minimum core”. This definitely makes protocols more suited to go after (and disrupt) existing horizontals. Rather, vertical markets could likely be addressed by product implementations that build above and extend rather common denominator protocols.

This capability may definitely help solve the unbundling fallacy: products built on top of existing protocols could be lean enough to have a lower cost per user, and also have a reduced CAC with some onboarding of users being granted by the network effects operating at protocol scale.

In accordance with such a vision, horizontal protocols would hopefully establish a minimally extractive stance, with a basic, shared domain model, and leave products to build differentiation on top.

Nevertheless, what we witnessed in the protocol development stage so far is a different situation where most of the teams have approached the market by embracing a product-centric go-to-market model, coupled with the will to embrace progressive decentralization. As a side effect, we had a massive amount of reinventing the protocol wheel: at the moment there’s almost a striking 1:1 relationship between products and protocols.

This pattern has – most likely – been a consequence of the shortcomings and inconsistencies that DAOs have shown in execution (management by committee is not particularly effective in conquering market share).

On another hand, we’re seeing public bodies embracing protocol-like initiatives to disrupt incumbents and increase interoperability – solving one of the key problems of the platform approach. Initiatives such as ONDC in India are indeed establishing protocols and eying the use of public ledgers to host verifiable reputations.

In conclusion of this essay let us lay out some that appear to be the key outstanding questions that remain to be answered:

• are protocols really an alternative to platforms? If yes, are they disruptors, or they may be tools that incumbents use to transition from being a platform to being a protocol in an effort to remain legitimate under ecosystem pressure? Do the existing capital incentive and governance lock-ins allow for this transition to happen?
• are protocols instead more suited to target new markets, for example around the Commons?
• Are they best suited to become tools in the hands of public regulators?

Although these questions are yet to be answered, this essay aims at giving an overview of the major areas of overlap and disruption where protocols can offer new ways to approach markets and enable transformation, while at the same time offering a reality check, unveiling the complex interplay of functions that platforms have been able to deliver – on their way to conquering markets.