Tokens are an exciting new primitive that facilitate user ownership; they’re a novel tool founders can deploy to create healthier, more sustainable networks. But that newness also means there’s not a well-worn path for founders to follow. Launching a token too early risks skewing product-market fit, yet releasing a token too late might result in it not meshing well with the product or leave the project chasing its peers.
To tackle this problem, founders can use what I call the “Core to the Product” framework. Quite simply, the more necessary a token is for the product to function, the earlier it should be released. On the other hand, the more adjacent a token may be, the more optionality there is for the function of the token and the longer founders can delay a token launch. This core vs. adjacent framework is a spectrum, and many tokens fall somewhere in the middle.
Let’s walk through a few examples.
The core end of the spectrum might include Layer 1s like Ethereum, Bitcoin, and Solana. These tokens act as native economic units of account and are critical parts of the protocols’ functionality. They also often act to secure the network. That these tokens were launched at the outset of a project makes sense – the product cannot function without them.
Additional examples close to the “core” end might be scenarios in which it’s valuable to *intentionally *shape user behavior with tokens. Community-driven IP can fall in this bucket. Shibuya, for instance, uses its tokens to let its audience decide the storyline. Using token ownership to facilitate such user behaviors is a new product experience unlocked only by web3.
NFTs present another interesting case. They frequently sit near the “core” end, but can technically fall anywhere along the spectrum. In many instances, NFTs are the product. Other times, they help facilitate activity tangential to the main attraction (e.g., NFT-ing in-game assets). And yet sometimes, NFTs are fully adjacent (such as with POAPs).
Other middle-of-the-spectrum functions may include activities like bootstrapping – important to the product / adoption, but not absolutely necessary. Incentive programs tend to span the spectrum: temporary ones may be closer to the adjacent end, whereas incentives supported by protocol revenue might be closer to core.
Finally, the adjacent end can encompass things like governance rights, public goods funding, and much more. Despite not being core to the product, these tokens are still incredibly important: they can be used to supercharge what’s already working with the core product, while also helping create and sustain user-owned networks.
“Adjacent” tokens should be launched only after finding product-market fit. This is because adjacent tokens enjoy a broader design space – there may be more options to parameterize governance, integrate token functionality with new product lines, or creatively incentivize community engagement.
Importantly, taking time to launch a token doesn’t mean punting consideration of a token – in fact, founders should very much continue to think about the potential role of a token as they build. Product-market fit, additional ecosystem participants, and maturation of a community can help illuminate the ways in which a token can grow and strengthen that product’s network.
Ultimately all token design decisions come down to the question “what are you optimizing for?” This “Core to the Product” framework provides a guide for thinking broadly about optimizations regarding the timing of a token launch, but the decision will always be project-specific. For founders trying to determine where their project lands on the spectrum, I’d recommend testing the extremes: imagine both what the product would look like absent a token, as well as what a “core” token could look like. The easier it is to imagine the product functioning without a token, the less urgent it may be to launch a token at outset, but the more important it is for founders to consistently explore ways in which tokens can amplify their products as those products mature.
At Variant, we partner with founders at the earliest stages to think through these types of decisions and more. If you’re building on the bleeding edge of crypto, we’d love to collaborate. You can reach me on Twitter or at email@example.com.