This is Michail Tsatsanis signing in to continue tdiscussing my Technology Marketing Center case study on How to Balance Standards and Innovation.
The first step in developing a standards strategy is to get clarity within the organization of the exact type of standards support the product or solution needs. Once the details are fleshed out, one usually finds that there are three categories of features in the product:
- A set of features that are necessary but already supported (or very close to being supported) by standards, for example, FCC emissions, environmental standards, standard interfaces (ethernet, USB, etc.)
- A set of features that are not standard, but are "nice to have" and not essential to the product (e.g., proprietary modes, debugging capabilities, etc)
- A set of features that are both non standard and essential to the product
Clearly the last bullet is the tricky part and the heart of the standardization problem. Sometimes key architectural elements of the product cannot be defined until the dust settles from the standards battles. This is more so in silicon companies, where big design and investment decisions have to be made years in advance and where the standardization outcome creates "winner take all" situations. In contrast, sometimes in systems or software companies, adaptations to accommodate changes in the standards may not be as costly or as destructive to the product schedule. It is no surprise then, that the fiercest standards battles are often waged among silicon vendors over key chip architecture defining elements.
Although more difficult in some cases than others, an effort must be made to bring together key technical and marketing people within the organization, to clearly define the extend of the standards battle that has to be taken on. I don't want to go all Sun Tzu on you, but I have to remind everybody that the battle best won, is the one that does not even have to be fought.
In our startup, we had an innovative signal processing technology that provided significant performance improvement of the communication link. One implementation of this technology required the co-operation of the two communication devices (one on each end of the link). Unfortunately, this implementation, although technically preferable, required extensive standardization to have two communication devices from different vendors inter-operate. None of the options at hand seemed attractive: either forgo standards compliance or forgo the performance advantage. Since both of those options were non starters for our company, the technical guys had to go back to the drawing board and see if there is any technical solution that could break the impasse. After extensive research, a solution was found that could be implemented on only one of the two communication devices comprising the link. This allowed this performance-enhanced device to inter-operate with another standard device with no required changes in the standard specification. Moreover, most of the performance improvement of the communication link was maintained (compared with the original implementation).
This innovative technical solution saved the day for our startup, avoided "betting the farm" on some unsure standards outcome and allowed as to avoid an unnecessary confrontation with bigger and better equipped adversaries. This did not quite eliminate all our standards concerns, but left smaller and more manageable battles on the table. Hence, I come back to my point in the beginning of this post. It is important to have clarity in the organization of what the necessary standards battles are, and what can be solved with compromise, and innovative technical and/or marketing approaches.
Check in next week for more discussion,
Until then, be well and do well,
-Michail.
Comments