5 Tips for Product Management in a Decentralized World
Anyone in product has seen the graphic below. We’re taught that being a great product manager means sitting at the intersection of Technology, Business, and UX. For many of us that’s been a tricky enough skill set to master while the evolution of business models has been largely limited to the online version of the offline world.
Today we are sitting at an inflection moment where all three are changing rapidly based on the evolution of blockchain. Part of this is due to the open source nature of the communities and part due to the economic incentives built deep into each platform. The number of projects are growing exponentially. Some have truly unique technology; some make incremental changes to predecessors, and some have grand ideas but no path to implementation. A quick Google image search for “blockchain ecosystem” will bring back charts and graphs packed full of names you’ve likely never heard of before.
So far this is an engineering led r/evolution. The articles, papers, and lectures overwhelmingly describe engineering problems or properties of a blockchain. There is a huge amount of value in this information, but few sources are truly abstracting the user experience and business model away from this information. This is largely because the technology is developing so quickly that organizations don’t yet see a need to focus on the intersection between business, UX and technology. However, as the various platforms refine their implementations there will be more dapps and more product managers needed to execute.
If you are new to the space, Blockchain at Berkeley has an excellent introduction course on edX, here. This article assumes you are already familiar with many core concepts of decentralized systems and are looking to build a dApp or proof-of-concept.
Overview
The basic concepts of blockchain are fairly simple. You have a database of record which cannot be changed after a transaction is written to it. Rather than existing on a single server owned by a single company or in an AWS instance, companies and people are given incentives through fees or business advantages to participate in managing the blockchain. Each platform has its own flavor of how those participants agree on a transaction, but in each the whole chain must eventually agree on the single source of truth. Some systems also support smart contracts which are executable programs stored and agreed upon by all participants on the blockchain. All of these records are visible to all participants.
Even in that short description there are a few major differences between a traditional ecosystem and the new paradigm.
- Records cannot be changed
- Each participant has a copy
- Financial incentives to participate
- Visibility to all
There are countless variations that look to change some of those fundamentals such as: permissioned blockchains, like Hyperledger Fabric, or privacy focused blockchains, like ZCash or Monero. This article won’t cover all of those variants but will address the concepts necessary to make sound product decisions.
- Finality over Throughput
One of the most common stats provided to show the ability to mainstream blockchain is transactions per second. Visa is 1,667. Paypal is 193, though publicly they’ve reported handling 450. Bitcoin is 3 to 4. Ethereum is 20. This doesn’t translate to is anything about user experience. What’s more important is time to finality. Visa and Paypal will be instant once they’ve processed the payment. Bitcoin has a recommended wait-time of 60 minutes! Even Ethereum has an additional wait time of 6 minutes. In some use cases this might not matter, like an ebay auction, but imagine buying an ebook or your groceries. A user needs to get their product at the same or similar speed as current methods, and as a consumer I don’t measure that in transactions per second. When choosing a protocol, understanding how finality impacts users and perhaps refund obligations is critical.
2. Trade-offs have usability impacts
The news is also filled with stories on different “hacks” to many blockchains. Most of these aren’t hacks in truth, but general vulnerabilities in the different protocols. For instance, Ethereum Classic, ETC, was recently the subject of a 51% attack which lost some $1.1M. As a smart contract platform, it’s reasonable to consider building a dApp on ETC. However, understanding vulnerabilities, it could be seen that this network had a low enough support base to be attacked. Each platform has a different set of risks and tradeoffs. The blockchain trilemma is oft quoted. Picking any one edge of the triangle comes at the expense of the opposite corner.
How might that have affected the users? First, it’s easy to see that they may have lost money if they transacted in ETC. Second, all major exchanges slowed or stopped processing trades. Your users would have been locked into their ETC while the exchange rate to USD dropped. It’s important to understand the risks associated with the model you’ve built on and how extreme circumstances could impact users.
3. Immutability changes process
Immutability has created a need to get the right code out the first time in a way that seems at odds with Agile development methods. If you’re in an Agile system today, you’re looking to launch and iterate. I think Facebook said it best with, “Move Fast and Break Things.” It’s been a great philosophy for the centralized platform. They’ve built, iterated and grown to a $518B market cap. However, if they had to publish all their code out in the open, how many Cambridge Analyticas would there have been? Along with changing the business paradigm, blockchain is changing the development paradigm. As part of this, Formal Verification may not be a standard yet, but expect it to become so in blockchain. This new method of development means that your specifications are tested against all real-world scenarios to ensure that your software runs as planned and that behaviors outside of that plan do not create vulnerabilities. Instead of our general automated testing and code reviews of today, this is assertion based and mathematically proved. If you’re putting smart contracts on any blockchain this method will be critical to the long-term success of the product. Mistakes or vulnerabilities in a smart contract can easily end a potentially great product.
4. Privacy really matters
Most consumers have used their ad-based applications without much thought to privacy. That has changed as we’ve seen more frequent abuses and mishandling of that information, as well as regulatory reactions like GDPR and CCPA. Centralized platforms have always had the luxury of offering privacy as an afterthought. The separation between their information and the rest of the world has meant they can keep their data sharing private from the consumers that are being monetized. For a corporation more data means more money. Users have been told their information is for better personalization and understanding of what they want. Both are true, though it now seems that the corporation has been getting a lot more value than the consumer. In the decentralized world some aspects of transactions will be visible to all, even a history of transactions can give away a lot about the consumer. Bitcoin was long billed as an anonymous currency, but in practice it’s very possible to pinpoint who the users are. Imagine broadcasting your customers’ bank statements for all to read. Not such a big deal if it’s truly anonymous, but most data models are not. Privacy cannot be an afterthought. In this immutable ledger poor design will carry repercussions as long as the blockchain is visible. It is now imperative to design with a deep understanding of how your data model will affect user privacy from day one.
5. New incentive models mean new revenue streams
Permissionless decentralization often hinges on a strong financial incentive model for participants to remain honest. The key concept being incentives make it expensive to be a bad actor in the network. These incentives mean the fees taken from consumers are now divvied up between many parties. Blockchain offers the promise of increased consumer welfare and retention of profits for many participants through the removal of business process friction. This could be either difficulty with paperwork and record keeping, or the removal of intermediaries. The new business model means less gross revenue capture across the value-chain, but could result in better unit economics with increased consumer welfare. It may seem optimistic, but remembering that nearly all projects are now open source, competitors have a much lower hurdle to entering a market. If they can produce the product with a lower price they will. Consumers still have a significant amount of friction exchanging coins and moving platforms, but in the future this will become less costly.
Corporate finance and leadership will need to learn and digest the new cost and revenue models. In most organizations, this is going to take education and proof to align leadership with the pivot. A decade ago subscription-based software seemed like a folly. Adobe was a market leader in this transition and initially suffered a severe drop in stock price. However, once the market understood the business model they’ve seen unprecedented growth. Markets are slow to react because they’re looking at return versus risk. Aligning the business means proving that the decentralized revenue streams are going to be viable for long term growth.
Conclusion
Building products in a decentralized environment is going to take a whole new set of skills and understanding. Product managers have largely been able to let transaction speed, security, bugs, privacy and business model be handled by others. Our concerns have largely been with interfaces, stability, growth, and monetization. The paradigm is shifting and the gap between consumer product manager and technical product manager will close. Understanding how these lower level application choices affect user experience and the business will be a critical component of success.
