/ Token Design

Why Tokens Need Customer Development

Back in May, we originally published this post about why blockchain, more than any other industry, requires customer development. The fundamentally multi-sided relationship at the heart of blockchains unfortunately doesn’t always inspire projects to prioritize a customer centric approach.

In the months since this post first ran, Wayne Chang has gone on to co-found Alpine, a team at ConsenSys dedicated to designing tokens that build the types of productive communities he advocates for in this article.

We’re re-running it this week as a reminder that especially when the often irrational and speculative "market" for tokens is bearish, it's more important than ever to define a practical path to decentralization, and that path always starts with the customer.

Token economies are naturally multi-sided markets that must be coordinated effectively to achieve network goals. Market participants must consistently engage in productive behaviors to keep a thick market, reduce market congestion, and keep participants safe. From the perspective of the participants, if they are to keep using the product, it must simply be worth using. One of the best tools to build a great new product is customer development: the opposite of “build it and they will come.”

While some companies only care about one customer, token economies are multilateral by default. This means that the process of identifying customer problems, validating them, and creating solutions must happen for every type of customer. Moreover, any failure to a secure a single type of customer stands to topple the entire model. In cryptocurrencies, the miners, developers, and users must all participate or the system fails. Presumably, each type of customer significantly contributes to the the virtuous cycle of market improvement, and the removal of any one leg is likely to cause market failure. This failure is markedly expensive due to the increased iteration costs of nascent technologies such as world computers running smart contracts.

Most important, this process cannot happen without talking to the customer. It's crucial, especially at the early stages, for a new company to have access to prospective customers who can be interviewed and validate (or not) that the problems the company thinks they have are the problems they actually have. Early products are subject to significant change, so everything must be worked backwards from the almighty problem—the stable, unchanging job that needs doing. First interviews are fruitful when used to learn about customer problems, and wasteful when used to showcase transitory product concepts.

In the two-sided marketplace Airbnb, the concerns of the hosts must be accounted for differently than those of the guests. The person who wants extra income from renting their spare room has a different set of concerns than the weekend traveler. Each side has different jobs to be done by the platform, so they are presented with different user interfaces, requirements, and even tones of voices used in communications. No party needs to understand the entire system to use it and enjoy value. Furthermore, each side has different channels and value propositions that result in separate marketing and retention strategies. These are well expressed in the Business Model Canvas for companies and the Token Utility Canvas for tokens. At the heart of managing these processes in Airbnb are customer-driven decisions based on data:

Thus, data science is an act of interpretation — we translate the customer’s ‘voice’ into a language more suitable for decision-making.

Today's Waste

They say that four weeks of software development can save you four hours of planning. In the world of tokens, the amount of waste that results from the “build it and they will come” mentality is already staggering and will likely exceed that of the dot-com era. Experienced internet entrepreneurs will immediately recognize this broken pattern. In late 2017, teams are raising multi-million dollar war chests on a WordPress website and LaTeX document (if that!), and “pivot to blockchain” is a strategy rapidly gaining adoption. It’s gotten so out of hand that the SEC steps in regularly to protect people from getting swindled.

While most of the teams behind these projects have good intentions, the overwhelming majority follows no methodology to confirm that their products will satisfy demands of real customers. Many of them don’t so much as contact a single prospective customer before launching and completing their token sales. Interaction with Slack and Telegram communities alone does not count towards conducting customer development. The high bar of obtaining access to high-tech chat platforms about new tokens on the blockchain severely limits demographic reach. Underbanked individuals in emerging markets don’t use Slack. Real estate title clearinghouses have a different concept in mind when they hear “telegram.” The likelihood that ideal customers will join a niche community and begin productive dialog is low. It’s better to seek them out directly.

This situation is severely exacerbated when founders have virtually limitless access to funds. It’s the same reason that large companies fail in new ventures: high revenues or flushness of capital creates insensitivity to new profitability. As Clayton Christensen said, young firms should be “patient for growth, and impatient for profits.” The current sale structures extinguish many of the natural forces that encourage this behavior by giving founders little to no accountability, lack of appropriate incentive structures, and lots of money. While multi-sided markets are indeed harder and more expensive to bootstrap, this is no excuse for flying blind. Customer development and accountability can help with this. Among the core principles of lean (the philosophy from which customer development is derived) is to reduce waste.

Start Small

Even in the glorious and decentralized New Token Economy, it will be imperative to stand something up and provide value to customers as soon as possible. In Crossing the Chasm, Moore talks about finding beachheads: small niches that allow a product to become best-in-class with minimal effort through specialization. After all, Amazon got its start by selling books: non-perishable items that are easy to store in warehouses. Combined with other niche-specific benefits such as ease-of-automation and low margin requirements, this gave Amazon the launching pad it needed to expand into other markets. What does starting small look like for token design?

While creating ideal customer profiles, it may be useful to imagine the smallest set of market participants such that all parties benefit when the market behaves well. It may be necessary to change marketplace mechanisms, at least in the beginning, to accommodate lower transaction volumes and activity. The smaller amount of necessary dependencies, the easier it will be to create an MVP that can be tuned, scaled, and most important, delivering value.

For example, the starting requirement of 1000 organic transactions per second on most new marketplaces would be a non-starter. What if there were only 20 vendors and 100 buyers that expressed interest in using a new token marketplace? How would this cryptosystem look to ensure enough market thickness and safety to satisfy the participants? What if they only sporadically checked their email, and didn't know the first thing about the blockchain or installing browser extensions? These are the design considerations that will make or break cryptosystem implementations, as nearly all of them are reliant on network effects and aggregation theory. Instead of a minimum viable product, it could be useful to frame a minimum viable economy.

Many mathematicians have successfully derived generalized theories from collections of specific cases. It's far easier to see higher-level patterns when equipped with concrete, manipulable examples. It is worthwhile to build and study specific versions of a hypothetically generic marketplace. Again, consider Amazon, which was first a marketplace only for books before evolving into The Everything Store.

Ambitious projects that want to create marketplaces-for-X or governance-for-Y should consider adopting the strategy of beachhead niches as first steps in their grand schemes, and it all begins with the customers and their problems.

Get in the Van

The information necessary for successful market design and growth will not be found solely in the founders' homes or offices. The best answers are often gathered from face-to-face interviews, as in-person meetings still offer the highest-fidelity communications of today, including cues such as facial expressions and body gestures. Several methodologies already exist to script, recruit for, conduct, and record interviews. One such process is described by Cindy Alvarez in Lean Customer Development. The collection of information should be methodical, well-recorded, unbiased as much as possible for analysis.

In the very early stages of a project, founders should expect to spend more time learning about customers than building products. What kind of money is at stake? What job is is the customer trying to get done? What are the major pain points today? How does each customer segment currently interact with the others, and what would be ideal? What is the potential economic value in new kinds of transactions, and how does it compare to existing transactions?

If the construction of a fully-functional dApp and associated smart contracts represents an investment of the team's resources, then customer interviews should be considered necessary due diligence to massively de-risk that investment. It's better to have a weak product in a strong market than vice versa, and talking to customers is one of the best ways to check for a strong market. As the proverb goes, measure twice and cut once.

Meaningful Milestones

Most successful token sales leave project teams with more money than they know what to do with, and some conscientious founders lock it up shortly after realizing this (although much more could be said about fair token distribution models). Reliance on good faith to secure millions of dollars worth of highly liquid assets is romantic, but historically unrealistic. Founders must be held accountable to the vision they set forth to realize, and token holders, investors, and ethical founders all agree. Many have even called for multi-stage fund releases contingent on hitting major project milestones, with partial refunds upon project death, not unlike the multiple rounds of funding found in traditional venture capital.

If a scheme were to exist, then goalposts from customer development could be good candidates for milestones.

Figure 1: Core Process from The Four Steps to the Epiphany by Steve Blank

With a milestone-based fund release, project stakeholders could gradually unlock increasing amounts of capital as progress in is made on building a true marketplace. Concertgoers who purchase very expensive tickets for a concert before it is fully organized would benefit from having a voice in deciding when additional funds should be released to the organizers. If a venue isn't arranged reasonably in advance, the prospective concertgoers may vote to release the remaining funds as partial refunds pro-rata to all pre-purchasers, cancelling the entire event.

Similarly, token purchasers may decide that after reviewing a project's customer interviews (or lack thereof) that it is unlikely that the team will deliver, and that the enterprise risk, which all purchases have some degree of, is unacceptably high; product development should halt. In this case, the token purchasers might collectively agree to release new funds for the team to conduct customer development again, but this time with a different approach incorporating past learnings. Alternatively, the token purchases could come to consensus that the project should simply be cancelled, and that all purchasers are entitled to partial refund of the remaining capital, perhaps 90% of the original amount. This capital could then be used more efficiently by its original owners than through mismanagement by a project with dubious prospects. The choice should belong to the people who paid for the delivery of future goods, services, and rights. This would ensure accountability and solid communication between the project founders and network members (or delegates thereof), so long as the project founders wish to unlock their next milestone funds.

Borrowing Ideas

Good programmers write good code, great programmers steal great code.

We should use any useful models, ideas, and experiences that are out there now. My friend Abe Stanway coined this as intellectual arbitrage. Because token economies may be synonymous with the emerging field of lean market design, it would be prudent to review all relevant prior works, including those of Paul Milgrom and Alvin Roth. For building new successful and scalable organizations, some of the best ideas come from Steve Blank, Eric Ries, and Tim Brown. These are just the big names to start with before digging into their footnotes, seeing where their own ideas come from, and learning about their peers. The blockchain industry can save swaths of precious resources by re-purposing existing processes already made workable by giants before us. There is extraordinary potential to unlock in this new technology, and resources are far better spent hypothesizing, conducting experiments, and breaking new ground instead of reinventing what has already been discovered.

There are already several crypto-ecosystem projects that employ more rigid methodologies from technical and economic perspectives. For example, MakerDAO borrows elements from control theory to model system financial stability. OpenZepplin maintains a widely-used secure smart contracts framework. ConsenSys Diligence has released standard structures for security reviews. IOHK has explored the benefits of theorem provers for smart contracts. The Ethereum Foundation theorems and proofs for its Casper protocol.

Urgency to raise standards should also be applied to customer development, search for product-market fit, and execution of these strategies utilizing methods such as Agile Software Development and Extreme Programming.

Going Forward

The blockchain offers a completely new market creation paradigm with many new winners and losers, but no doubt it will still come down to the people. They will transact, build dApps, write bots, and invent jobs in ways that we can’t even imagine. The blockchain ecosystem is driven primarily by the participants and their needs. As engineers of new markets, it’s our duty to respect them and deliver real value. This can’t happen without their frequent candid input, which we should remember isn’t owed to anyone. Ventures often hinge on the good will of early adopters, and we’re forever in their debt. The only reasonable thing to do is to listen to them carefully and pay it forward.

Special thanks to John Mardlin, Darius Przydzial, William King, and Kevin Owocki for early reviewal and suggestions.

Enjoyed this post? Sign up for our platform to stay updated on our projects and the token economies we are building.

Why Tokens Need Customer Development
Share this

Subscribe to Token Foundry