We still have a problem in the Web3 space around genuine consumer usage outside of speculation. Founders continue to build infrastructure and are losing sight of the most essential component of bootstrapping a successful protocol. We’re continuing the same pattern of building beautiful ghost cities, and the one thing most architects assume is that there’s some sufficient demand waiting at the gates (as they claim in their position papers and problem statements). 

Quite often, founders attempt to justify building protocols instead of applications and clients by making excuses across several areas. You may hear tales about key management, costs, and scalability - when, in reality, these are mostly solved through embedded wallets, L2s, and progressively scaling trust assumptions. Related to this, the one philosophical tradeoff point founders will sometimes make is about decentralization, which is also the most flimsy argument available to them.

In most cases, decentralization is a moot point used in place of justifying systems that don’t need extreme trust guarantees about control. But if a new protocol drops and nobody wants to use it, does it make a sound?

"Extraordinary; we can build the perfect system for decentralized food delivery that is protected from nation-state attacks." ~ Nobody

Product-Led Growth

When considering how to drive adoption, let's step back and start with core principles. Robust clients and products should be the core centerpiece—as they always have been when using a product-led growth framework. Product-led growth is a way of operating in which product usage dictates the direction of engineering, design, marketing, and more.

Every point of feedback that determines direction, resourcing, and messaging should come through a customer's experience using a product. There isn’t any philosophizing about what a user might like because all feedback exists as a directed beam to influence business direction. This evolved with web3, as there was more emphasis on building decentralized technologies and open protocols to usher in a new way of operating.

However, many teams lost sight of providing an experience for users and thought their technology alone could change the world. Sometimes, it isn’t about how great or complex a technology is, but how easily it can be harnessed and the downstream experience for a user.

Every ‘field of dreams’ looks great on paper, but here’s a shovel - start digging.

Product-Led Protocol Development

Your protocol is not a product. 

In the web3 space, we inch closer to a new model with Dan Romero’s concept of Product-Led Protocol Development. Too often, developers build protocols for the sake of building protocols, and think that users and other developers will flock to them and make them successful. It’s essential to think about driving the first usage of your protocol rather than just building the protocol itself.

In this short post, he implores developers embarking on some unreasonably large protocol or network-building quest to make sure they’re aware of three things:

• A protocol is only as good as the number of clients and businesses using it.

• Developers worth their salt care about their quality DAUs rather than a tech stack.

• Users use apps, not protocols – so focus on building the cornerstone app.

Before even thinking about a new frontier, we must ensure we’re building the first road there. You should be building both the protocol and the first client that leverages that protocol. What users want to see in a client should influence a protocol’s development, returning us to the original concept of product-led growth. In this case, the protocol properly becomes more abstracted away while enabling all its benefits to end-users through the client. Satisfied users start to increase your chances of success by influencing your client development, and any necessary changes to the protocol itself that other developers can benefit from.

This model also sets an initial blueprint for how developers should leverage your protocol, because you’re making the most beneficial aspects of it abundantly clear through your product offering.

All the points you draft about how great your protocol is should be present in the client you build. You must demonstrate that value instead of expecting others to do it. However, that isn’t to say you shouldn’t start with a new protocol; ensure the first client or tool to leverage the protocol is the centerpiece of your offering to the world. 

One last point to make in the case of web3 apps is that you must ensure you have your table stakes handled before trying to appeal to mass markets. Mimicking what exists on the market in the same category you're building in gets you to square one. Differentiation should come after meeting the market where it is. For example, a social networking application should at least allow users to create profiles, create content, and easily share content. If your app doesn’t even have that (in the name of ‘decentralization’ or some other excuse), it’s time to rethink your strategy.

Product-Led Blockchain Development

Finally, I think we’ve moved beyond product-led protocol development and into what I’m calling product-led blockchain development. This is coming as more teams spin up new application-specific rollups and L2s. In this model, you’re not just building the first product or client to leverage your own protocol, but also your own blockspace and ‘product-defined blockspace’.

You need to show and demonstrate why you created an entirely new blockchain, and there’s no better way of doing that than demonstrating your wedge or unique advantage. Being ‘faster,’ ‘cheaper,’ or ‘more scalable’ doesn’t mean anything anymore when we’ve made creating new blockchains as easy as one-click deployment. 

Your network effects don’t stop at someone leveraging a new open protocol. Now, developers influence the success of your new blockchain by leveraging the blockspace for the benefits it provides in the context that you’ve defined. You’re now on the hook for a hell of a lot more than just an open protocol and an application—you're on the hook for the engine that underpins it.

You’re now responsible for implementing nodes and clients, some of the first core fundamental protocols, and that novel application that justifies that new blockchain. If you’re willing to go on this mission, you better be ready to handle all of this.

Be the blockspace you wish to be in the world - but remember to build something useful.