# Product-led protocol development

Source: https://danromero.org/product-led-protocols.html
Kiwi News: https://news.kiwistand.com/stories/Product-led-protocol-development?index=0x65b58c55a03b15c1a5c879539198e6b32d9fc349c4d2bc1a83d4b2728e8d2afeecb30eae
Submitted by misha on 2024-01-27 UTC, 7 upvotes, 1 comment

## Summary

Dan Romero argues that a protocol meant to reach internet scale should be built product-first, starting from that end goal and working backwards. He says a protocol is only as strong as its number of independent, thriving clients, applications and businesses, since a protocol with many users but one dominant client is effectively an app with open APIs. He adds that developers care more about addressable quality daily active users than about tech stack, so a builder should first ship a high-quality initial app that attracts enough users to make developers interested in building on the protocol.

## Article

Dan Romero

October 14, 2022

If your goal is to build a new protocol, start from the end goal—internet-scale protocol like DNS, HTTP, SMTP—and work backwards.

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). Practical alternative clients—not theoretical—matter for exit with interoperability.

Developers care far more about addressable quality daily active users (qDAUs) than tech stack. A protocol with a lot of quality qDAUs and slightly worse technology will likely attract more developers than a protocol with better technology but few qDAUs. Quality defined as not bots or accounts that sign up and immediately churn (creating a ghost town effect).

Users don’t use protocols, they use apps. So if your goal is to build a protocol, you should build the initial app that’s high quality enough to earn the attention of enough qDAUs that developers start finding building on the protocol interesting.

Lastly, it’s easy for people to fall into the Field of Dreams fallacy for protocols — “if you build it, they will come”. Can’t expect others to spend the time and effort to build high quality products if you’re not willing to do it yourself.

## Comments

**tim**: > A protocol with a lot of users but one dominant client is just an app with open APIs (for the time being). Practical alternative clients—not theoretical—matter for exit with interoperability.

Haha, I wonder if his view has changed now with Warpcast having 80-90% market share!