Product-driven protocols
Note: Most of what is mentioned here are observations from how Farcaster is getting built (wrote about Farcaster here).
The most common critique of web3 is that we don’t have useful products today. While the argument misses a whole set of things about how technology happens and how innovation works, it raises the question is there a universe where we would’ve had useful products today? and I think the answer is yes! and a huge part of the reason we don’t is the way we’re developing protocols. This blog post is written with the goal of defining a new way of building protocols, a product-driven one.
A simple definition of a product-driven protocol, is a protocol that’s built in the same way products get built. You launch fast, iterate fast both enabled by being sufficiently decentralized, with an extra step to achieve developers-protocol fit along the way. Another would be “A protocol that solves X while delivering shippable intermediaries”. I think the biggest advantage of buidling a product-driven protocol is, as Dan Romero put it, “you’re in control of your own destiny” as the core product that you're building will determine if your protocol succeed or not.
I wrote about the Twitter APIs story and I think they’re probably the best example of how a product-driven protocol should be built. Build something a lot of people love, and open it for developers to build on top of it. Developers built on top of Twitter not because they provided a database, they built on top of it because there’s a market value and users to be captured. Twitter had apps built on top of it with millions of monthly active users. Try to find a product you can build using your protocol (It’s the same thing as be a user of your own product). Dan puts it perfectly that you “Can't expect others to spend the time and effort to build high quality products if you're not willing to do it yourself.”
I think the core of building a product-driven protocol is sufficient decentralization. There’s this notion in web3 that you have to be maximally on-chain to be decentralized but the reality is that most protocols aren't based on money so they don’t have to be. The Internet is decentralized, and neither DNS, HTTP, or SMTP are on-chain. You can change your browser, email provider, website host, etc… anytime you want. I would also argue that in a practical way off-chain protocols are more decentralized than on-chain ones because of their exit with interoperability structure and native usage-as-vote consensus mechanism. The only thing you need to focus on, are we decentrelized enough that people can exist and run the client themself if they need/want to? and how can we lower the price and time that’s required to exit to zero in the future?
An example would be let’s say company A wants to implement the type “encrypted” for Farcaster casts, and company B rejects that. Company A can implement the encrypted type and if enough users use the encrypted feature, company B will be forced to add the new cast type. Users switches the clients and vote for another company's data structure implementation while keep being interoperable with other company client. While if the same data structure was a smart contract, you’ll have to fork the contracts and lose being on the same protocol.
Another argument for sufficient decentralization is the fact it's very aligned with the worse-is-better model. It allows you to have a much simpler protocol, and development to be much faster. Focus on being simpler not only in your interface, but also in your implementation for the sake of speed. Be a virus, take the market and user's share and later progress towords decentralization. Richard Gabriel says:
It is important to remember that the initial virus has to be basically good. If so, the viral spread is assured as long as it is portable. Once the virus has spread, there will be pressure to improve it, possibly by increasing its functionality closer to 90%, but users have already been conditioned to accept worse than the right thing. Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing.
Linus Torvalds also says:
Don't underestimate the power of survival of the fittest. And don't ever make the mistake that you can design something better than what you get from ruthless massively parallel trial-and-error with a feedback cycle. That's giving your intelligence much too much credit.
Don’t be a Gopher. Gopher was the first Internet first data access protocols that got replaced to World Wide Web. A huge mistake that they did and one of the reasons they lost, is that Gopher was being over optimized for how the core team thought developers will use it. Your protocol should be general enough to enable developers to build things you have not imagined yet.
Product-driven protocols operate pragmatically. Farcaster got criticized for being invite-only, but they knew when to trade off decentralization for the sake of the product and that having a high quality communnity is important for achieving developers-protocol fit. It doesn’t matter if you’re decentralized and you have no users / developers. Another example would be delegate keys, they’re considerably a big decentralization trade off but they’ll 10x the user experience and make it much easier for developers to build new apps which is what really matters.
People say that creators need to focus on getting 1000 true fans, your proocol need to focus on getting 10 true fan developers. Focusing on having an early community of builders that really love/care what you’re building is going to be crutial for an open and decentrelized ecosystem later on. Mainly avoid competing with them.
Chris Dixon in his essay The importance of predictability for platform developers says:
The most successful platforms try to mitigate these risks for developers (not just the appearance of these risks). One way to mitigate platform decline risk is to launch the platform after the platform’s core product is already successful, as Facebook did with its app platform and Apple did with its iOS platform. Platforms that are not yet launched or established can use other methods to reassure developers; for example, when Microsoft launched the first Xbox they very publicly announced they would invest $1B in the platform.
Bootstrap. At the early days of the browser, Mosaic automatically converted Gopher menus into HTML. A web3 example would be Showtime importing NFTs from other platforms to their feed at the beginning. Another thing I think is very interesting is bootstraping decentralization while staying off-chain by using protocols like Sidetree and archiving on IPFS.
Progress towords openess, decentralization and being powerless. Think about decentralization and openness as more of a spectrum rather than 0 or 1. You won’t be decentralized from day one, and you shouldn’t be (for the sake of speed). Even if your protocol interface is centralized, make it open so developers can experiment with it and it feels like a protocol from day one, Twitter felt like a protocol even though they were corperate APIs. Eventually you’ll have to progress toword a state where the protocol survives if your company dies. In Product-led protocol development, Dan says:
A protocol is only as good as the number of independent and thriving clients, applications and businesses on it. A protocol with a lot of users but one dominant client is just an app with open APIs (for the time being).
Tokens might be good. but later. I’ve always been against tokens but I’ve changed my mind lately as I think it shifts the entity’s focus that’s developing the protocol from retaining users to the network size, make it possible for APIs to be public good and provide an economic incentive for the protocol to keep being upgraded. Fred Wilson puts it perfectly:
If Twitter had been built and monetized this way, things could have played out very differently. In the early days of Twitter, there were third party applications (Summize for Search, Tweetie for iOS client, etc). These were all built on Twitter’s API. If Twitter had imagined itself as a protocol instead of an application, these third party applications would not have had to compete with (or get bought by) Twitter. But at the time, there wasn’t an obvious way for Twitter’s founders and management team to benefit from a protocol-based business model. In this emerging model, Twitter could have adopted a protocol-based approach and issued a crypto-token, Twokens, that users could earn from things like amassing followers, reporting abuse, etc. Twokens could also be sold by the Twitter founding team to finance their operations. Crypto-exchanges could make a market in Twokens so that anyone who wanted to speculate on the future value of the Twitter protocol could do so.