Just a few rough notes on this talk by Chris Dixon (who, if you don’t know him, is one of the best analytical writers on all things technology/internet market/business/strategy/history and a16z Crypto general partner).
Dixon has a long history in the tech/internet market and therefore brings this perspective into the crypto space – as you can, for instance, read here and here. Unlike many others who either have primarily a financial approach to crypto or a crypto-native (and hence rather specific [world]) view, Dixon has a “real-world internet and tech perspective”. Thus, I’m always looking forward to his publications.
The video above is the opener of a16z’s (longside Techcrunch) pretty cool Crypto Startup School. While the talk is a fairly general introduction, I still highly recommend it because Dixon talks about the subject in a way that normal (internet/tech) people understand. Therefore, it is not only useful to people who are new to the space but also a good reference point for crypto folks looking to reach a non-crypto audience.
Here are my notes:
Blockchain as the “reversal of a paradigm”
An interesting line of thought: with blockchain, hardware is now governed by software instead of software governed by hardware as is the case traditionally. Noted 😉
“Computer that can make commitments”
I like Dixon’s phrasing here a lot. It’s much more approachable than the related but often misunderstood/incorrectly applied concept of “trustlessness”¹. “Commitment” is a good term to explain what’s achievable with blockchain/DLT/crypto networks and I think it creates a much clearer picture – e.g. in the minds of product designers – of what’s actually doable thanks to the technology.
It’s much easier to answer a question like “What’s the last commitment you made and how could we digitize it” than “what’s the last trustless environment you were in”?
Dixon touched upon this issue in a brief blog post as well:
What else can you do with computers that make commitments? One fertile area being explored is re-architecting popular internet services like social networks and marketplaces so that they make strong, positive commitments to their communities. For example, users can get commitments baked into the code that their data will be kept private and that they won’t get de-platformed without due process. Third-party developers can safely invest in their businesses knowing that the rules are baked into the network and can’t change, protecting them from platform risk.
Lego Bricks/ New Computing Primitives
Dixon develops a more nuanced perspective on the field. He talks about “new computing primitives” that blockchains enabled, namely:
- digital money
- digital goods
- smart contracts
- decentralized organizations
- tbc
It’s useful to create these more nuanced models for reasons that I explained in Untangling the Different Crypto Innovation Streams:
I think it is about time to untangle the different streams of innovations which have their origin in Bitcoin and which are keeping the blockchain/crypto/web3/DLT ecosystem busy these days. Why untangle? Over time, the community grew and more and more people from all kinds of backgrounds became attracted to the crypto world. As a result, the ideas, philosophies, and goals floating around in the community expanded as well. Yet at the same time we still simply talk about blockchain or crypto when, in fact, it is no longer a homogenous field but a variety of innovative concepts.
By untangling these different streams of innovation, we can apply a higher degree of precision to our design efforts and analysis (e.g. of a new project), we make the different domains and respective ideas more accessible (e.g. to people who just joined the party), and we ourselves can develop a more nuanced understanding of what’s going on.
What I particularly like about Dixon’s nomenclature is that it is very usage-focused. In that sense I like it even more than my innovation streams.
Design, Trust & A-ha Moments
There’s a really good question in the Q&A section:
“The thing that blockchains are really good for is trust. End-users choose what to trust in a kind of squishy way, they don’t pragmatically choose what to trust. What do you think product developers need to do to convey that to their end-users?”
To Dixon, the answer are a-ha moments, for instance a situation when users, for the first time, have a strong feeling of ownership and control. He also hints at a potential development I also believe in: while the majority of today’s users may not actively look for the innate properties of blockchain, upcoming generations who have a stronger intuition for the digital world and problems that come from a digital lifestyle like platform risk, data privacy, ownership might well do. That is certainly one element.
However, I think that from a product design perspective, maybe conveying trust shouldn’t be the starting point. When looking for a market, yes, you can look for environments where networks would be useful but actors don’t trust each other (I wrote about this in here).
But the first-level application utility – i.e. what the user is actively looking for – usually is not trust. She wants a concrete problem solved or task performed. It’s just as true for blockchain-based applications as for others. The type of problems you solve using blockchain might only be solvable thanks to the trustlessness property yet that’s not necessarily obvious to the users and doesn’t have to be, at least not from day 1.
So I’d answer: don’t look to convey trust but look to solve a problem extremely well, leveraging the technology’s capabilities, and only then make sure that your users understand why your approach works so well and will continue to do so.
The Network Startup Decentralization Playbook
Dixon hints at an emerging playbook. In his mind, it starts with a traditional company structure that dissolves into a more decentralized, looser structure. I’d love to hear more about his/a16z’s thinking on that. As a VC of course they like company structures. I personally believe that decentralized networks ideally would require their own type of yet-to-be-developed legal entity, maybe something inspired by cooperatives.
¹ Trustlessness means that blockchains can be used in environments where the individual actors – the participants in a blockchain network – don’t need to trust each other because the trust is “built-in” on the system/network level, i.e. the code behaves in a verifiable and transparent way; of course, all this requires code-fluent users. Hence, the average user still needs to trust although not in the integrity of a single entity but of the (eco)system at large.
Subscribe to my Newsletter
The Things is my newsletter at the intersection of tech, crypto, entrepreneurship, and the network economy.
Rough Notes 