Converge

Knowing when to converge is the trick. Converge too soon and you may end up with the wrong product, wait too long to converge and you run the risk of delivering too late.

In order to deliver the right product at the right time, best practice is to permit divergence for about 1/3 of the overall development time frame. By divergence I mean this is the time where you define the problem you are trying to solve and explore all the possible solutions, with no limitations — the goal is to define the killer product during this time frame.

Some try to avoid convergence in order to keep all their options open, and fear convergence on the wrong thing… these projects also tend to miss their target windows since finite resources are never focused on delivering the highest value functionality. In an attempt to do all they achieve none.

At about 1/3 of the available time you must force focus — in other words… convergence. The best vehicle, especially in start-ups or where processes are being developed, is that first customer. The optimal condition is to identify the customer that represents 80% of the requirements in a given segment. These are usually the tier 1 customers, since they drive market trends as others follow them.

When there is no customer focus, technologists tend to diverge, since they are excited by the infinite possibilities of the technology -- convergence is boring, while divergence is exciting. Good for a University Research department, bad if you are trying to run a business. When requirements are allowed to constantly change, people diverge, projects slip… it usually requires further divergence in order to adjust to new requirements caused by being late and now non-competitive… the diverge/converge cycle can be endless. It’s one of the root causes of products missing market windows.

Converge in 1/3 of the time, get to market, generate revenue and then iterate further technology generations. This is one of the core principles of fast-time-to-market best practices.