3 things token protocols could learn from developer-centric startups

Written by kylebrussell | Published 2017/12/06
Tech Story Tags: blockchain | cryptocurrency | protocol-tokens | token-protocols | developer-centric

TLDRvia the TL;DR App

In all of the excitement around cryptocurrencies, ICOs, blockchains, and bubbles, there isn’t enough talk about the practical work that should go into bringing a token-incentivized protocol to market successfully.

I’m not talking about fundraising via an initial coin offering —there’s probably too much information out there on that subject — but the things a team can do to make it more likely that people will have the interactions with their network that will bring value to the associated cryptotokens in the long run.

After spending a lot of time working with folks building developer-centric startups and token protocols, I’ve thought of a few things the latter could learn from the former. These practices most directly apply to networks which allocate computing resources, like Ethereum for compute and Filecoin/IPFS for storage.

The path to market for these most resembles those of startups looking to appeal to developers by enabling new capabilities in their apps or making it easier to implement features that are valuable but have previously been expensive/difficult. Think Stripe or Twilio. A few things protocols can learn from these startups:

Actively marketing to potential users

Strengths and weaknesses are often generally closely linked, whether you’re talking about a person, technology, business, or protocol. One of the biggest strengths of token-incentivized protocols is that the speculation around the token incentivizes the supply side of the network to spin up (i.e. as the price of Bitcoin went up, it was more lucrative to be a miner), which overcomes one of the biggest challenges faced when spinning up a multi-sided network or marketplace.

Projects still need to think about getting the other side of the network spun up if the token is to have underlying value that sustains past initial speculation, especially as the space matures and potential investors/network participants become more discerning with their attention and resources.

This means maneuvering through the transition from speaking to the early adopters who help mold the initial technology and community to the broader market of developers who could take advantage of a protocol. One could argue that token-holders have decentralized this kind of evangelism, but I think there’s still a strong argument for meeting developers where they are (whether that’s conferences, forums, Slack channels, or elsewhere) in addition to letting the speculative clamor around a protocol draw developer attention. Even with (especially with?) all of the noise around the crypto token/asset phenomenon, you can’t assume that the people who could end up building a killer app will discover you protocol.

Documentation and tutorials matter

Token protocols that raise comparable amounts to startups offering tools for developers should meet or exceed the bar those startups set for documentation and tutorials. That means example code that works with that latest version of the protocol, explanations with as few ambiguities as possible, and tutorials that quickly get developers to an “aha!” moment, where they feel like they realize the power of what’s been made available and what they could build on top of a protocol.

Among those points, I think tutorials are an undervalued point of leverage within these communities, as they can shape what developers think is possible. The Ethereum project has done a great job of highlighting how simple it makes spinning up new cryptocurrencies and Kickstarter-style crowdfunding campaigns, two of the early killer apps on top of its network.

Offer multiple curated ways for the community to interact

This one is perhaps the most obvious to folks working on these kinds of projects, given the familiarity with/backgrounds in open source software. Basically, to diffuse knowledge within a community you want to give people multiple high-quality forums for discussion. Slack is great, but you should also have more persistent places for discussion, like Reddit and traditional forums. It’s very valuable to be able to give the community a way of indicating what kinds of discussions they find valuable to consume and link to insightful conversations.

Call me a snowflake, but I also think it’s incredibly important to make these forums places for healthy discussion where people can ask dumb questions. If you’ve got millions of dollars worth of BTC/ETH/fiat on hand from a token sale, you can afford to hire an experienced community manager who will cultivate productive conversation and nip abuse in the bud.

A wide swath of projects that have launched tokens have put out little more than whitepapers at this point, so this post wasn’t written to call out anyone failing particularly hard on any of these fronts. But now that real money has been distributed to teams building protocols, they should take these go-to-market considerations just as seriously as the technical underpinnings of the protocol and issues around governance.

There are other approaches protocols can take as they go to market: trying to serve existing businesses by making workflows faster/cheaper/simpler/safer and doing traditional sales, and franchising, for networks where nodes are more differentiated and will try to bring in users on the other side of the network for their own benefit. As in traditional startups, what you build and how you bring it to market should be deeply intertwined, so you should already have some sense of this at even the whitepaper stage of development.


Published by HackerNoon on 2017/12/06