"Products" & "Protocols" are NOT the same

They're vastly different, and you're probably failing at both. Here's why:

Intro

I’ll get right to it — I come from the world of crypto, where people are often building both products and protocols. These things are vastly different, with different purposes, different moats, and an entirely different approach required to make each/one/the other successful.

Here, we go back to the building blocks of each, working off of first principles. A lot of founders fail trying to do both in a mediocre capacity. Here, you can understand (and maybe execute) on each, independent of each other.

Note: I expect this document to be a perpetual WIP. I plan on refining it over time. Subscribe and periodically come back to watch how this doc evolves. I’ll try to time-stamp edits (or maybe just post new articles expanding on certain points). Feedback welcome.

Products

Products are applications that define user experiences. Successful products are built on a strong underlying market. To capture a market through your product, founders must connect a hyper-aligned subset of new or existing users in that market to their product. They can do this by cultivating a community of those users pre-product through reliable distribution channels.

The more cross-networking that exists within this community, the higher the coefficient by which that community can scale your growth. This means if the community isn’t cross-networking, or if there’s blockers to their cross-communication being amplified, the you should bring them into an environment where that’s seamless and constant. Doing this also gives your users better endurance when product features fail to amplify user retention or growth.

You want to treat your community as a model, setting up reinforcement loops and monitoring networking interactions with each node. This will teach you a lot about distribution, what’s important, and what’s not. Inserting explicit feedback loops to decrypt opaque interactions is important. This will help you tailor your product features and distribution.

From here, you should be iteratively funneling community members to new product features, seeing if those features solve user inefficiencies. Features should be focused on multiplying user output and user-generated distribution in tandem, accounting for the user friction of learning and utilizing your product features, plus the difficulties of sharing your product to an aligned network of additional users.

This allows you to focus on retention and growth — two outputs of the product you’ve built. Retention will come from effectively multiplying user output. Growth comes from user and company-generated, effective distribution of either incremental or exponential product advancements to a cross-networked user base within a market. Incremental product advancements grow your share of the market (e.g. better pricing, faster services). Exponential product advancements grow the market as a whole (breakthroughs in technology, UX). This is similar to “moving down the demand curve” in microeconomics with incremental product advancements vs shifting the demand curve outward with exponential product advancements.

Effective distribution is the synthesis of company-driven marketing and user-generated referrals (the push) to an aligned, cross-networked, self-sustaining, naturally growing user base with high conversion tendencies (the pull).

Protocols

Protocols are required infrastructure to make specific product experiences possible. Successful protocols enable products to channel a big, growing market into a high-utility function. In new markets, protocols will naturally serve one or two products to start, but failing to diversify to new products over time means the protocol is really just a controlled piece of infrastructure within a product’s stack, at the mercy of that product’s architecture decisions.

If a protocol is unable to graduate to serving multiple competing products, the protocol will die. Serving multiple products allows a protocol to aggregate a market’s resources faster than any single product can grow. This creates a sustainable flywheel where any new product that wishes to compete on resources must integrate that protocol or be severely disadvantaged.

Successful protocols enable product experiences to amplify its aggregated resources. Protocol resources are commonly misunderstood as public goods — this is incorrect. Successful protocols’ resources are common goods. Public goods are by-definition non-rivalrous and non-exclusive, which has no use for a protocol (if someone’s building a protocol aggregating public goods, they are wasting their time). Common goods are non-exclusive, but rivalrous. This difference enables a protocol to capture value by segmenting the rivalrous resources it has aggregated.

Protocols compete on resources and architecture.

In DeFi, resources are segmented by asset type and function.

Asset type is the difference between fungible and non-fungible spot assets, or each vertical of fungible and non-fungible derivative assets (like options, perps, parimutuels, etc.). As new asset types arise, so does the opportunity for new protocols to come in and aggregate those resources.

Function is delineated by the core interaction taking place with the assets. We’ve seen assets be pooled (AMM, pooled borrow-lend), or quoted (orderbooks, peer-to-peer lending), or bid on (RFQ process, block-builder/searcher relationship [MEV]). The aggregation of underlying assets is limited by the function between these assets, meaning there will be dominant, separate protocols specializing in the tradeoffs between different asset types and different function types.

In DeFi, architecture is segmented by intention and UX.

Intention is a function of security, scalability, and execution. Because of this, there should be at least two primary protocols serving a given function. Users should be able to choose between security, scalability, and execution tradeoffs — areas in which there is often no objective “right” answer. By extension, this fuels the propagation of different protocols serving the same product experiences.

UX is a function of interoperability, ease of adoption, and devops. UX is a serious moat for the products, teams, and resources interacting with a protocol. Interoperability, ease of adoption, and devops each have a corresponding scaling coefficient effecting a protocol’s aggregation of resources (growth). Maintaining developer (and corresponding product → user) velocity is a key focus for a successful protocol. Protocols win on aggregation and are fragmented by function.

Outro

I’m someone who’s built, scaled, and sold successful products (and now protocols) with a deep understanding of the differences between each. I currently work at mrgn group (known for marginfi & mrgn research), where I execute on this understanding, real-time, building permissionless financial infrastructure and sophisticated trading systems.

If you learned from this, or if you think you can learn from new writing, please subscribe. Outside of Substack, I primarily communicate through Twitter on a day-to-day basis. If you’d like to learn more about me, visit my website here.