To have a large impact, bleeding-edge mass market standards must do two things: diffuse widely and provide new functionality. Curiously, however, while these standards often get built from very advanced technologies, they cannot deploy on a wide scale without building upon other widely deployed routines or less-advanced processes.
Successful deployment of a bleeding-edge mass market standard can bring about enormous change. Consider what happened after the design of USB2 became available. Interested parties monitored the upgrade to USB, understanding that their near rivals did the same. All these parties subsequently made products compatible with USB2 and differentiated along the dimensions in which they had competitive advantage. Consequently, a range of innovative products emerged—storage devices, printers, cameras, keyboards, … you name it.
There is something paradoxical about this pattern: A standard at one layer enables more novelty on another. And a change to the standard—upon which many others build—can enable an even wider range of innovative services.
This issue’s column discusses the determination of new standards in mass markets, an event that shapes such paradoxical outcomes and hence market structure and firm strategy. It is worthwhile to take a moment and examine the patterns.
Fraught with uncertainty
A new standard’s ultimate impact is often uncertain at the time of deployment for numerous reasons. Technical constraints or simple lack of imagination, for example, might prevent participants from designing a perfect standard at the outset.
Consider the deployment of Wi-Fi, initially called 802.11 for the IEEE committee that developed it. The first beta version was released in 1997. This version contained a few problems, revealed by simple field experiments. Efforts to resolve these problems generated two descendants: 802.11a and 802.11b. Version 802.11b was deployed first, in 1999. Although a version of 802.11a soon followed, it never deployed as widely to equipment firms. Most had largely already started to commit to 802.11b.
The popularity of 802.11b surprised many (except the enthusiasts who had designed it). That success generated more industry support, which generated additional calls for improving the design’s speed and reliability. The deployment’s success altered the commitments of many firms. For example, Intel branded a design for laptops, which they called Centrino, which led it to fund conformance testing and a range of upgrade activities.
In summary, the evolution of 802.11 took trial and error. Nothing was inevitable.
Another market risk—balkanized demand—can also slow new standards. Balkanized demand occurs when user preferences differ. Before a standard has been perfected, it can be difficult to determine which design offers the right solution for most users. In the face of disagreement about what is preferable, even the most sagacious observer cannot forecast whose preferences should get the largest weight.
For example, a plethora of alternatives have recently emerged in the smart phone market. Each aims to be the next de facto standard for the niche, offering slightly different capabilities and aimed at slightly different user problems. Yet, it’s unlikely that more than a few of these standards will survive, if that, because most applications developers do not want to support more than one or two platforms.
As an example, Windows CE has been in this market for some time, but has never generated much developer enthusiasm. Apple brought its experience organizing multiple applications on its iPod platform to the iPhone, and got a huge response. Google’s effort with Android represents another method for organizing the platform, and might get somewhere. Blackberry has organized yet another approach. Microsoft claims it will be back soon with better.
How will this turn out? Each offering standardizes different APIs for developers and different formats and applications for users, and nurtures distinct ecosystems. Apple has the lead as of this writing, but I would not count the others out. Once again, it will take trial and error with users to discover which preferences have the most market saliency.
The smart phone example hints at another facet of mass market bleeding-edge standards. When the stakes are high, firms can clash over more than merely changing a technical design. They might clash over where to focus technical progress, as well as how to determine which direction to take. Call these super clashes. Super clashes involve choices between distinct communities of managers, technologists, and/or sponsoring firms.
The history of the Internet provides a great illustration. Development of TCP/IP as a foundation for a national network occurred in the presence of an alternative process and model for the same activity, organized by the International Organization for Standardization (ISO).
Looking more closely, the two standards stressed different designs and different processes for determining new protocols. The ISO process emphasized committee consensus in advance of deployment, with committees representing major stakeholders. DARPA’s descendants established a different process, embedding it within the Internet Engineering Task Force (IETF) in the mid-1980s.
The IETF process stressed bottom-up suggestions and workable solutions, labeled “running code” by its supporters. It also tried to give editorial guidance and support for the entire standardization process, resulting in remarkably clear and comprehensive documentation. The ISO process contained fewer pragmatic benefits than the IETF process, which reduced the number of proposals embedding unrealistic ideals or hair-splitting compromises. Such issues thrived under the ISO process.
Super clashes can also involve competition between coalitions of commercial firms. In fights between coalitions, both might expend considerable resources, and members might not see returns unless their side wins. Such coalitions most recently emerged in the HDDVD versus Blu-Ray (storage format) fight. A similar fight involved 56K Flex versus X2 (56K modems)—one of many examples from the last decade.
Super clashes are especially interesting—and difficult to follow—when all the features of an evolving standard are not yet well defined. This tends to occur when two or more suites of standards battle one another to become a de facto platform.
Crossing between the nonprofit and commercial worlds can exacerbate the confusion. This is occurring now in the fight for high-bandwidth wireless data standards. One coalition works with the IEEE to upgrade Wi-Fi (from 802.11g to 802.11n). Another works through cell phone carriers to upgrade the Global System for Mobile Communications (from 3G to 4G). Yet another works with the IEEE (committee 802.16) to define a new service altogether (WiMax), and the firms in this coalition are different from those in the others.
This sort of jockeying has also started to emerge in infrastructure markets to support cloud computing. IBM, Microsoft, Amazon, Google, Sales-Force.com, and many other firms offer users and developers distinct pathways to migrate their activities to the cloud. Each firm has a suite of technical solutions that needs modification in any given instance. Coalitions have begun to form around different approaches, but the composition of these coalitions change frequently. Keeping track of the developments is almost a full-time job.
The virtues of messiness
Any reasonably thorough case study of a super clash will emphasize the frustration, confusion, and utter plethora of loose ends. Most participants in standards competition come out of the experience with nothing good to say about it.
I say, hurray for the mess.
Normally orderliness is a virtue, but not in standards super clashes. Why? In short, tendencies toward orderly, infrequent, and simplified standards lead an industry down about as unhealthy an innovative path as it can go. Think of Winston Churchill’s famous quote: “It has been said that democracy is the worst form of government except all those other forms that have been tried from time to time.” Similarly, super clashes have only one saving grace: standards designed in the absence of competition are usually much worse.
This observation might seem rather abstract, so consider an illustration from ancient history—the good old days of AT&T’s monopoly over residential customer premise equipment. Until the mid-1970s, most households faced a limited menu of handset designs. These were well engineered, but there were too few choices compared to those available in a competitive market. Think of what you can find in Target or Walmart today. Why was such a limited and orderly choice a good idea?
In other words, messiness arises from the push and pull of competitive action and reaction. Such competition can lead to a proliferation of commercial options as well as to unplanned explorations that defy industry road maps. Super clashes might be irritating for all involved, but the super clashes foster disruptive innovation.
Messiness tends to bring with it one other interesting feature—transparency. Transparent processes are those in which policies let participants know that change is imminent, and – often – what change will arrive. Transparency emerges during clashes for two reasons. First, some standards organizations, such as the IEEE committees, are transparent by design, which encourages others to be transparent as well. Second, competition induces coalitions or sponsoring firms to reveal information about their standardization process and prototypical designs to gain adherents.
In short, transparency leads every facet of the mess to get scrutinized. Greater transparency fosters more news stories and Internet blog critics. It can force firms to take responsibility for their flaws. It also might motivate an additional innovative entrant, which forces incumbents to react.
Altogether, therefore, savvy observers know that new standards and upgrades in mass market bleeding-edge situations enable the potential arrival of change. The opposite also holds. A slow pace for development or a slow arrival of new standards should set off alarms.
Copyright held by IEEE Micro. To see the original, look here.