The term “zerg” serves several purposes in this week’s question. It is: a nod toward the recent release of Blizzard’s Starcraft 2 real-time strategy game; a reference to a rush strategy to win a Starcraft match that has found its way into general usage among online gamers; and a way to blend the terms time-to-market and first-to-market into a single phrase in a serious question for embedded developers. Despite the connotation of a rush strategy, there is more than a ten year gap between the launch of the prior and current release of Starcraft.

Time-to-market is the length of time for the design and development process of transforming a concept from an idea to a deliverable product in the market. It applies to new concepts/products as well as incremental improvements to existing products. Being able to get an idea to market quickly is especially important when products undergo a rapid obsolescence cycle.

First-to-market is a special-case of time-to-market, and it is usually the implied message when marketers tout how using their embedded components will shrink your time-to-market. Adopting a first-to-market strategy relies on the assumption that time-to-market matters most for first-of-a-kind products because it provides a first mover advantage.

A time-to-market emphasis assumes that you can shrink your design cycle so that it is shorter than your competitors that chose a different way to complete their design effort. There are several strategies to shrink the development cycle. The easiest, and most risky, strategy is to skip “low-value” steps in the development process, but this can cause the development team to miss flaws earlier in the design cycle and cause them to become expensive, in terms of both resources and schedule, to fix.

A more robust, but also more costly approach is to have more developers working in parallel so that you do not skip any steps in your design process. This is an approach taken by many teams aiming for a first-to-market product release; however, it has its own unique set of risks. By virtue of trying to be the first to build something, the components you have access to have not yet been characterized to your project’s requirements. In essence, you become an early adopter working with preproduction components. Likewise, your team usually lacks access to mature, domain-targeted tools, documentation, and training because you are completing your first-to-market design while these are being built and certified. This means your team will need to build some of the components, such as drivers, from scratch because the production version of these may not exist until you are ready to ship out your product.

When marketing material touts that it shrinks your time-to-market, it usually is relying on a third approach – using pre-engineered and pre-certified components and tools. In essence, you can safely skip steps because you actually outsourced those steps to someone else. On the other hand, you are not going to be able to find production ready components for novel first-to-market ideas because building these pre-engineered solutions is costly, and the companies that provide them choose to build them because they believe they can recover the development cost across many customers and designs – your competitors.

How important is a first-to-market strategy to your projects? What trade-offs do you consider when trying to shrink your time-to-market? What types of risks are you willing to accept to get the product out the door sooner, and what steps do you take to mitigate the consequences of those accepted risks?

Email me with any questions you would like to suggest for future posts.