First step: create an industry alliance
Before you can develop an industry standard, you need to bring together the companies will jointly develop the standard. This is an industry alliance.
Products with standard interfaces are easier to sell, easier to design, and cheaper to manufacture. The USB interface, for example, provides standardized power and communication. Wi-Fi provides Internet access.
Product developers can design their own proprietary interface when a suitable standard interface does not exist. Such a proprietary interface can be designed to deliver the right functionality and performance but in many circumstances a proprietary interface will not make economic or business sense.
What are your options when you have decided that a new standard interface is needed to make your product successful? Either you wait until a standard is created by your competitors, or you take the initiative to create an industry alliance for developing that standard interface.
Taking the initiative can be profitable. You can make sure the interface supports the applications that are important for you, you can be the first to market, and by contributing technology and intellectual property, you potentially gain a long term competitive advantage.
Getting started
It is not a good idea to invite your competitors, suppliers and customers to a meeting and start brainstorming a new interface standard. Not only will that cause legal complications, it will also be extraordinarily difficult to agree anything. Expect a long frustrating process with mediocre results.
In my experience it helps to spend time to create the group and establish goals and governance rules before you start discussing the specification and start developing the industry standard.
Creating the “Vision”
Drafting a couple of slides is a good way to start. Keep it simple with bullet points and avoid complicated sentences in this stage. The slides should cover the main points: goals, governance rules, IPR rules, rules for sharing costs, and also the high-level technical choices that are proposed for the interface, or technical options that will be investigated when the choice is not obvious yet.
Controversial topics should not be avoided or hidden in ambiguously worded statements. A hidden controversy will resurface in a later stage and then it will be much more difficult and painful to deal with. Either state the choice that will be made, or state how the controversy will be dealt with later.
Negotiating the formal legal contract between the participants will be much faster when the main ingredients have been agreed already at the level of PowerPoint bullets. When controversial topics have not been addressed or were hidden, discussions about the wording in the contract become a proxy fight about the underlying controversy, and contract negotiations become slow or risk breaking down.
There is a downside to specifying choices for many potentially controversial topics in the first draft of the Vision document. The company that drafted the Vision will need to convince other companies to join the group and that will be difficult when the other companies do not agree with some of the choices. And competitors may be reluctant to agree with the proposed choices when they suspect that the company drafting the vision has already developed the technology and will gain a competitive advantage.
Engaging with potential participants and improve the Vision
An interface standard needs broad industry support. It is time to talk with potential participants and get their feedback when the first draft of the Vision is ready. Use the feedback to improve the document and to re-consider the initial choices.
Getting the first two or three company to support the Vision is hard. It will become easier once the initiative is supported by multiple companies. It helps to state clearly that the first draft is a strawman draft, meant as example of what could be decided and not as a take-it-or-leave-it proposition. It is necessary to be responsive to comments and accommodate the wishes of other companies, even if their requests for modification are not obvious improvements.
There are three pitfalls in this stage:
- To be too accommodating.
- To stick too strongly to the text of the first draft.
- To engage only with suppliers and customers and not with competitors.
If you really want everyone in the industry to support the Vision, the resulting document will not contain any controversial choice. At a later stage, however, choices for controversial issues will have to be made anyway. That will cause long debates and slow down the development of the interface specification. If you want to develop the interface specification quickly, it may be necessary to accept that not all companies will join the group.
It could be that the concepts in the draft Vision are carefully considered to create the best possible industry standard and that the other participants lack the knowledge and experience to make improvements. Even if true, it will be hard to get other companies to invest in the development of an interface standard when they feel that they will not able to influence the standard. At best they will be passive participants, waiting for the dominant company to do the work. Worst case they will try to create a competing interface standard.
It is easy to start talking about the Vision with suppliers and customers. Engaging with a competitor is much less comfortable because disclosing the Vision with all its details about requirements and solutions to a competitor can be risky. In most cases, however, it is essential that at least some competitors support the interface standard in their products. That means it is necessary to engage with them as early as possible. It will be easier for competitors to support the initiative when they are treated as equal partners. Excluding competitors in the early stage will increase the risk that they establish a competing standards initiative.
The right balance depends on the circumstances. A company with dominating market share, or an extraordinarily strong IPR position, can afford to be less accommodating and provide stronger leadership.
Main ingredients of the vision document
- High-level requirements for the interface specification that will be developed. What type of products will implement the specification? What problem wil be solved?
- The terms and conditions for intellectual property licensing. Standards development organizations (SDOs) create optimal conditions for the adoption of their standard. A RAND license policy is used by many SDOs. RAND licensing invites contributions from owners of relevant technology but prevents royalties from getting so high that it blocks the adoption of the standard.
- Rules for sharing costs, for example by collecting membership fees.
Drafting a contract between the participants and establishing the group
When enough companies have expressed their support for the Vision it is time to establish the group and start developing the interface specification. To establish the group it is necessary for the participants to sign a contract. That can be a simple multi-party agreement, something like a multi-party NDA with additional clauses. It is also possible to establish a legal entity with bylaws and have the participants sign a membership agreement.
In any case, the most important clauses in the multi-party agreement should not come as a surprise to the participants because they were already covered, and agreed, in the Vision document.
All topics covered in the Vision should find their way into the agreement, or into an annex to the agreement that describes the technical requirements and boundary conditions for developing the interface specification.
It is easy to draft agreements when the main ingredients have already been agreed in bullet form. When, during review of the draft agreement, participants do not agree about a particular clause, it is essential to find out if the disagreement has to do with drafting preferences and wording, or that the disagreement is caused by differences in business requirements. If the disagreement is about a fundamental difference in business requirements, it can be helpful to take a step back and re-discuss and refine the Vision. Trying to resolve such differences by clever ambiguous formulations in the contract can cause problems later.
Get professional support
Organizations like IEEE-ISTO provide support for industry alliances. Suppprt for organizing meetings, collecting membership fees, making minutes, etc.
Second step: develop the interface specification
When you develop an industry standard, the deliverables are: (a) an interface specification, (b) a test specification, and (c) a certification program to verify that products are compliant with the specification.
What is an interface specification?
An interface specification makes it possible to independently develop products on both sides of the interface. Bluetooth, for example, is an interface between mobile phones and peripherals such as audio headsets. The manufacturer of a phone can add Bluetooth without the testing against all Bluetooth headsets. And the manufacturer of a headset can develop the headset without testing against all phones.
A good interface specification maximizes design freedom on both sides of the interface. The interface specification should not be so specific that it allows only a single implementation. That makes a good interface specification much more abstract and complicated than the typical product specification. It is easy to underestimate how hard it is to make a good interface specification.
A good interface specification must include a test specification. Ideally, passing these test should be sufficient to predict that the product will work correctly with all products on the other side of the interface. In practice it is not easy to make such a 100% predictive test specification.
Some interface standards require testing only against so-called “golden” test samples. That is an easy way to avoid having to develop a test specification, but it severely limits the design freedom of product implementations because products that behave slightly different from the golden samples have a high probability of encountering compatibility issues in the market.
The specification development process
Drafting the specification will be relatively quick when the requirements and main technical choices have been agreed in the Vision. But even then, writing an unambiguous interface specification takes time and effort by all participants.
It is particularly important to create multiple independently developed prototypes. Independent implementations are needed because ambiguities and omissions in the specifications will make these prototypes incompatible. Verifying that independent implementations are indeed compatible is the only way to gain confidence that the specification is complete and unambiguous.
Releasing an interface specification too early will cause incompatibilities between products in the market. That is disappointing and expensive.
A cycle of spec improvement and prototype development typically takes half a year. That makes it hard to predict when the specification will be ready. And it shows that it is worthwhile to take review and editing of the specification seriously. Good spec writers can reduce the number of prototyping cycles.
Backtrack when you get stuck!
What to do when the prototypes disappoint? It may be that performance targets are not met, products get too hot, or are unexpectedly expensive to manufacture.
One solution is to revisit the main technical principles and try another approach. That will cause significant delays.
Another option is to revisit the requirements. Requirements formulated at the beginning of the standard development process tend to be a “wish list” and may turn out to be conflicting. In wireless power transfer, for example, “high efficiency” and a “large transfer distance” are mutually exclusive because efficiency drops with increasing transfer distance. When the trade-offs between conflicting requirements is understood by all participants it can be useful to revisit the requirements and come to more realistic targets for the interface.
New technical insights can also make it necessary to revisit the main technical principles. If a new method is discovered that increases the performance of an interface dramatically, it can be necessary to make drastic changes, or risk that the interface specification becomes irrelevant.
Test Specification and Test Tools
Launching a product is a gamble when it is impossible to verify that the product is compliant with the specification. Will the product work with products on the other side the interface? Probably not when products have not been be tested. An interface specification is therefore useless without a test specification.
Test specifications are preferably developed concurrently with the interface specification. Developing the test specification afterwards will cause delays in product introduction and squanders the opportunity to get feedback on the testability of an interface specification.
And the test specification is useless without test tools. It is usually possible to execute any tests with general purpose equipment such as an oscilloscope, but that is extraordinarily time consuming. In practice, certification by independent test labs is not possible without dedicated professional tools that automate interface testing.
Development of tools is often a bottleneck. It can easily take as long as the development of the specification. It pays to involve manufacturers of test equipment in an early stage.
Managing product certification
It is possible to have product developers self-certify that their products passed all tests defined in the test specification.
The alternative is to require that an independent test lab verifies compliance with the test specification.
Both methods work provided that the test specification covers all potential interoperability failures, and that products that pass are guaranteed to be interoperable in the field.
Unfortunately, it can be challenging to create a test specification with 100% coverage. The first version of a test specification in particular is likely to be incomplete, and relying on the test specification alone will cause product failures in the market.
Interoperability testing as fail safe
It is possible to lower the risk of interoperability failures by collecting samples of all previously certified products in one location and then test each new product against this collection.
When a product passes all compliance tests but fails the interoperability test, that exposes an omission in the test specification. A root cause analysis of this interoperability failure can be used to add an additional test to the test specification that will prevent similar interoperability failures in the future. This way the test specification is debugged without risking the sale of products that do not work correctly.
Further reading
The article “Managing Competition Between Standards” discusses how the manage the development of competing standards within a single organization.
The article “Network effect: difficult market introduction” explains how creating an industry alliance can help with market introduction.
The article “Guide to facilitate multi-party negotiations between companies” explains the negotiation process for creating an industry alliance in more detail.
The article “Why Startups Fail” will help you understand that it risky for startups to participate in standards development, mainly because it takes too long for startups with high cost of capital.
The article “Choosing name and logo for a group of cooperating companies” shows how to create an effective logo without spending a fortune.
