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
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.
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.
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.
<100 subscribers
Rocco
Great new article from @rocco about product-led blockchain development. https://paragraph.xyz/@rocco/product-led-blockchain-development
Thanks for sharing. This is some good stuff @rocco.
๐
We backed into this naturally with @oap. We saw a niche, went to web3-ify it, realized we had a protocol, and then continued on with the app people will actually use.
Yep, that's smart!
I want this very much ๐ป But I donโt can to mint from my telephone ๐