paint-brush
The Fallacy of Onboarding the Next Billion Usersby@danielmcglynn
160 reads

The Fallacy of Onboarding the Next Billion Users

by Daniel McGlynnDecember 3rd, 2024
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

What's the best way to scale onchain? Building for scale helps get your product or service in front of more people. The counterpoint is that onchain products should be built for specific niche audiences.
featured image - The Fallacy of Onboarding the Next Billion Users
Daniel McGlynn HackerNoon profile picture


What does mainstream adoption even mean?


This post is taking part in the Devconflict x Kiwi writing contest


At Devconflict, a side event of Devcon 2024, a global conference held by the Ethereum Foundation, there was a debate about the best way to scale blockchain-based products and services.


The primary purpose of the debate was to determine the best way to scale or finally achieve an escape velocity that makes blockchain products more accessible to the masses.


Here’s the debate for full context:


Two core arguments emerged from the debate:


  1. Onchain products should be built to serve billions.


    Building for scale helps get your product or service in front of more people. Building for scale also helps with things like user experience and distribution strategies.


    This helps new users or entry-level users, but it also helps more sophisticated users find new and interesting ways to use the underlying product or service, which then helps fuel more adoption.


  2. The counterpoint is that onchain products and services should be built for specific niche audiences — or tailored to groups of people with specialized needs outside of the mainstream.


    The point here is mainly that building for billions requires making too many trade-offs and that onchain products and services will start to feel too much like the web2 stack.


    The logic here is that to reach a billion users and beyond you really need command and control structures like global corporations running things. On the flip side, building for specific use cases is more aligned with the spirit of decentralization.


    The goal here is to build technologies that can be combined or remixed to reach internet scale via supporting communities.


The crux of the debate is whether or not onchain technologies can really scale in a way that allows them to maintain the values of what makes them unique or alternative in the first place.


Here’s a quick breakdown of the two scaling strategies and then a take on which route makes the most sense.


Maybe the best scaling solution is more time. SOURCE

Build for Bilions

The build-for-billions mentality makes sense when thinking about internet scale.


One of the great things about building for the internet is that, for the first time in human history, you can build goods and services that are global and universal in a way.


Another advantage is network effects or the idea that an app or service becomes more valuable the more people use it.


During the Devconflict debate, both sides kept pointing toward messaging services like WhatsApp that have successfully reached a billion users.


To reach that scale requires getting a lot of things right. Maybe the thing that a product like WhatsApp got right is solving a fundamental need.


Messaging apps are a great example because they solve the fundamental problem of making it easy and cheap to communicate with other people.


What’s interesting about a product like WhatsApp is that the real utility — the end-to-end encryption is not the main feature that helped onboard its billion users. Instead, people use WhatsApp because it’s easy to use and it’s easy to find other people to connect with.


Likewise, like messaging, many onchain products solve fundamental needs like making it easy and cost-effective to send, receive, or collect digital assets.


In the spirit of build-for-billions, blockchain-based services should abstract away friction points like wallet key management or interoperability issues that make it complex to navigate between one product and the next.


The issue is that a lot of the complexity inherent in the product design of blockchain-based services is there for a reason.


The risk is that oversimplifying something like wallet key management requires handing control back over to a company or organization rather than an individual user, which could potentially lead back to a web2 user experience.


So the tricky part with onchain products and services is to build for billions but in ways that empower users rather than just recreate new versions of already existing technologies.


After all, while it is true that one of the fundamental reasons a service like WhatsApp was able to reach a billion users is because it is essentially “free.”


But the app is monetized via data collection for targeted advertising, which doesn’t exactly fit into the ethos or principles of building onchain.

Build for niches of engaged users

The alternative to building new internet technologies that don’t require billions of users to become successful is to build more precise solutions for a smaller group of users.


Building specific solutions enables two things:


  1. Products can be tailored, customized, or precise to solve a well-defined issue.
  2. Products and services can exist that aren’t necessarily billion-dollar businesses, but still generate a lot of value for end-users and the people creating them.


Building a successful product that is used and loved by hundreds of thousands or even millions of people can be really useful, but is it mainstream or even a name brand? And does that even matter?


Probably what matters more is if the product can operate in a way that is sustainable and can create value for the team who created and maintain it.


One of the promises of building onchain is that it enables new kinds of economies — more internet-native economies — that don’t require the same kind of big box store, mainstream media, kind of approach to success.


Put another way, maybe the goal of building for billions is antiquated — or like the Walmart of the digital age.


Maybe instead the goal should be to build small specialized stacks of products that can be easily stacked and combined with related products to build suites of services that leverage things like network effects and global access, but do it in a way that is also extremely custom and bespoke.

How to achieve internet scale while staying true to open, permissionless access and non-custodial control?

The most obvious answer to the question about how to scale new kinds of internet services is just to build products that are better than anything that exists right now.


For people concerned about privacy, that means building the best privacy product — one that delivers both the best user experience and the best alignment with privacy-preserving principles.


For people with concerns about having their retirement funds rugged by banks, it means building a streamlined non-custodial experience — one where key management becomes as easy as saving a username and password.


For people worried about the rise in nationalism and closing borders, it means building technologies that are global and multicultural at the foundation — where there is no off switch available to politicians or people pretending to be politicians.


Maybe the key to scale is not so much thinking about success in the traditional web2 context of milestones of millions of users.


Maybe the right way to think about scale for onchain services and beyond is to think about how the product is composable, durable, and accessible.


If the answer is yes then it can become part of the fabric of the open internet. The product or service might even get remixed into something else or used by some other project.


After all, the internet works best when it operates as networks of networks — guided by rails of common protocols — but is also dynamic, open, and adaptable.


This post is part of the Open Money project.