Flywheels for Protocol Demand

Monday, September 11th, 2023

Flywheels are considered key to web2 technologies. Product managers are already familiar with the major examples. Not all traditional SaaS products have flywheels that work and scale (although all will try).

Protocol design, however, should always consider a flywheel. It's inherent to its capabilities and is the foundation to building a demand objective function.

In the essay Demand Side Token Design - Sub Functions, I introduced "sub functions", which are other parts of the protocol that contribute to the objective function.

These are essentially acting as flywheels, so its a valuable concept to think about, not only at a high-level strategically, but at specific protocol and contract design.

As with all things, it depends on validating insights from customers, but we'll take this as a given and dive into a little background.

A quick run-through of flywheels

Thankfully, a summary was already created in Substack by Aakash Gupta's Product Growth Newsletter.^[1]

Here are some examples from that article:

Amazon e-Commerce

1. Cost: Growth → Lower Cost Structure → Lower Prices → Customer Experience
2. Selection: Customer Experience → Traffic → Sellers → Selection → Customer Experience

Amazon: Advertising

1. Marketplace Sales: Growth → Marketplace Sales → Shopper Purchase Data → Marketer Demand
2. Data: Marketer Demand → Advertising Data → Better Performance → Ad Selection

Airbnb:

1. Host experience: More reviewed properties → More trust → Amazing traveler experience → More trust → Amazing host experience
2. Traveler experience: More marketplace data → Vetter pricing system → Great value → Amazing traveler experience

Epic Games

Netflix

1. The Content Flywheel: User experience → Time spent watching → Filmmakers → Movies and shows → User experience

2. The Data Flywheel: User experience → Time spent watching → Data → User Experience

Uber

1. Faster pickups: More geo coverage → Faster pickups → More demand → More drivers → More geo coverage

2. Lower prices: More geo coverage → Less driver downtime → Lower prices → More demand

The Center Value is Your Protocol Objective Function

As I wrote about in Demand Side Token Design and Demand Side Token Design - Sub Functions, the protocol that wants to design its mechanics to increase demand is essentially building a flywheel with the objective function in the center.

Remember the canvas from Protocol Design Canvas?

We could loosen it (and probably should do so in the early stages of the design) to create a simplified flywheel like above.

When making the flywheel, I remove the reference to the tokens. We will layer this on since tokens are what makes the flywheel more compelling and trackable. But a solid protocol strategy should stand alone without the token value.

Edit - a completed, and different, flywheel first

After I originally wrote this article, I thought more about it.

I came up with this:

This focused entirely on the core potential stakeholder, the Network, but imagined as part of the design what would naturally incentivize the Network in the first place (they have a virtuous cycle), and as a result of N network joining, whether there was a flywheel to attract N+1.

This may warrant a separate write up (Flywheels for Protocol Demand - Part 2).

So now back to the original writing, which is not perhaps the best approach, but is more structured which is the important thing here.

Building a flywheel from the beginning

Let's start with some basic dynamics:

As the number of indexers grow, which compete for query fees, the costs should lower, which should attract developers to build more applications that query the service. As the total spend increases, more indexers should gravitate to the protocol to earn fees.

But as we look at this, is "lower cost of queries" really sufficient to attract developers to build dApps.

It's not.

So let's layer onto this.

Under this design, we presume that if data is more "useful," more developers would build out more dApps. If we reward those who curate and make available the data, developers would would find it useful and then make more applications. Applications would, in turn, drive an increase in spend, which incentivizes more useful data.

However, this poses some problems if we drill in a little more into Demand Personas for Protocols.

Part of the persona work includes their journey, and it seems limiting for developers to make applications just because useful data is made available.

Certainly it's a model. For example, whenever an entity makes data available through an API, applications do emerge. If a city were to release robust transportation data, for example, developers will build application to use it.

But availability doesn't generate demand. Demand seeks availability.

When a firm (which is why understanding Firmographic Framework for Protocol Demand matters) thinks that the transportation data is valuable and not available elsewhere, there will be demand, capped at the number of firms that fit that profile.

The gating factor is a little bit more nuanced that someone looking at integrated blockchains and then curating something for developers. There needs to be more juice and scale.

Here's the third version:

Here, we see that there is no flywheel in terms of acquiring source chains and the developers building on those chains. This means there is a non-flywheel growth dependent on BD.

I made a change to propose the flexibility of ETLQ pipeline, which can expand the use cases which improves usefulness of the data for a developer who has an idea of an app (versus the data driving the innovation, the developer is unblocked from having an idea.)

Is it possible to change this picture by adding some additional factors to potential explore with the protocol itself?

Here I made some speculative additions. These all need to be validated, but at least we have a framework to explore by talking to the stakeholders.

I highlighted the three areas of interest in yellow:

All three have in common finding ways for the protocol to increasing the number of developers who build data applications.

1 - Indexers Participate in More Dev Meet Ups

The Indexer population has grown globally; could it be possible for the indexers to be incentivized by the protocol to attend or host developer meetups?

This may seem like something unrelated to the protocol itself, but consider a few options:

1. Indexers who host developer who build get additional rewards for having brought in those developers. The protocol would need to support the incentive mechanism and tracking of additional rewards.
2. Indexers build open source primitives that accelerate growth from developers and receive additional incentive rewards (harder to do depending on the type of primitives, ideal ones would be a contract on chain that augments the services)

The protocol team would probably want to provide guidance on firmographics and communities to help support Indexers who want to do this; although the beauty of this is an indexer may already have market insight (they are web3 games or NFT collectors) and can be a part of the appropriate communities.

2 - Source Chains Bake the Data Protocol in All BD and Dev Onboarding

The second approach to scaling developer growth is to augment the existing BD and developer outreach efforts of all the other source chains.

Cracking this nut successfully gives scale to a data indexing service that is agnostic to source chains.

Making this connection also needs understanding the needs and journey of the chain's developers and customers. It could also involve some additional content to help frame the value of any tools or protocol features.

Here are some ways:

1. Chain-specific SDK or data query documentation
2. Chain-specific "etherscan on steroids" that could fill in gaps with the etherscan UX and is offered by the chain to all users
3. Free queries which shows transactions from applications that have a query component

These aren't purely on chain, but are tools or content that could help the chains most compelling integrate the data service.

Chains might be more open to talking about querying transactions or data written to their chain's blocks if there were a reliable, decentralized tool which made it easy. This can also be offered through a dApp that provides an enhanced customer experience for the chain (an ideal case is being able to surface types of data or transactions that give the chain a unique position in the market).

Enabling the chains to see clearly that analytics provided by dapp builders to their customers drives more usage could increase the incentives for developer outreach and BD teams to tell a story that bakes the service in.

In this case, the decentralization makes a difference, not because of the ethos, but because they can't get rug-pulled the way they can with a SaaS. In many ways, the infrastructure is "public" so the chains have less risk extending their own service using the data layer.

This approach gives tremendous scale since there's a multiplier across all the chains to their BD and developer relations efforts.

However, it needs deep customer insight into both the chains and into their customers.

3 - Drive More Users to Developers' Apps

This is the most ambitious, but it's also the most tried-and-true developer go to market from the web2 world.

Whether it can translate to web3 remains to be seen.

But the number one most effective way to drive developer acquisition is by aggregating their potential audience through a marketplace.

Apple's AppStore is the quintessential illustration of this.

Because the AppStore centralizes the audience of potential customers, it's a compelling place for developers to build. As developers build more apps, more users return to the AppStore to discover more apps.

Having such a strong position is compelling, but extremely difficult.

Could a protocol that provides a data service to build data driven apps do the same thing?

Possibly:

1. They already have a directory of apps using the service
2. The protocol already has relationships with chains (see #2) -- who could be incentivized to drive more users to app built on top of their chain (depends on their firmographic concentration)
3. The directory could use TCRs to add an incentive layer to the rating systems, potentially
4. The directory could provide valuable information that encourages more developers while also driving users

A marketplace can be very powerful, especially when one doesn't already exist in the ecosystem; research into the existing developers and ways to incentivize more popular dapps to evangelize the marketplace would probably be a good first step to then see if those mechanics can be built onto the protocol, itself.

This is a little long, but there is great opportunity to combine mechanism design with flywheels; they are adjacent to each other and are complementary.

Fly Wheel thinking zooms much further out, which is valuable. Doing the exercise helped me in my own thinking, for example.

Objective Functions help us to drill down into the actual mechanics of the incentives and how they can (or can't) be codified.

Fly Wheel design helps provide a hypothesis which can be tested directly with customer research.

Object Functions probably need to be best tested in simulations.

Combined and when well-done based on customer and market insights, this becomes a powerhouse.