There’s no one right way to build a protocol, so long as the method you select includes building demand for the protocol. However, depending on the type of protocol, there’s often a best suited go to market (GTM) strategy. Today, the way in which protocols build demand is often dictated by two GTM approaches:

1. The network-driven GTM approach
2. The product-led GTM approach

Let’s briefly discuss both and examine when each strategy tends to be most effective. 

Network-Driven Protocol GTM

Network-driven protocol GTM focuses on building a protocol with broad distribution and permissionless access, and then evangelizes others to build on top of the network. 

This approach often encourages adoption through:

• Permissionless access (e.g., Ethereum)
• Strong business development (e.g., Polygon)
• Token standard or contract integrations (e.g., Metaplex)
• Resource marketplaces (e.g., Akash, Livepeer)
• App integrations and robust documentation (e.g., XMPT, Reservoir, Lens) 

To be clear, this strategy does not just mean ‘build a protocol and people will come. Spoiler alert: they will not. If you do not help foster demand, you’ll be left with great code and no users. Rather, the network-driven approach must be paired with a GTM strategy that spurs initial traction, whether from funding potential applications, fostering developer activity, working with design partners/flagship customers, or otherwise forming partnerships and initiatives to bring demand to your protocol. Taking this approach allows a team to focus on the protocol and helps generate user activity that the initial team might not have anticipated.

Another core advantage of this approach is the ability to remain credibly neutral. Over time, it’s likely that an app and protocol will have divergent interests which can make it difficult to convince entrepreneurs to build on a platform. Entrepreneurs will opt for more neutral platforms if they believe your protocol will compete against them or impose controls like Twitter did by shutting off API access to its client-side competitors. 

Product-Led Protocol GTM

Product-led protocol GTM focuses on building a single application, tool, or product ‌ on top of a protocol in order to jumpstart demand. 

This GTM strategy is most effective for building:

• Initial tool suites or products (e.g., Mirror)
• Protocols where enhanced discoverability is important (e.g., OpenSea + Seaport)
• A stateless protocol (e.g., a library of contracts) such that the app is necessary for value capture (e.g. payments splits contracts)
• Some messaging apps (e.g., Dialect)
• Core primitives with a specific focus (e.g., Uniswap) 
• Consumer distribution of core network infrastructure (i.e., Hivemapper, DIMO)
• Marketplace-based protocols (e.g., Sound and Catalog with music NFTs)
• In a category where controlling unique content and experiences is critical (e.g., Oncyber)

The product-led protocol development and GTM strategy aims ‌to serve as the initial wedge and first driver of activity for a protocol. There are multiple benefits to building the core app that people use on your protocol including dogfooding the protocol, driving initial protocol traction, and possibly monetizing the protocol at the app layer. 

Dogfooding is when you build an app on the protocol, which your team can then use and test — and in doing so, discover what works and what needs more work, just as a user might. Initially, ENS was pretty challenging to use and required users participating in a Dutch auction process to buy their usernames. Eventually, the team built out an easy-to-use interface that made it much simpler to reserve and purchase ENS domains. Similarly, Uniswap built out its core app that is still widely used today, although now there are many other apps that also leverage the protocol’s liquidity. 

Secondly, the product-led protocol approach is important when a protocol’s competitive advantage comes from capturing user attention. For example, liquidity in NFTs (e.g., Seaport) isn’t locked at the asset level and therefore marketplaces currently compete for users based on product experience (e.g., Blur) or discoverability (e.g., ENS Vision).

Lastly, protocols that are stateless (read: easily forkable, and thus can lose its competitive advantage) can provide great utility, but still require an app attached to the protocol to capture the value. These stateless protocols often operate similar to traditional open source software where there’s a large enterprise that monetizes the open source software via premium features or a more robust product experience.

How to Choose Between Product-Led vs Network-Driven GTM

Regardless of your approach, generating demand for a protocol is critical to success. Protocols that create demand – whether by building their own products or by incentivizing activity – will outcompete protocols that don’t find ways to build demand.

As an observation, generalizable protocols – protocols that offer a wide array of use cases – often benefit from remaining neutral or fostering a wide array of applications. Conversely, specific protocols – protocols with a targeted user persona – often benefit from building an interface or app by leveraging the product-led protocol GTM approach. Furthermore, protocols that require owning user attention for value capture should also focus on building their own application in tandem with their protocol. 

Following this outline, most protocols will have a greater chance of succeeding by taking the product-led protocol GTM approach, as it allows protocols to jumpstart and own their initial demand. 

***

Disclaimer: This post is for general information purposes only. It does not constitute investment advice or a recommendation or solicitation to buy or sell any investment and should not be used in the evaluation of the merits of making any investment decision. It should not be relied upon for accounting, legal or tax advice or investment recommendations. You should consult your own advisers as to legal, business, tax, and other related matters concerning any investment. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by Variant. While taken from sources believed to be reliable, Variant has not independently verified such information. Variant makes no representations about the enduring accuracy of the information or its appropriateness for a given situation. This post reflects the current opinions of the authors and is not made on behalf of Variant or its Clients and does not necessarily reflect the opinions of Variant, its General Partners, its affiliates, advisors or individuals associated with Variant. The opinions reflected herein are subject to change without being updated.