Blockchain apps have a 0% success rate. How can we build better products?
We have been building in crypto for the past year and find some of the accepted practices are counter to the successful practices of building a startup. Sharing some of our learnings for DIRT. Originally published on Coindesk: https://www.coindesk.com/0-success-why-blockchain-apps-just-arent-taking-off
— —
In 2018, the blockchain story and the promise of a decentralized future fell apart. The most widely used dApps have a few thousand daily users and a study of 43 blockchain applications found a 0% success rate. With so much funding and talent in the space, why do we have so little success to show?
There is a broken process for building and launching blockchains applications today. Rather than working within an low-risk environment that supports iterations and learning, blockchain companies follow a playbook that stacks the odds against their success. By pre-selling a product before it is built, projects set themselves up to failure with unrealistically high user expectations on their v1.
Moving forward, this approach to building creates three problems: 1/ to appease an early adopter crowd of crypto-enthusiasts, projects preach to the choir and build with the assumption that decentralization is the answer (rather than a means to an end), 2/ with vocal supporters, projects make suboptimal decisions by committee, and 3/ with a market emphasis on ideas and theory, projects follow the whitepaper as if it is the final product plan rather than the starting point.
With so little to show from 2018, we have to change how products are incubated and tested. For a better 2019, we can take lessons from how successful technology companies are built and apply them to the blockchain space.
1/ Build a product not a protocol — Many blockchain projects that pitched a future of decentralization just a year ago are realizing you cannot find mass market success by preaching a philosophy alone. Open source projects as an alternative to closed, centralized networks are nothing new. It has been tried before with Diaspora vs Facebook, Mastodon vs Twitter, and DuckDuckGo vs Google. The takeaway from these projects is the same: openness and decentralization only matter to developers.
Blockchain applications need to go back to basics and ask the question of who is the user and what is their problem. Bitcoin created a way for darknet users to exchange funds online. Ethereum allows developers to run a script on a decentralized computer. IPFS is a way to store censorship data. No crypto-economic incentive is strong enough to overcome a missing use-case.
2/ Listen to your users, but don’t let them tell you what to do. — Facebook released the newsfeed to overwhelming negative public response. Apple product launches are all been met with the same media reaction: too expensive to succeed. Netflix moved to streaming and lost over a million customers in the transition. Some of the most important product decisions that seem obvious in hindsight were controversial at the time. For crypto projects, a vocal community can be the biggest asset or biggest liability. Listen to your users but filter the feedback. Don’t give your users what they ask for; give them what they want.
3/ Focus on iteration over the idea — There is an mistaken perception in crypto that the idea is the most important part of success. So we see teams focusing on whitepapers and delaying the launch for years. But what we have learned from how successful technology startups are built is that a good idea is only the beginning.
If the goal is to solve the customer problem of getting from point A to point B, the MVP is a skateboard. When startups promise the car in the first release, they can’t meet customer expectations.
Two markets with runaway success in 2018 were exchanges (ex: Binance) and mining hardware (Bitmain). Binance went from 0 to over $1billion in revenue in under a year (https://news.bitcoin.com/crypto-exchange-binance-expects-up-to-1-billion-profit-in-2018/). ASIC mining efficiency for bitcoin has increased by over 10x. In the same year, no decentralized application has seen mainstream success. The product development cycle for building smart contracts and decentralized networks is excessively slow because the high risks of mistakes are too high (ex: Parity wallet hacks). Rather than launching and learning from user feedback, teams iterate in isolation and delay the valuable learnings that come from real users. Moving forward, projects should launch earlier and smaller. Test the product with a small group of users, get feedback, and iterate.
