Web3 Scaling Considerations
The dot-com boom and magical internet moments flood my mind when thinking back on the 90s. Despite the innovation, many just remember it as the dot-com bust. It was traumatic for an entire generation of investors who knew "up only" (sound familiar?!). The Dow closed up about every year from 1982 to 2000. It was an unprecedented event for them.
And here we are in 2022, with many tech stocks crashing and crypto markets imploding. Startups across all stages are trying to figure out how to adapt, survive, and thrive. This post provides some practical advice to early-stage web3 teams.
Premature scaling is the leading cause of death for startups
What can future founders and newer investors learn from the dot-com bust? To help answer this, I found a paper from 2005 called Searching for Ghosts: Business Survival, Unmeasured Entrepreneurial Activity and Private Equity Investment in the Dot-Com Era.
The paper highlights how the popular ‘get big fast’ strategy was to blame for many implosions. “Many of these grew rapidly, but were unable to generate revenues to support their expansion and crashed spectacularly.” It’s unfortunate because the problem wasn’t always with the viability of businesses. It was with their valuations.
Not everyone blew up. Many startups who remained appropriately sized actually survived. “As the bubble burst, valuations were brought into line with the realistic scale of the typical online venture, but the underlying, exogenous change in Schumpeterian opportunities persisted.” These smaller companies grew slower and more organically, surviving the shakeout.
The median age from founding to IPO hit a low of 4 years for those going public in 1999. Startups raised war chests at extraordinary valuations. Spending was the name of the game. Nobody seemed to care much for business fundamentals, like costs and margins. Associate your company with the word “internet,” and you’d instantly increase the perceived value of your company.
The primary lesson here is pretty simple. As my partner Greg Sands always says:
"Premature scaling is the leading cause of death of startups. Stay compact until you hit product market fit.”
The advice sounds too basic to be helpful to the uninitiated. It's hard in practice, especially during frothy times. Many outside pressures contribute to the desire to create a facade of perfection and induce FOMO. Founders often want their team, investors, media, and users to all think they're more valuable and prepared for growth than they are. But raising, hiring, and expanding before being ready is often a recipe for pain. Some of the spectacular implosions could have iterated their way towards a useful, sustainable product if they just spent their time and focused on doing so instead of growing prematurely.
The web3 way - get [community] big fast
“Community” isn’t a new concept on the web. eBay opted for a self-regulating system of feedback forums and reputation scores. They embraced that they sold nothing and that all value came from their community. AOL was also highly community-oriented, doubling down on making communications easy with email and public and private chat. When the internet went mainstream, it not only connected computers but also the users of those computers to each other. However, all of these companies focused on their community aspect post product launch.
A typical order of events for web3 product development involves building out a community before the product launch and launching a token at some point. Some teams launch a token sooner in their product's life than others. The benefits mostly revolve around initial user acquisition, solving for the cold start problem. The ol’ chicken-and-the-egg. Who will use YouTube without videos when nobody knows it exists to even upload to (after all, the initial 19 second upload stating that elephant trunks are cool came from a YouTube co-founder)? On top of that, an initial “community” combined with token incentives is theoretically a mechanism to keep early users engaged as evangelists to help grow the user base.
While conceptually appealing, the model has costs and adverse incentives as highlighted by Hasu on a recent Bankless episode. Crypto companies essentially "go public" extremely early. It's their GTM.
Why does it work this time if it didn't work in the 90s? Well, it might not. We're not sure yet. We’re still in the experimentation phase. Here are a few of the widely accepted problems:
- Attracts mercenaries.
- Introduces complexity.
- Distracts from long-term priorities.
- Over indexes on awareness and activation rather than retention.
- Enriches early stakeholders before hitting meaningful milestones.
With that said, experimentation is healthy. I’ve enjoyed watching Chris Maddern navigate these waters with Floor NFTs. And I’m hopeful that my friend Jon Brovda and his company GamerGains will be able to turn their 40,000+ Discord members into active, loyal users after launching their platform.
Tips for web3 teams
Some teams probably don’t care about the problems because they’re in it to get rich quickly. But I’d like to offer some advice to top-tier product teams looking to improve their chances of success beyond the usual advice applicable to all sectors.
- Use a token as a tool to help you reach PMF faster than if you didn’t have one.
Always remember that the goal of any early product team is to iterate towards PMF. Never forget that you need to build a fantastic product! It needs to be some combination of useful, understandable, fun, innovative, and easy. If a token helps your journey towards PMF, then great. But if you’re nowhere close and a token isn’t critical, then it’ll be a distraction that’s impossible to unwind later. - Think of your community as a resource to use, not to grow.
Many teams want to grow their communities as large as possible. “We have 4,000 Discord members!” It’s mostly a vanity metric. And as Brian from Rabbithole shared, over-gamifying often leads to a toxic community. Not all anon members are equally valuable to you for your product. Try to understand who your community members are so you can leverage them for customer discovery (like Adam Fern) and understanding if any fit your archetype user profile. Value actual contributors who are around to do more than take financial advantage of any low-hanging incentives. Don’t wait until you’ve launched a product to interact with users. Leverage the community you already have to influence product decisions. - Define your archetype user(s).
When building a product and working through customer discovery, you must have hypotheses of your archetypes. It’s improbable that everyone with a MetaMask wallet is qualified to be a helpful, valuable, engaged user of your product. A smaller number of these community members will be much more useful than a more significant number of mercenaries chasing incentives and rewards. - Rethink if building in public is right for you.
In a recent conversation with the DAOHQ team, they mentioned how building in public has under appreciated consequences. Others will pay close attention and copy you if you’re working on a good idea. Releasing frequently is valuable but consider exploring new opportunities and features in closed beta groups. This can be a much safer approach to building a head start. - Focus on retention as much as user acquisition.
Finding new users is often expensive, and you’re unlikely to get churned users to re-engage. It’s even more challenging in crypto, where users are generally anon or pseudo-anon. You don’t have their contact info to send a text or email (although this will likely change; see Mirror Subscriptions). You need a way to monitor for signs of retention problems. Be honest with yourself if you’re running a rich incentive program. Play the scenarios out a few years to think through what will happen when they dry up. I’m excited to follow AGM as he works to help web3 teams track attribution. I’m also eager to see other teams leverage tools like Luabase to better understand user behavior and the ROI of initiatives.
Further Thoughts
Reality is, the regulatory environment is playing a critical role in shaping the GTM approach common in web3. Most rational operators wouldn't opt to increase complexity, distribute ownership, and distribute decision making to a wide audience sooner than they have to. How would web3 GTM motions look if regulations were different?
I’m currently an investor at Costanoa Ventures, an early-stage firm focused on fintech, data infrastructure, crypto, and security. You can get in touch with me on Twitter or LinkedIn.