The author of this article, Michael Mignano, founded Anchor, the world’s largest podcast platform, in 2015 as a co-founder, which was later acquired by Spotify. He is currently responsible for managing Spotify’s podcasting, live broadcast and video strategy related businesses. Michael is also an active angel investor and advisor, and has received his investment and advice on more than 50 early-stage technology companies. Published in the substack of Li Jin, co-founder of Variant Fund, and may have implications for web3 based on open protocols and standards.
Standards, such as RSS for podcasts, enable emerging technologies to easily plug into existing ecosystems for widespread dissemination in the information age. But standardization ultimately comes at a cost, and innovation suffers as a result. That’s why, for example, the podcast format has pretty much stagnated in its 20-year history.
Technical standards are an excellent invention. Standards help R&D teams save time and money by allowing them to use a common language to interact with each other, without having to develop individual components in the same market, and without having to redefine how systems interact. For example, a team developed and created a new mail client, and they didn’t need to reinvent the format to transfer mail between sender and receiver; they just used SMTP (Simple Mail Transfer Protocol, which defines the Standard), focusing on how to create a great application experience for users, without worrying about other things. This means that when someone wants to do something that has been done before, they don’t need to reinvent the wheel – they just need to adopt the standard, accelerate the product development process, and reach their audience – when the product fits the market – Reaching users is much faster than creating a completely proprietary product.
While standards-based products can reach audiences faster, lower barriers to entry mean more products of the same type, leading to market fragmentation and ultimately slow innovation. There are gains and losses, which I call the standard innovation paradox. I will explain in detail below.
But first…what exactly are standards?
Simply put, a standard is a specific specification that determines how a technology (hardware or software) should talk to other technologies. Standards are usually developed by the community, approved and maintained by consensus in committees, which are usually open to everyone and everyone can contribute. HTTP (for web browsing), SMTP (for mail transfer), RSS (for content aggregation, such as blogs or podcasts) or SMS (for sending/receiving text messages) are typical of modern technology standards.
The benefits of standardization
To fully understand the benefits of standardization for the R&D team, we can take an example as an analytical illustration. Take, for example, RSS (Simple Syndication) applied to podcasts. RSS has long been the backbone of podcasting, providing creators with a powerful distribution mechanism that allows creators to publish audio from a single endpoint and instantly sync content to any consuming platform that wants to receive it. Over the past 20 years, RSS has allowed podcasting to flourish on the open-source Internet by defining a common language that can communicate between a vast network of podcasters and podcast-listening apps. To publish audio via RSS, the creator (or the podcasting platform on behalf of the creator) must publish the podcast in a specific format that contains only the parameters defined by this standard, such as URL parameters to the podcast cover, anthology list, and so on.
I have been working on RSS for a long time, co-founding Anchor, a podcast creation platform that was acquired by Spotify in 2019. Anchor makes it easy for anyone, anywhere, to publish podcasts from iOS, Android, or from their browser, with no prior experience or technical knowledge required. One of the most amazing things about Anchor for creators is that it can publish podcasts with one click through the RSS standard, and all podcast listening platforms can receive content. This strong distribution capability is one of the reasons for Anchor’s meteoric growth, ultimately making Anchor the world’s largest podcasting platform.
We created Anchor to help podcast creation, and RSS really plays a big role in it. At the same time, RSS is also a powerful tool for podcast consumption. Almost all existing podcast listening apps in the world (such as Apple’s Podcasts, Spotify, Overcast, etc.) support podcasts based on the RSS standard. This has huge benefits: if a podcast listening app applies this standard, it can automatically expose all podcasts today to its users at once. Similar to the email example I mentioned above, this means that these podcast listening apps can focus on creating a great user experience without worrying about the content; the content already exists on the open source Internet, making it easy for users to listen.
“Loss” under the balance of gain and loss
Since adopting the RSS standard saves a lot of time and money by allowing podcast listening apps to not have to reinvent how content flows within the podcast ecosystem, it means that the barriers to finding listeners for these apps are lower. The result is that there are too many of these apps in the 20-year-old podcasting ecosystem, leading to increased market segmentation. If you’ve ever searched for a podcast app on the App Store or Google Play, you’ll see a ton of results. In a way, this market segmentation is good for users, because it means users have a lot of choice and flexibility to use the product to listen to podcasts. But at the same time, this segmentation is detrimental to innovation. It is almost impossible to innovate the application experience based on the RSS standard, which means that the podcast listening experience is stagnant, and there has been little development and change over the years. Why? As stated earlier, standards are driven by consensus, and the changes that drive the underlying language of these podcast apps will not happen easily. Let’s take the example of planning a vacation below to better understand it all.
Imagine you and your significant other take a two-week vacation to a country you haven’t been to before. Because it’s just the two of you, you can do whatever you want during the journey without worrying too much. Want to cancel today’s dinner reservation to go to a concert? Can. Don’t want to visit the museum tomorrow, want to rent a car and go to another city? Can.
Now, imagine the same journey, but not just the two of you, but your children, your parents, three friends, your brother and sister-in-law, and all four of their children. It’s a whole different trip, indeed. In this version of travel, everything has to be carefully planned. If you decide to change your itinerary, you need to ask everyone to agree, which is almost impossible. This trip is a great time to spend with family and friends you haven’t seen in a long time, but because it’s a consensus-driven trip, it’s not as fun and unique.
Building products on a scale that is widely used is similar to family trips like this. Once a team wants to do something new and interesting that goes beyond the boundaries of the standard, they have to get all the stakeholders applying the standard to make the change together, otherwise unilateral changes are useless. And, in any case, once you break the standard and make changes, you lose many of the benefits of the standard. It’s hard enough to get a group of friends and family members to change their itinerary plans during a trip. Just imagine how difficult it must be to compete with Zhou Xuan, a company with different potential competing interests and different natures, big and small. This is the paradox faced by standard R&D and construction.
Standard Innovation Paradox
The paradox of standard innovation is the result of trade-offs that product teams face when developing and building new products based on standards; products can quickly adapt to the market, and it is relatively easy to find an audience for the product, but innovation ultimately fails due to market inertia and consensus-driven standards-based research and development . If and when a team decides to break the standard for innovation without the support of all other stakeholders, those benefits of the standard are lost. The more stakeholders there are in an ecosystem, the more people need to get consent (and therefore, the harder it is to change).
Now, imagine building a product within a closed proprietary system not based on a single standard. In creating from scratch, teams are free to implement and change the technology as they see fit, without worrying about whether other stakeholders who are not on the same page will buy it. The downside, of course, is that research and development costs are higher and finding product-market fit is more challenging. However, once such a product finds a market fit, there is no standard ceiling to stop the team from accelerating the pace of innovation.
The standards innovation paradox forces teams to make choices when developing and creating new products (applying standards accelerates product development): apply standards to gain immediate distribution/interoperability benefits in an existing ocean of product ecosystems (at the expense of future innovation), or create a product from scratch with ultimate flexibility and innovation potential (at the expense of integrating into an existing audience)?
Paradox in Podcasts
We faced this paradox early on when we created Anchor with the RSS standard, before we were acquired by Spotify. Innovative changes to the podcast format are nearly impossible because the underlying standard is the nearly immutable RSS.
For example, let’s say we want to add a comment section for each episode of a podcast and implement a comment function in the show’s RSS feed. Unless we can apply this change to the hundreds of podcast listening apps on the market, the comment feature will not be supported by podcast listeners. Without this support, there is no incentive for creators to apply and implement this change, and the feature would immediately fail.
As another example, let’s say we wanted to build a richer and more dynamic podcast analytics system that would give creators a better understanding of how their shows are performing, thereby increasing their earning potential through modern forms of internet advertising. Unless we can get hundreds of podcast listening apps on the market to apply the proposed changes, it will be impossible to get more detailed data from the listening apps to feed back to the podcast publishing platform, and innovation will fail.
The RSS paradox is varied. The past 20 years have led to the tragedy of a large number of podcast listening apps, and many attempts to create a different podcast app have failed because the entire ecosystem is based on completely rigid and immutable standards.
The Paradox in Messaging
The SMS text messaging standard is another example that illustrates the limitations of standards-based development. The SMS standard was born in the 1980s. About 10 years later, after all the necessary stakeholders had used the standard, SMS was finally first applied to mobile phones in 1992, and finally reached scale in 1999 (note: it takes a lot of consensus for the standard to be applied). From now on, anyone anywhere in the world can send a text message to another person using an SMS-enabled mobile phone, no matter which mobile phone or provider.
Then, someone had a brilliant idea to add a new feature to SMS: pictures! How cool would it be if you could send pictures via text from your phone? But because SMS is an open-source standard, the picture functionality cannot simply be coded into the latest software update. The standard itself has to change, and all handset manufacturers and operators must agree to and apply the change. Of course, a new standard is needed: MMS. So, it took almost another decade for MMS to finally take shape.
Now let’s look at iMessage, Apple’s proprietary messaging service, which isn’t a standard at all. iMessage succeeded because of the rapid adoption by a large group of people of a proprietary but amazing product: the iPhone. To use iMessage, you must first own an Apple device, such as an iPhone, which is certainly a step backward. If you use an Apple device to send a message to people, you get a service that is constantly being updated quickly. Apple develops in its own proprietary ecosystem to rapidly innovate the messaging experience, and now its text messaging service is very different from the SMS era.
Think back to how iMessage has changed over the years. Early iMessage and SMS were not much different. But now, it’s packed with features like read receipts, photo galleries, face filters and Memojis, the App Store, voice memos, and the list goes on. The same goes for Snapchat, Messenger, WhatsApp, and many other proprietary messaging platforms. The only way these platforms can achieve such a high level of innovation and such a rapid rate of innovation is to develop and create outside the SMS standard (although, it cannot be ignored that the interaction with other systems is sacrificed, thus limiting the potential audience).
Paradox in Newsletters
Here’s a fresher example. You’ve probably heard of Substack, a great Newslettes product. This is a platform that allows creators to create, store and expand their Newslettes business. The great thing about Stubstack is that it uses an open source standard — SMTP that drives mail delivery — to easily distribute Newslettes to all email users.
Contrary to the podcast example above, where any platform that applies RSS can immediately solve the chicken-and-egg supply-side problem, Substack does the opposite: it does so by ensuring that all of its consumers can read the content of the emails Demand side issues. It’s a brilliant strategy, and as a platform it’s growing rapidly, attracting countless well-known authors and paying subscribers.
Although applying SMTP can instantly distribute content to readers, this approach has its own drawbacks: mail is static, and will remain static as long as the mail client is driven by the SMTP standard. This means Substack can’t do anything dynamic with email, such as personalizing the reader’s discovery experience in real-time in the email client. Alternatively, include a dynamic comment section that updates in real time. Or implement any other feature that enhances the author or reader experience, but that requires some kind of dynamic interface in the mail client. Like the podcast example above, doing this requires most of the major mail clients on the Internet to apply Substack’s innovations.
So recently they made a very smart move, although perhaps not surprising given the limitations of the standard: They launched an app that would allow them to expand on top of their rich email newsletter experience. In my opinion, it makes sense to do so. If Substack can successfully scale its app, it can rapidly innovate the Newslettes experience, no longer beholden to the SMTP standard. But doing so would sacrifice the benefits of open-source standards that enabled users to demand their business in the first place.
It seems to me that Substack is stuck in the standards innovation paradox: continue to work on SMTP to benefit from the widespread adoption of email? Or develop proprietary solutions to accelerate innovation? With the release of its app, I think it’s clear that Substack’s choice is starting to deviate from the norm.
break the spell
The curse of the standard innovation paradox can befall any fast-growing company that wants to innovate, but it can be broken. In fact, there is a way for the R&D team to have both the benefits of the standard and the innovation that goes beyond the standard.
Distribution mechanism utilizing proprietary systems
After a certain period of time, all products that apply scaling standards will ultimately provide roughly the same experience. This is because what they can offer is ceilings, which come from the standard unalterable rigid nature. The more standards there are for products, the greater the market inertia and the more difficult it will be to change. This will bring fierce competition, and it is impossible for any product to break out due to different experiences. So, how can these products break through the bottleneck and find the large-scale applications that are critical to them? They need to rely on other non-standards to drive products within the market.
Or take Spotify’s podcasting business as an example. A few years ago, the audio-streaming giant went from just offering music to offering all kinds of audio, including podcasts. Given that the content and experience of music and podcasts are different, many people hope that the company can release an app dedicated to listening to podcasts, providing users with a completely different app experience than listening to music. However, if they do, they will have to compete with the sea of podcast-listening apps that are limited by standards and provide users with largely the same functionality. Breaking the bottleneck is difficult for the Spotify podcast app, as it is for any other podcast listening app. So Spotify leverages its existing base of music users on its existing app to distribute podcasts to hundreds of millions of users. Doing so frees Spotify from the paradox curse.
Implement backward compatibility
Remember, users prefer standards-based products because their choices and data are portable. If a standards-based product can break through the bottleneck of market segmentation and stand out, it is important to retain the user’s initial benefits of the standard, otherwise, it will risk losing users and product-market fit. The best way is to ensure backward compatibility with the standard. Take Apple’s iMessage, for example. If you’ve ever used iMessage, you’ve basically used an Android device to send text messages. Notice how iMessage does it? iMessage reuses the SMS standard to interact with the SMS recipient. This is the best ending for both users. For you and your friends using Apple devices, you can enjoy all the benefits of an innovative proprietary platform. But these benefits don’t have to sacrifice the core functionality of SMS based on open source standards, because you can still send text messages to Android device users via SMS.
Should we use the standard?
Despite the standards innovation paradox, we cannot ignore the enormous benefits that standardization has brought to technological success over the past few decades. However, when creating a new product based on standards R&D, it is always important to weigh the pros and cons, considering whether future development will be hindered by the standards innovation paradox after the team finds a product-market fit.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/anchor-co-founder-what-the-paradox-of-standards-innovation-means-for-web3/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.