The Standards Innovation Paradox

Hey! Nathan here. Today we have a guest essay from Michael Mignano, the co-founder of Anchor (the largest podcasting platform) and former “Head of Talk Audio” at Spotify. After they acquired Anchor, he went on to lead Spotify’s strategy across podcasts, live, and video.

Michael’s essay is about how open standards like HTTP, RSS, and SMS are awesome in some ways, but often have the unfortunate side effect of freezing innovation in any product category where they take hold. It’s a smart, in-depth articulation of a concern that I share, and have previously written about too.

Of course, if you know anything about the podcasting ecosystem, you might be able to predict that this take stirred up some controversy. At the bottom of this piece, I’ve added links and quick summaries of the more interesting pushback it received, as well as some of my own brief commentary.

But first, the essay that started it all! Please enjoy The Standards Innovation Paradox by Michael Mignano.

Technical standards are awesome. Standards help teams save time and money by giving them a common language for how their products can interact with other products, eliminating the need to build each component within a market or re-define how systems communicate with each other. For example, a team building a new email client doesn’t need to reinvent the format for how email is transmitted between sender and recipient; instead they can just adopt SMTP (Simple Mail Transfer Protocol, the standard that defines how email transmission works) and focus on crafting a great experience for their users. This means the wheel doesn’t get reinvented when someone wants to do something that’s been done before — they can just adopt the standard and accelerate their product development, reaching their audience — and oftentimes, product market fit — much faster than by building completely proprietary products.

Despite the benefit of standards-based products being able to reach an audience faster, the tradeoff is that a lower barrier to entry means more products get created in a category, causing market fragmentation and ultimately, a slow pace of innovation. I call this tradeoff the Standards Innovation Paradox, and I’ll explain it in more detail below.

But first…what exactly is a standard?

Simply put, a standard is a specification for how a technology (hardware or software) should talk to other technologies. Standards are generally developed by the community, but approved and maintained through consensus by committees which are typically open to anyone who wants to contribute. Some classic examples of standards in modern technology are HTTP (for web browsing), SMTP (for email transmission), RSS (for syndication of content, such as in blogs or podcasts), or SMS (for sending and receiving text messages).

Benefits of standardization

To understand the full scope of benefits that standards provide to product teams, it’s helpful to unpack an example, such as RSS (Really Simple Syndication) in podcasts. RSS has long been the backbone of podcasts, providing a powerful distribution mechanism that enables creators to publish their audio from a single endpoint and immediately syndicate their content to any consumption platform that wants to ingest it. RSS has enabled podcasts to flourish on the open internet over the past two decades by defining a language for how a vast network of podcasters and podcast listening apps communicate with each other. To publish audio via RSS, a creator (or podcasting platform, on the creator’s behalf) must publish the podcast in a specific format and include only the parameters defined within the standard, such as a URL pointing to the podcast’s cover art, a list of episodes, and so on.

I spent a lot of time working with RSS, having co-founded Anchor, a podcast creation platform that was acquired by Spotify in 2019. Anchor makes it easy for anyone, anywhere, to publish a podcast from iOS, Android, or their web browser without any prior experience or technical knowledge. One of the things that makes Anchor magical for creators is that it publishes podcasts via RSS to all podcast listening platforms with the tap of a button. This powerful distribution capability is one of the things that enabled Anchor to grow extremely quickly, and eventually become the world’s largest podcasting platform.

While RSS was a huge help for us building Anchor on the creation side of podcasting, RSS has also been instrumental to enabling the consumption side of podcasting. Virtually all of the world’s podcast listening apps that exist in the world of podcasts (such as Apple Podcasts, Spotify, Overcast, and many others) support the ingestion of RSS-powered podcasts. The benefit of doing so is huge: if a podcast listening app adopts this standard, it can automatically surface all of the world’s podcasts to its users, right away. Similar to the email example I used above, this means these listening apps can focus on a great user experience, but not have to worry about building out the content side of their business; the content already exists on the open internet, and can be easily pulled into the listening experience for users to enjoy.

Trade-offs

Since adopting RSS saves podcast listening apps an enormous amount of time and money by not forcing them to reinvent the way content flows through the podcasting ecosystem, it means the barriers to finding an audience for these apps is lower. As a result, many of these apps exist, and thus a tremendous amount of market fragmentation has emerged within the podcasting ecosystem since its inception roughly 20 years ago. If you’ve ever searched the App Store or the Google Play store for a podcast app, you’ve likely come across a tidal wave of search results. In some ways, this fragmentation is great for users, because it means they have a ton of choice and flexibility in what product to use for their podcast listening. But at the same time, this fragmentation is bad for innovation, and makes it nearly impossible to innovate on experiences that are based on RSS, meaning the podcast listening experience has remained stale and largely unchanged for almost the entirety of podcasting. Why? As mentioned above, standards are consensus driven, meaning changes to the underlying language powering these podcast apps don’t come easily. To better understand this dynamic, consider the following analogy to planning a vacation.

The family vacation

Imagine you and your significant other are alone together on a vacation for two weeks in a country you’ve never visited before. Because it’s just the two of you, you can do anything you want on that trip without putting much thought into it. Want to cancel tonight’s dinner reservation and go to a concert instead? You can. Want to skip tomorrow’s museum visit and instead rent a car to go to a different city? You can.

Now, imagine that same trip, but instead of it just being the two of you, your kids, your parents, your in-laws, three friends, your brother, his partner, and their four kids all tag along, too. It’s a completely different trip, right? In this version of the trip, everything has to be planned meticulously. And if you decide you want to make changes to the itinerary, you have to get everyone to agree, which is nearly impossible. What you end up with is a great time spent with family and friends you haven’t seen in a while, but a consensus-driven trip that is far less interesting and unique.

That’s what it’s like building products based on standards that have achieved scale and widespread adoption. Anytime a team wants to do something exciting and new that exceeds the limitations of the standard, they have to get every stakeholder (or at least enough to reach a critical mass of adoption) who has adopted that standard to also adopt the change, otherwise the change is useless. And if you plow ahead with the change anyway and break the standard, then you lose the benefits of the standard. This is hard enough with a bunch of friends and family on a vacation, but just imagine trying to do it with a variety of companies, big and small, all with different and potentially competing interests and priorities. This is the paradox of building with standards.

The Standards Innovation Paradox

The Standards Innovation Paradox is the trade-off teams face when building a new product based on standards; reaching product market fit can happen much faster because finding an audience for the product is easier, but the pace of innovation ultimately flatlines due to market inertia and consensus driven standards development. If and when a team decides to break the standard for the benefit of innovation without gaining buy-in from all other stakeholders, the benefits of the standard are lost. The more stakeholders in an ecosystem, the more people who need to agree (and thus, the harder it is to change).

Now, think about this in comparison to building in closed, proprietary systems which are not based on standards. When building everything from scratch, teams are free to implement and change technology however they see fit without having to worry about getting buy-in from misaligned stakeholders. The downside to this scenario is of course that development will be more expensive, and finding product market fit may be much more challenging. However, once a product finds product market fit, there’s no ceiling of the standard to prevent a team from accelerating their level of innovation.

The Standards Innovation Paradox forces teams to make a choice when building new products that could be accelerated through standards: adopt a standard and get the immediate benefit of distribution/interoperability with a vast ecosystem of existing products (at the expense of long term innovation), or build everything from scratch to enable ultimate flexibility and innovation potential (at the expense of plugging into an existing audience)?

The Paradox in Podcasts

We faced this paradox with RSS when building Anchor in the early days, before we were acquired by Spotify. It was nearly impossible to make innovative changes to the podcasting format, because it was based on a virtually unchangeable RSS standard.

For example, let’s say we wanted to enable a comments section for podcast episodes and have these comments be available within a show’s RSS feed. Unless we were able to get hundreds of podcast listening apps out there to adopt the change, the comments wouldn’t be supported on the listening side of podcasting. Without this support, there would be no incentive for creators to adopt and engage with comments either, and the feature would immediately fail.

As another example, let’s say we wanted to build a richer, more dynamic system for podcast analytics that enabled creators to better understand the performance of their shows, thus increasing their earnings potential through modern forms of internet advertising. Unless we were able to get hundreds of podcast listening apps out there to adopt the proposed change, getting the richer data from the listening apps back to the publishing platform wouldn’t be possible, and the innovation would fail.

This RSS-variety of the paradox has spawned a graveyard of podcast listening apps over the past two decades, many having tried to unsuccessfully build a differentiated podcast app on top of an entire ecosystem that’s based on a fully entrenched standard.

The Paradox in Messaging

Here’s another example that highlights the limitations of building with standards: SMS, the text messaging standard. The invention of the SMS standard took place in the 1980s. After almost a decade, after getting all of the necessary stakeholders on board, it finally launched to the first mobile phone and cellular carrier in 1992, and eventually, reached scale in 1999 (remember: getting standards adopted requires an enormous amount of consensus). Once it did, anyone anywhere in the world could send a text message to any other person with a mobile phone that supported SMS, regardless of which provider or device anyone used.

Then, someone had a brilliant idea to add a new feature to text messaging: pictures! How amazing would it be if you could send pictures via text message on your cell phone? But because SMS was an open standard, pictures couldn’t just be coded up into the latest software update. The standard itself had to change, and every device manufacturer and carrier had to agree to this change and adopt this change, via a new standard: MMS. And so it took almost another decade before MMS finally reached scale.

Now take iMessage, Apple’s proprietary messaging service, which is not at all a standard. iMessage is able to work because a critical mass of people quickly adopted an amazing — albeit proprietary — product: the iPhone. To use iMessage, you must own an Apple device, like an iPhone, which is certainly a drawback. And if you message someone else on an Apple device, you get the benefits of the service itself improving at an extremely rapid pace. By building in their own proprietary ecosystem, Apple has been able to innovate quickly on the messaging experience, and it now looks nothing like SMS ever could.

A brief history of Messaging, with and without standards

Just think about how much iMessage has changed over the years. In the early days, it was indistinguishable from SMS. But now, it’s extremely rich with features like read receipts, photo galleries, face filters and Memojis, an App Store, voice memos, and the list goes on. And the same can be said about Snapchat, Messenger, WhatsApp, and many other proprietary messaging platforms. The only way these platforms were able to reach this level — and pace — of innovation was by building outside of the SMS standard (though, importantly, this came at the expense of being able to interact with other systems, thus limiting the potential audience).

The Paradox in Newsletters

Here’s another more recent example. You’ve likely heard of the amazing newsletter product, Substack. It’s a platform that enables creators to build, host, and scale their own newsletter businesses. The smart thing about Substack is that it uses an open standard — in this case, SMTP, the standard that powers email — to easily distribute newsletters to anyone who has an email inbox.

In contrast to the podcast example above, where any platform that adopted RSS could instantly have the supply side of the chicken and egg problem solved, Substack did the opposite: it solved the demand side by ensuring all of its consumers already had a way to read newsletter content. This is a really smart strategy, and so as a platform, it has taken off quickly, attracting tons of high profile writers and plenty of paying subscribers.

But despite the amazing ability to tap into SMTP for instant distribution to readers, there’s a tradeoff with this approach: email is static, and as long as email clients are powered by the standard of SMTP, it will remain static. This means Substack cannot use email to do anything dynamic, like personalize the discovery experience of the reader in real time in the email client. Or include a dynamic comments section that updates in real time. Or implement any other sort of feature that would enhance the creator or reader experience but would require some sort of dynamic interface inside of an email client. Like in the podcasting example, doing so would require getting most major email clients on the internet to adopt Substack’s innovations.

And so they did something recently that was very smart, but perhaps not surprising given the limitations of standards: they launched an app that enables them to build out their own rich experience for email newsletters. This makes a lot of sense, in my opinion. If Substack is able to scale its app successfully, it can rapidly innovate on the newsletter experience, and not be beholden to the standard of SMTP. But by doing so, they are sacrificing the benefits of the open standard which initially they used to kick start the demand side of their business.

It seems to me that Substack was faced with the Standards Innovation Paradox: keep building on top of SMTP to get the benefits of widespread email adoption? Or build a proprietary solution to accelerate the pace of innovation? With the release of its app, it’s clear to me that Substack has chosen to begin moving away from standards.

Breaking the Curse

While the curse of the Standards Innovation Paradox can doom any fast moving company that wants to reinvent their category, it can be broken. In fact, there is a way for teams to have their cake and eat it, too, whereby they can both get the benefits of the standard, while also innovating past its limitations.

Leverage distribution from proprietary systems

After enough time, all of the products that adopt standards at scale will end up offering roughly the same experience. This is because there is a ceiling of what they can offer because of the entrenched nature of the standard. The more products that adopt the standard, the more market inertia, and the harder it is to change. This means competition is fierce, and it is unlikely that any one product will break out because of some differentiated experience. So how does one of these products break through and find a critical mass of adoption? To find distribution, these products need to piggy-back off of some other product that is not competing in a standards-driven market.

Think about Spotify’s podcast business as an example. A few years ago, the streaming audio giant evolved from being only a music service to being one for other categories of audio, such as podcasts. Given the content and experience differences between music and podcasts, many hoped the company would launch a dedicated podcast listening app to offer users a clean separation between the two content types. However, if they had done so, they’d have to contend with the aforementioned ocean of podcast listening apps which were all offering users roughly the same features that were limited by the standard. It would be just as challenging to breakthrough for a Spotify podcast app as it has been for every other podcast listening app. So instead, Spotify used their existing music user base inside of the existing Spotify app to distribute podcasts to hundreds of millions of users. By doing so, Spotify was able to break the curse of the paradox.

Deliver backwards compatibility

It’s important to remember that customers like using products based on standards because doing so offers them choice and data portability. If a standards-based product happens to break through market fragmentation, it’s important to maintain the benefits users got from the standard in the first place, otherwise you risk alienating your users and losing product market fit. The best way to do this is to ensure backwards compatibility with the standard. Take Apple’s iMessage as an example. If you’ve ever used iMessage, you’ve almost certainly messaged someone on an Android device. Notice how the bubble turns green? That’s iMessage falling back to the standard of SMS to interact with the recipient. This is the best of both worlds. For you and your friends on Apple devices, you can get all the benefits of an innovative, proprietary platform. But these benefits don’t come at the expense of the core messaging functionality which is based on the open standard, because you’re still able to message people on Android devices through SMS.

To Standard or Not to Standard?

Despite the Standards Innovation Paradox, it’s impossible to ignore the massive benefits standardization has had on the success of technology over the past several decades. However, when building a new product that conforms to a standard, it’s always important to consider the trade-offs and weigh the future potential of being hindered by the paradox after a team finds product market fit.

Have you noticed other examples of the Standards Innovation Paradox out in the wild? If so, I’d love to hear about them! Just reach out to me on Twitter or LinkedIn.

—Michael

Michael Mignano is a technology executive and entrepreneur, most recently serving as Head of Talk audio for Spotify, where he was responsible for leading the podcast, live, and video strategies for the world’s leading audio streaming platform. Prior to this, Michael co-founded Anchor in 2015, which was acquired by Spotify in 2019, and is now the world’s largest podcasting platform. Michael is also an active angel investor and advisor to 50+ early stage, technology-enabled companies.

Hey! Nathan again. I hope you enjoyed that as much as I did. Now, as promised, I’ll link to and contextualize some of the more interesting reactions to this piece.

The main critique most people in the industry had, best articulated by James Cridland in a response on Medium, was that actually RSS is extensible, and in fact has been extended several times.

For example Apple has allowed podcasters to add tags indicating if their show in serial (and should be listened to oldest-to-newest) or episodic (and should show most recent episodes first). They added a tag where you can mark an episode as a “trailer.” And these are just recent examples! Back in the day the whole concept of podcast cover art wasn’t even a thing—Apple added that!

Of course, since RSS is an open standard, Apple didn’t have the power to unilaterally make these changes. Instead they said to podcasters, “If you want to add these extra tags in your RSS feeds, here’s what we will do with them.” And because Apple had the biggest podcast app, lots of podcasters started putting the extra tags in their feeds, which meant other apps could use that information in their apps too, and it became a de-facto extension of the standard.

The problem is, of course, that very few podcast apps are big enough to influence podcasters—and, perhaps more importantly, the software they use for hosting—to add new tags. And even when they can, it tends to be either obvious (like cover art) or incremental (like marking an episode as a trailer). It remains very difficult to undertake more fundamental or ambitious changes, and it is pretty much impossible for all but Apple and Spotify to get anyone on board with them. So change is quite slow in practice compared to other product categories.

If you want to go deeper on this argument, Michael Mignano joined James Cridland on his podcast (of course) to discuss the issue in more depth, and the episode should be coming out soon.

Hope you enjoyed this guest post! If so, hit the like button so we know to do more on this topic :)

Thanks!