Product-Driven Protocols: The Missing Link in Web3’s Innovation Problem

The most common critique of Web3 is that we still don’t have many useful, widely adopted products. While this often misunderstands how new technologies diffuse (Rogers, 2003), it raises a fair question: Could we have had compelling products by now if we built differently? I believe yes, and the reason we didn’t is because we build protocols before products. This essay argues for a different approach: product-driven protocol development. 

What Is a Product-Driven Protocol? 

A simple definition of a product-driven protocol is a protocol built the same way products are built: you launch fast and iterate fast, both enabled by being sufficiently decentralized, with an added step to achieve developer–protocol fit along the way. Another definition might be: “A protocol that solves X while delivering shippable intermediaries.” 

The biggest advantage of building a product-driven protocol is, as Dan Romero put it, that “you’re in control of your own destiny,” because the core product you’re building ultimately determines whether your protocol succeeds or not. 

The Twitter API Lesson 

Developers built on Twitter’s API because Twitter already had users. The social graph, not the API itself, created the opportunity. Third-party teams built the first mobile clients, early interaction patterns like pull-to-refresh, and services with millions of users. They were innovating because demand was visible and immediate. 

But when Twitter shifted toward monetization, it restricted access, acquired or shut down third‑party products, and imposed caps on client growth. The lesson here is not that Twitter acted wrongly, it acted rationally as a company controlling its platform. The lesson is that Web3 protocols tried to copy the API strategy without first achieving the user base that made the Twitter ecosystem possible. As Dan Romero puts it perfectly, 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”. 

Many Web3 protocols skipped the product stage and assumed that openness alone would attract developers. But developers do not build for abstractions, they build where users already are. 

Web3 can finally achieve what early Twitter, and other major products early on hint at: a foundation for open, permissionless innovation, but only if users come first. 

Design Framework 

At the core of building a product-driven protocol is the principle of sufficient decentralization

(Srinivasan). Web3 often assumes that true decentralization requires being maximally on-chain, but in practice most protocols are not money protocols—and therefore do not need such rigidity. The Internet itself is decentralized despite DNS, HTTP, and SMTP being entirely off-chain. Users 

can switch browsers, email providers, hosting services, and clients at will. This type of optionality, not full chain-level execution, is what enables practical decentralization. 

In many cases, off-chain protocols may even be more decentralized in practice because they naturally support interoperability and provide users with an implicit “usage-as-vote” mechanism. The critical question becomes: Are we decentralized enough that users can exit and run their own client if they need or want to? And second: How do we reduce the cost and friction of exit toward zero over time? 

A simple example illustrates this dynamic. Suppose Company A wants to introduce an “encrypted” cast type for Farcaster, while Company B resists adopting it. Company A can ship the feature regardless. If users find it valuable and enough of them rely on it, Company B will be pressured to support the new type to remain compatible. Users effectively vote by switching clients while retaining interoperability. If this same data structure lived inside a smart contract, the only path forward would be to fork, fracturing the protocol rather than evolving it. 

Worse Is Better: Evolve Through Use, Not Ideology 

This approach closely aligns with the worse-is-better philosophy in software design (Gabriel, 1990): build something small, useful, and easy to spread; improve it through usage. Systems that succeed often start simple and evolve under real-world pressure rather than being engineered perfectly in advance. 

Gopher, one of the Internet’s earliest data-access protocols, lost to the World Wide Web in part because its core team over-optimized for their own assumptions about how developers should use it. The lesson is simple: your protocol must be general and flexible enough for developers to build things you haven’t anticipated. 

Platform economics research shows that platforms succeed when built on top of successful core products (Parker & Van Alstyne, 2018). Developers need predictable rules, user demand, and confidence that the system will persist. 

The 10 Fan Developers Principle 

If creators aim for 1,000 true fans, protocols should aim for 10 true-fan developers. An early community of deeply committed builders is essential for an open and decentralized ecosystem to emerge later. These developers not only extend the protocol but also stress-test it, shape its direction through real usage, and model what is possible for others. 

Open-source governance research (O’Mahony & Ferraro, 2007) shows that resilient systems evolve from founder-led coordination to distributed stewardship. Product-driven protocols follow this logic intentionally: early builders form the nucleus of that future stewardship layer.

As Chris Dixon notes in The Importance of Predictability for Platform Developers: 

“The most successful platforms try to mitigate these risks for developers… One way to mitigate platform decline risk is to launch the platform after the platform’s core product is already successful… 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.” 

Progressive Openness, Decentralization, and Becoming Powerless 

Decentralization and openness should be understood as a spectrum, not a binary. You will not—and should not—be fully decentralized on day one. Early centralization is often necessary for speed. What is important early on is that the protocol feels open even if parts of it remain centrally operated. Twitter, for example, felt like a protocol in its early years despite being a corporate API, because developers could experiment freely and build real products on top of it. 

Over time, a product-driven protocol must move toward a state where it can survive even if the founding company disappears. As Dan Romero puts it: “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).” 

This progressive shift, from founder-led coordination to distributed stewardship, is also reflected in open-source governance research (O’Mahony & Ferraro, 2007). Resilient systems intentionally evolve from centralized leadership to shared, community-driven maintenance. 

Tokens may play a role, but only later. Although tokenization has often been misused, it can eventually help shift the protocol’s center of gravity away from retaining users and toward growing the network as a public good. Tokens can also create durable economic incentives for ongoing maintenance and upgrades. 

Fred Wilson illustrates this with the counterfactual of early Twitter: 

“If Twitter had been built and monetized this way, things could have played out very differently… In this emerging model, Twitter could have adopted a protocol-based approach and issued a crypto-token—Twokens… The founding team could have financed operations by selling some, while users earned them through contribution, and exchanges enabled speculation on the future value of the protocol.” 

The goal is not token-first, but token-when-ready: use them only after product-market fit, when they can reinforce decentralization rather than distract from building.

References 

Gabriel, R. P. (1990). Worse is better. Lisp and Symbolic Computation, 3(2), 123–145. Varun Srinivasan. (2022). Sufficient Decentralization for Social Networks. 

O’Mahony, S., & Ferraro, F. (2007). The emergence of governance in an open source community. Academy of Management Journal, 50(5), 1079–1106. 

Parker, G. G., & Van Alstyne, M. W. (2018). Innovation, openness, and platform control. Management Science, 64(7), 3015–3032. 

Rogers, E. M. (2003). Diffusion of Innovations (5th ed.). Free Press. Dixon, C. (2013). The importance of predictability for platform developers. Wilson, F. (2021). Why Web 3 matters. AVC.