The Protocol Guide to Enterprise-Led Growth

Wednesday, August 2nd, 2023

(Note: although Bitcoin has a tombstone, I believe it will survive. Midjourney doesn't.)

Not all protocols will survive

Whenever there's a new technology, a Cambrian explosion of different vendors and offerings emerge. But eventually that number whittles down to just a handful of key players.

Cars. Airplanes. Computer operating systems. Chip manufacturers.

In each case, the early days had lots of innovation. But as the market matured (which it often did quickly), few were left standing.

Broad, general-purpose protocols, will not escape a similar fate.

In the same way that software, for example, found lots of application niches once the core operating systems and databases consolidated to just a handful, a similar fate is likely going to occur to whatever the "blockchain stack" becomes.

What will determine which are the last protocols standing?

Every failed protocol fails in its own way

I don't know for certain if the Anna Karenina principle applies^[1], but I think every happy long standing protocol will have one thing shared amongst the others.

This one thing is not being done well by most protocols.

In fact, the industry as a whole is lacking this one thing.

Protocols in the blockchain have been pouring energy towards attracting lots of developers who will trust their platform. They have been mostly using a tried and true Developer Relations Playbook, which includes hackathons, documentation, tutorials, and Twitter/Youtube content.

At first, this seems like a reasonable developer-first strategy. And for those protocols that quickly attained critical mass, it has paid off in the short-run.

New startups are being built on these protocols. Some of these could become big.

More developers are learning how to build on the well-publicized protocols. Protocols are grabbing more mindshare than those who have lagged behind in their developer efforts.

Especially among the decentralized and permissionless protocols, however, one thing seems to be missing:

Enterprise demand pull.

There isn't strong and existing enterprise demand pull. Increasing interest and directionally right momentum, but it's still small.

I anticipate two main counter arguments to this statement.

While there are likely more, I want to address these main two as a foundation to why the developer-first strategy, while an important pillar, will not be enough for protocol sustainability.

Mistaken perspectives on enterprise demand pull

Before I dive into why a massive enterprise demand pull is missing, I want to pause offer a hot take.

Even if you are already building enterprise content, have hired a BD team, and landed major enterprise deals,^[2] understanding the dynamics of missing demand pull will only help you.

It's worth asking whether the assumptions you have about the role of enterprise demand pull deserve re-consideration.

Myth 1: Enterprises already know about blockchain

This is an easy one to believe. Blockchain is not new.

Major enterprises have begun to hire and even invest in the technology: Mastercard, Starbucks, Disney.

Doesn't this mean the tidal wave has begun?

There have been many enterprise focused organizations like IBM that have been pushing the blockchain story to support their own services and cloud divisions.

But education of the enterprise takes time. And IBM's involvement isn't the harbinger of near-term success.

For perspective, the Internet ushered in the "digital transformation" mantra. And IBM arguably led the way with "e-services" as an offering, complete with massive billboards in airports.

But it still years/decades before businesses instinctively had a digital-native approach. And I don't think IBM was the primary beneficiary of the "digital transformation." Their miss of the cloud illustrates this.

But this massive C-level education which took time and money from large consulting firms (Accenture, IBM) and very large software companies (ISV) (Oracle, IBM, SAP) is what led to our current environment of developer-first Go To Market (GTM).

The education that took place for digital transformation does not directly lead to blockchain-based technology.

There is some overlap, but as I argue later, it is different.

Myth 2: Developer-first will already generate enterprise demand

For the last decade or so, developer-led growth has been wildly successful for the reasons in #1 -- huge investments to business leaders around "digital transformation."

Across infrastructure and tooling, developer-first GTM has hands-down worked.

But that's because of all the leg work done by consulting firms and large software companies to educate the CxO on "digital transformation".

Because that demand created internal initiatives around software development, vendors that appealed to developers with tools that increased their productivity found a hungry audience.

Developers held the keys to technology decisions. They had and continue to have a mandate to fulfill existing demand driven by existing business initiatives.

But, if I argue that developer-first still works, what is different about the blockchain?

Demand pull for enterprises - where does it come from?

What has driven the ongoing demand for developer-focused tools and infrastructure?

The demand has been wide and deep across a spectrum of areas, from DevOps (dev tooling through testing and deployment), infrastructure such as cloud-native versions of the tech stack (compute, storage, databases), and developer-centric security.

Why wouldn't this massive, existing demand, just naturally include blockchain?

Before I answer that, let's look at what fueled the demand, as well as why it took a long time of evangelism and education around something as vague as "digital transformation"?

Real demand from enterprises comes from, at first, "business model innovation," followed by operational efficiencies.

The existence of the Internet, for example, did not create demand.

The resulting new business models, however, did.

Business model innovations born from the Internet are concepts we take for granted today.

But these concepts weren't always obvious or seen as necessary.

Whether it is 24/7 shopping, deep personalization, infinite inventory, user-generate content, ad-driven businesses that worked at scale, granular CRM -- all of these weren't part of most company's business models.

But they all shared advantages derived from the Internet, which included: near-zero cost distribution, unlimited presence, intimacy with users, and streamlining existing workflows.

This may be hard to believe, but many boomer decision-makers did not see such advantages as useful to the core of their business. Why?

Because they were operating from existing business models.

This is why Internet-first businesses, such as Dell, eBay, and Amazon surprised and disrupted their brick-and-mortar counterparts. It's hard to imagine now, but even with the rise of these Internet companies, it still took time for most major enterprises to think it as "emerging technology" to "existential infrastructure."

Once the new business models were in place, the investment then shifted to reducing operating costs of those new ways of running the business.

This ushered in cloud computing (only pay for resources you actually use), streamlined business processes through SaaS (lower headcount), higher productivity (fewer devs, security analysts, and dev ops to ship more impactful code faster), and better data collection and analytics (personalization, fraud detection, marketing optimization).

We will see how AI is a natural fit for this type of business-model and operational efficiency motion: AI can reduce headcount, continue the low-cost always on global distribution, make meaning out of all the data that has been collected.

Because nearly every company across every industry became a software company a) first to innovate on their business model; b) to then reduce operating costs; c) rinse and repeat at the appropriate pace and cycle for their industry or competitive set, developer-first tapped into massive demand.

Every developer was touching meaningful innovation or efficiency initiatives, whether for a small start-up or for a large enterprise. And so there were a ton of developers all open to new tools and infrastructure.

Once there's an enterprise mandate, decisions flow to developers

When a business already understands and funds a software-based initiative, the developer can make decisions around whatever they need to be productive - the database, applications, security and supporting architectures.

As the business requirements drive changes around that same business model and requirements, developers will improve and iterate -- prompting them to search for and try new tools.

For example, a broad business goal of better personalization and lower inventory for a big retailer can kick off lots of initiatives that keep improving: data collection, processing, analytics, inventory optimization, marketing automation, supply-chain management. Each of these areas (and more) have seen accelerating innovations in these areas, and developers make the decisions.

But without a top level driver on requirements, appealing to developers, alone, will not advance emerging technologies that offer business model changes.

Here's the question: do mainstream business model practices (once considered innovative) include the blockchain?

This will be hotly debated.

But I believe blockchain's value proposition and business model innovations are far enough out of the mainstream of the values generated by past technologies like the Internet, mobile, and cloud, that it cannot ride the existing enterprise demand pull.

Why are blockchain protocols different?

Let's first look at the primary value creation areas for the Internet and software.

Internet gives free, unlimited distribution. The blockchain doesn't add to this. So it's not a technology being pulled by innovation that is based on this value creation primitive. Putting something on a distributed ledger doesn't add much to the core requirements around speed, latency, personalization, mobile, data collection.

Mobile ubiquity gives deep intimacy with global customers. The blockchain also does not add to this in a traditional way of gathering data, storing data, tapping into existing behaviors. So it's not really being pulled by this value creation primitive.

Software cuts costs. Software automates redundancies, increasing record accuracy, and reduces the needs for humans to streamline existing workflows and processes. So the blockchain also doesn't really get pulled in by this value creation primitive.

Unless new value-creation concepts and primitives are accepted by the mainstream as true "unlocks" for their business, the blockchain will just be compared to existing "web2" technology.

Blockchain is not just a bigger and cheaper database. If it gets compared as such, it will lose.

Blockchain protocols enable different business models.

And until executives embrace and gain conviction around those business models, the demand pull cannot be compared to what we see for current developer-first solutions.

What is the risk for remaining engineering-centric?

Let's recap the main ideas so far.

1. Many protocols have deployed a developer-first model
2. This is reasonable because it works for existing technology that share the same value-creation primitives
3. Demand pull comes when business decision makers embrace new business models, followed by operating efficiencies of those models
4. Because of the long and arduous education and evangelism of CxO's around "digital transformation," every business became a software business.
5. This created a huge demand pull, where developers could make meaningful decisions to support an executive-level business model initiative
6. This demand pull does not exist for blockchain because blockchain creates new value creation primitives and new business models

The engineering-centric approach for protocols is to continue to reach developers and deliver engineering-focused products for other engineers, mostly within the crypto and blockchain space.

This isn't wrong.

It's just insufficient.

Hackathons and dev-focused work will likely attract curious developers or crypto-native engineers.

But without some known and accepted demand pull, very few scalable projects will emerge.

Not none. There is some signal, which comes from the classic technology adoption curve.

But this is always the case. There will always be the intrepid innovators and early adopters within a new technology at mainstream companies.

And blockchain has illustrated an ability to capture the imaginations of typically slower-moving brands. NFTs, because of the simplicity and cultural-impact, made a huge leap.

Some would argue that they jumped the shark.

That's okay. It's part of educating consumers and decision-makers. These kinds of cultural phenomenons, even if they get it wrong, create new pathways for legitimate businesses.

Pets.com was a failure across many dimensions.

But Chewy.com, a very similar, has been a success. Pets.com paved the way in terms of design, consumer adoption, and eco-system building (all those developers went elsewhere, likely continuing to build upon those original ideas).

So then the question is: what must be the principles or new business model innovations that enterprises must seize as advantageous in order to capitalize on blockchain and, in turn, create the massive enterprise demand to grow the successful protocols that can tap into it?

Blockchain Business Model Innovations

Once the business model creates enterprise demand and has found strong natural pull, are there ways that the protocol can enhance or accelerate demand?

Demand Side Token Design goes through this design process with an example semi-hypothetical protocol.

ChangeLog

1. Instantiation - can't remember
2. New updates - 2023-02-06
3. Wednesday, August 2nd, 2023: update to publish on my own blog
4. Sunday, August 6th, 2023: A few links to the other