tldr: Building web 3 startups is hard, as you have to balance product-market fit and iteration speed with community and governance. To achieve this balance, a mix of strategies must be deployed- using concepts from 20+ years of startup history, political science and human behavior.

Visionaries and dreamers have defined innovation culture in the startup ecosystem of the last 3 decades. In fact, we find ourselves in a world where cult founder personalities are aplenty, look no further than Elon Musk, Bill Gates and Steve Jobs.

This makes sense. Elon Musk’s vision for affordable electric cars, and his drive to bring that vision to reality is what gave us Tesla. The company’s mission was always driven top-down by what Elon Musk wanted for the future. In a sense, Tesla was an extension of Elon’s ambition. The recipe for creating successful startups is generally based on this ideal- start with a visionary founding team, and then execute that vision, iterating and pivoting on ideas as you go along.

Founders -> Product/Market Fit

In this era of startups, there is one mantra that rules above all: product-market fit. The founders have to build something that gets them closer to their vision, yes, but more importantly, they have to build a product that people want. The founders are responsible for finding the market, building the product, and creating the future. Marc Andreessen wrote in his 2007 blog:

In a great market—a market with lots of real potential customers—the market pulls product out of the startup.

The calculus is simple: find a good market with a vision for a better future, and then build in that direction for success. And it worked brilliantly, bringing a16z some of the most successful software startups on the planet.

Introducing Web 3

Web 3 envisions a different reality for startups. With guiding values of wide ownership, decentralization and open source, founders and central control are considered a liability in the new internet. Web 3 proponents point to the gradually extractive nature of Web 2 founders and startups, who eventually turn from helping their users to exploiting them for investor and personal profit. In contrast, Web 3 believes in community ownership to limit extractive motives from the core founding and investing team, which also limits the power the core founding team has to change their own product. Proprietary and closed software- exit stage left.

Progressive extraction by platform web2 companies - a16z

Furthermore, the computational primitives of the blockchain enable new governance and corporate structure paradigms. On-chain governance and its associated utility programs enable web-native democratic activity, unlocking global scale co-operation. Founders no longer have to make all the decisions for their vision, the decision making power can be transferred to those who believe in their narrative and (literally) buy into their vision. Founders can simply promise- that the future they envision is possible. And, encoding this promise is the programmable ERC-20 token. With this primitive, a challenger to product-market fit is born: market-protocol fit.

Products vs Protocols

Before we look at market-protocol fit, it is essential to understand the key differences between protocols and products.

Let’s look at products first. Products are user-friendly, focus on implementation and aim to achieve a monoculture- a world where everyone uses the product. In contrast, protocols are open, built for developers, are composable and focus on achieving a diversity of applications that sit on top of them. For a more practical example, consider XMPP, the open messaging protocol and WhatsApp which is a product built on closed-source, centralized software. Anyone can build an XMPP client, propose changes to the protocol or build on top of it, however only WhatsApp’s core-team can use the underlying WhatsApp system. With WhatsApp, there are no third party clients, and there is no thriving ecosystem of WhatsApp apps. At the same time, driving XMPP adoption and integrating new features must consider all of its third part clients, which means that it often takes much longer to develop new features into XMPP than into WhatsApp.

In short, protocols develop a lot slower than products as they cannot evolve at the same speed as a LEAN product team. However, protocols are generally more robust and have the potential to generate a pluralistic future with a diversity of composable applications.

Ethereum is a great example of a successful developer protocol. It is open source, permissionless and allows developers to build vibrant services and applications on top of it- Uniswap, Compound, Balancer etc. It is well documented, cares about interoperability, software diversity and decentralization.

Fundamentally, the core ideals of web 3 are decentralization, ownership and composability. This means, web 3 is about protocols, not products. With the composable primitives on Ethereum, Avalanche and other Layer 1s, it is possible to finally accrue value at the protocol layer instead of the product layer. In Web 2, HTTPS powers most of the world’s products but accrues none of the captured value. Web 3 flips that model and lets protocols and open-source standards accrue value for the services they provide.

In fact, in a Web 3 model, since all products are built on composable open standards- more value accrues to the protocol layer than the product layer.

Progressive decentralization

So how can we build and market protocols? We can start by trying to apply the product-market fit strategy to protocols. Let us use Uniswap as a practical illustration.

Define a problem [Uniswap: it is hard to swap tokens]
Have a vision [Uniswap: people can easily swap between any token, ever present liquidity]
Build an MVP [Uniswap: Automated Market Maker v1]
Iterate and test and build [Uniswap: raise venture funds to pay contributors]
Release the protocol

But recall, two of the core ideals of Web 3 are decentralization and ownership. But herein lies the problem, Uniswap likely wouldn’t have been able to build Uniswap so quickly if it was decentralized. Firstly, it is hard to achieve consensus on a vision amidst a large group of people. Even if that’s possible, it is even harder to agree on a single approach to achieve that vision. Lastly, in large groups, no individual feels full ownership and responsibility, and coaxing this group to build and iterate requires a lot more effort than in a small LEAN team with more at stake.

In essence, smaller teams move faster, iterate quicker and converge on a solution even if the solution is a local minima which isn’t the most optimal. Convincing large communities to achieve this directionality is quite impossible. A comparison can be drawn to a gradient descent operation. When a small team can quickly agree on the shape of the design space, they can quickly find a local minima to move towards. But in a large team, the landscape of the design space is fuzzy and not globally agreed upon, leading to a lot more difficulties in deciding which way to move.

This has led many startups and VCs to recommend progressive decentralization. Find product-market fit, and then introduce governance and handover control to the community. The order goes product/protocol-market fit -> build a community -> transition to a decentralized protocol.

It is also possible to use the mental model that token-based protocols are just special forms of products- namely the combination of a multi-sided platform and an open-source project.

Token-based products combine ideas of multi-sided platform products and open-source projects. This is great news, because we don’t need to radically reinvent “product”, or chase something different than “PMF”.

-Trent McConaghy

The product-market fit strategy works well for both multi-sided platforms (Uber) and open-source projects (Kubernetes) where if the product solves an actual need, and the market demands this solution then the product starts to gain traction on its own. And if a protocol is simple a composition of a multi-sided platform and an open-source project, then the same principle should apply.

Market-protocol fit disagrees with this.

Market-Protocol Fit

If progressive decentralization relies on directional and intentional startup movement, market-protocol fit is throwing everything at the wall and seeing what sticks. Market-protocol fit enables organizations to explore the entire solution space in parallel, similar to an evolutionary algorithm, where there is no control over individual agents.

As such, top-level behavior must be an emergent property of bottom-up actions by agents. This is necessary for tokenized ecosystems; otherwise they’d be centralized!

In other words, market-protocol fit approaches the problem by thinking about crypto-economic protocols as market frameworks looking for product applications. In this decentralized format, the market looks for the product that fits its needs, market-product fit. This is achieved by first and foremost, distributing tokens to a wide number of peoples along with a narrative or a guiding mission. Then, proper governance mechanisms and economic incentives are put in place to reward parallel explorations of the design space that achieve this narrative. Through that:

The work of exploring parallel narratives, discovering emergent use cases, and testing solutions is distributed among members of the wider ecosystem such that the rising tide lifts all boats.

In market-protocol fit, the founder does not have the sole responsibility for finding solutions to the problem. They only need to convince the community that this is a problem worth finding solutions for, and that the rewards from this will be plentiful. Ethereum is a great example of this in action, its prevailing narrative was to become a “world computer”. Eventually, this lead to many developers building solutions on top of it that made it a self-fulfilling prophecy. Market-protocol fit startups might however still need to pivot, to experiment and try different narratives that align the founder vision and public court of thought.

Can the market fit the protocol?

I can list numerous examples of product-market fit success stories but not a single instance of market-protocol fit. DAOs are the latest exploration into market-protocol fit, and they try to support unstructured exploration and solution discovery. But as anyone who’s been in a DAO knows, this tends to make it chaotic, slow and complicated to navigate.

Some would argue that the Ethereum Project is an example of market-protocol fit. I would humbly disagree. The Ethereum core team was addressing a specific problem, the ability to execute complex transactions and contracts in a trustless way on chain. Even before the community was around, the core-team of Ethereum were building and iterating to achieve the product. The developer traction that Ethereum has is symbolic of product-market fit not market-protocol fit. Ethereum is a product for developers.

However, the products built on top of Ethereum do serve to push a narrative that Ethereum wanted to achieve- building a new, fairer internet. If you take a big picture view, and look at Ethereum’s problem statement as “Solving the information and power asymmetry in the internet”, then Ethereum seems like a market-protocol fit approach. But on a smaller lens, Ethereum provides the developer tools and substrate for developers to build new, fairer and more open applications. In that sense, Ethereum is a product persuing product-market fit.

It seems to me that the conclusion would be that no matter what, your initial product/protocol has to find product market fit. Ethereum could only lean on their strong developer ecosystem to build out solutions for their vision after they built a strong product with product-market fit to attract developers. Possibly, the concepts of product-market fit and market-protocol fit are not exclusionary but rather different stages in a pipeline.

You set up a broad vision for what you want to achieve [Ethereum: building a fairer internet on a world computer]
Create an initial substrate/protocol for people to build on that unlocks a design space for that vision [Ethereum chain]
Iterate until product-market fit attracts developers to build on the protocol

Until this point, this was all about product-market fit. Now,

Push the narrative and vision to the developers and teams building on the protocol
Within some constraints in the protocol, allow builders to search the available design space [Dapps on Ethereum]
Selectively reward projects and proposals that move towards the desired narrative [Grants, Gitcoin, etc.]

This is the transition to market-protocol fit. The product, makes the market, makes the protocol. It’s product-market-protocol fit. And this requires startup teams to make a transition in strategy similar to what progressive decentralization describes. At the start, in product-market fit mode, it helps to raise equity rounds, build your initial substrate and have a LEAN team.

Once a certain critical mass of adoption has happened, the transition to market-protocol fit entails distribution of ownership, proper governance structures, ways to incentivize movement towards the original vision while preventing deviations. Startup founders in Web 3 act as CEOs of companies and then transition to members of parliament in states.

Final words

This transition can be both nerve-wreaking and complicated, but also exciting and rewarding. Once you’ve successfully completed the transition, the protocol lives on, independent of your ability to contribute to it. It would have obtained a life of its own.

Given the arguments laid in this post, I believe that the answer to how to build web 3 startups seems to be not “top-down” or “bottom-up”. We need to build top-bottom-up-down.

🔝

Top Bottom Up Down

How to balance product-market fit and iteration speed with community and governance?