A Token is Not a Short Term Carrot, Ceci N'est Pas Une Pipe

MagrittePipeConsider the much-discussed painting, The Treachery of Images ("Ceci n'est pas une pipe"; "This is not a pipe"), by the French surrealist painter, René Magritte (1898-1967).

Magritte highlights for our consideration the idea that an image of a pipe is not the same thing as the pipe itself. His statement is taken to mean that the painting itself is not a pipe; it is merely an image of a pipe. Hence, the description, "this is not a pipe”.

Conversely, a token is not a short term carrot, nor a stick for that matter. Just having a token doesn't mean that you have a working business model attached with it.

Amidst the flurry of ICOs we are seeing, a trend is emerging in token distribution practices: reserving tokens to incentivize users to participate or take action.

There are different ways this type of incentive is being thought of, one of which resembles getting a free drink coupon. So, you enter the bar because you were given a free drink ticket. You order the drink and mingle as expected, giving the illusion you are hooked and will stay, but do you actually stay and spend more? You could leave for a variety of reasons, but the ticket alone wasn't the clinching factor in keeping you there. It was only good enough to get you there to try it.

Just as companies need a strong value proposition [read], the token being part of your product, also needs to have a strong value proposition:

https://twitter.com/wmougayar/status/885815958136397824

 

Acquiring users & getting the token to work right with said users is a dual challenge. Doing both doubles the difficulty factor: 1) gaining a critical mass of engaged users (or developers) for your product, and 2) finding a sustainable utility factor the token together.

This brings us to the topic of Token Utility Fit (TUF). It is analogous to product-to-market fit (PMF) in startup-speak. For a refresher, please read Product/Market Fit is a Continuum.

Just like PMF, until the token fit is evident (via metrics), you are still at the hypothesis level.

Looking at the market, I'm seeing two types of startups and companies who are contemplating, or implementing ICOs, and I'll admit being in the enviable position of interacting with several of them, each week.

One type is the new startup that aims to design the token as part of a new product. They are typically targeting an existing market, but with the token as the novelty. Example: Blocktix, for event promotion and ticketing, or AdEx, who wants to create an decentralized Ad exchange. [Disclaimer: I don’t have any affiliation with these 2 examples, nor am I recommending them. They are just examples.]

Another type is the existing startup or company who wants to apply the token to their already-running model, with the variation being on how to accommodate such tokens. Kik is one example that has been publicized already [I did a fireside chat with Kik’s CEO Ted Livingston at the Token Summit in New York last May]. There are many other examples being planned, as my Inbox is filled with some of them. The scenario goes like this: Company X has an existing product. They want to add a token. I immediately ask them to focus on token functionality and refer them to my post on Tokenomics that outlines the various utility scenarios.

In either cases, the working token is a hypothesis waiting to be proven. Initially, you assume that user behavior will be aided by the token. In practice, only real traction metrics tell you if you were right, wrong or need to iterate.

To further complicate matters, there is a difference between a token that is designed for a decentralized protocol versus a token that is part of an application. The key difference is that developers are the primary targets for a protocol, therefore the token utility is oriented towards them via utility use cases of technical nature, e.g. gas for running smart contracts, voting rights, mining, or security deposits. And with an App token, the usage is more related to actions that end-users will take, e.g. posting content, engaging with a service, creating a new service, or buying/selling something.

Ideally, your product functionality works in lock-step with the token, while the token is transparent and in the background. A good example is Steemit where users focus on their natural engagement with content, and their wallets are automatically credited or debited, depending on the actions being taken.

The novelty with App tokens is what they enable, namely a transactional mini-economy that results in buying/selling or earning/spending activities within itself,- a circular economy of sorts. But a circular economy doesn't mean a circular (read Ponzi) token. Real work must be done, and real value must be created, as a result of user actions. If your user base engagement is fledgeling, a token may not be the panacea, unless it is properly threaded into the product, and user behavior is accompanying the token utility.

The token itself is not your new business model. What the token enables for you and for your users is the key part to focus on.