Product before Platform
How to reach the next step in the crypto innovation cycle
Crypto investors today are constantly pitched by startups building protocols and infrastructure that target developers as the end users. The pitch goes:
We are creating the platform that will enable developers to do XYZ.
With each additional crypto startup making the same promise to investors, the question on my mind is: how are you going to attract these developers to your protocol? Increasingly, I’m seeing that protocols are finding it hard to recruit developers to build on their platform, and the path to real world applications built on their protocols continues to be unclear. Why is there such a disconnect in the market?
eBay before Shopify
From the consumer standpoint, eBay and Shopify enable the same thing — buying products online. As a tool for the seller however, the difference between eBay and Shopify is significant. The first is a marketplace that connects individual sellers and buyers online; it’s a product that enables p2p online commerce. The second is a set of tools that enables sellers to create an online storefront; it’s a platform that allows sellers to build an online commerce business to reach their unique buyers. eBay created the category; Shopify capitalized on it.
My hypothesis is that there could not have been a Shopify without first an eBay. eBay sellers started as hobbyists selling used goods from their homes. Over time, eBay sellers grew into power users who ran their own retail business, selling items both used and new. Buyers were also able to leave sellers a rating, enabling sellers to build their online reputation with each transaction. The adoption of eBay helped solidify the new mental model of trusted online merchants — businesses that can subsist on selling products to online customers alone. This was uniquely a business that couldn’t have existed prior to the advent of the Internet and it would have been impossible to build a platform like Shopify had eBay not established online seller and buyer behaviors first.
AIM before XMPP
AIM (AOL Instant Messenger) was one of the first modern, Internet-wide, GUI-based messaging clients. It gained mass popularity in the late 1990s and at one time had the largest share of the instant messaging market in North America. AIM was powered by AOL’s OSCAR (Open System for CommunicAtion in Realtime) and TOC (Talk to OSCAR) protocols. AOL initially kept these protocols proprietary, but eventually shared them with third-party developers through licensing agreements and an SDK. The traction of the first-party application (AIM) and the availability of the underlying protocols spurred the creation of many third-party chat applications (eg. Adium, Trillium, Pidgin) that continued to use the TOC protocol until it sunset in 2017.
Following the rise of AIM’s popularity, XMPP (EXtensible Messaging and Presence Protocol) was launched in 1999 by Jeremie Miller and the Jabber community. Miller wanted to provide a free and open alternative in response to the proprietary instant messaging services of the day. By the mid 2000’s, the open-source XMPP and its variations have become the standard for many instant messaging applications and still power some of the largest messaging providers (eg. WhatsApp, Nimbuzz, Google Talk, Facebook Chat) to this day.
In this example, the value of messaging protocols did not manifest until user-facing applications such as AIM and ICQ reached scale. My hypothesis is that there couldn’t have been XMPP without AIM. While we may not favourably view AOL’s decision to keep the OSCAR protocol proprietary, we should give AOL credit for pioneering instant messaging as a new model for an internet application. The popularity of both AIM and ICQ parked the interest of third-party developers to build other apps using the OSCAR and TOC protocols. It is also the catalyst that brought us XMPP and the subsequent developer adoption of the open protocol.
New Models for Services and Applications
In both examples above, it took a fully verticalized product to showcase a new model for a service or application. These services and applications were 10x improvements upon their predecessors, or were simply impossible prior to the internet. When we seek “the killer app” in crypto today, we are again looking for new models for services and applications made possible now by new primitives in crypto. The way to discover these new models is not to build the tools that enable them (i.e. Shopify), but rather to focus on building the new model as a product itself (i.e. eBay).
In some ways, the emergence of Ethereum is a stark counter-example to my hypothesis above. Ethereum launched as infrastructure; a platform that enables developers to deploy smart contracts on a permissionless blockchain. The new models that Ethereum enables did not emerge until the first altcoin ICO (Augur, 2015) and the first decentralized autonomous organization (the DAO, 2016). The precedent set by Ethereum has guided many developers and entrepreneurs to do the same — that is, to launch a platform without a product.
This is extremely risky and likely to be a difficult path to success. With the advent of so many platforms and tools on the market, investors are not looking for yet another ambiguous path to real-world application. If you want to succeed today, you will have to show exactly how users will actually use the products built using the infrastructure you deliver.
But what if you are building infrastructure?
The point I’m making is not meant to be disparaging to infrastructure builders. While I remain very much in favour of entrepreneurs looking to make a bigger impact by building a platform or tools that enables developers and other entrepreneurs to build products, this is simply not enough today. Given where we are in the innovation cycle in crypto, platform builders need to dogfood and build a product that can demonstrate the functionality of the infrastructure they are offering — or risk being lumped in with the rest of “boil the ocean” startups that have yet to deliver.
Perhaps it has become unfashionable for infrastructure and protocol builders to create full-stack products amidst the cries for decentralization and open-source software from crypto anarchists. Developers have tried to avoid the stigma of being seen as a potential point of centralization or control. This is wrong. I would wholeheartedly encourage entrepreneurs to explore building full-stack products before launching standalone platforms. While I am encouraged by the wealth of tools and infrastructure in the space, I look forward to seeing teams launch full-fledged products first. In short, show what your platform can do!
Credits go to Dani Grant and Nick Grossman who published their eloquent piece on The Myth of the Infrastructure Phase earlier this week. I had been mulling similar concepts for the past few weeks and it is their clarity of thinking that has encouraged me to write down my own thoughts. Thank you!
