When the company reaches the point that they have a product or service that they can demonstrate in their development lab, online, or at a customer’s location, it is time to celebrate. Finally, after many sleepless nights, and probably a few re-starts, the “talking” can be replaced with “showing.” The company’s vision becomes real and tangible. At this point, it may be readily acknowledged that the demo does not have all of the features and functions of the, so called, Minimum Viable Product, but it is still proof-positive that the vision can be fulfilled, or does it?
Although it is important to breakout the champagne and celebrate this major milestone, experience has shown that this point is only a single step on a very long path. In general, when a product can be demonstrated it represents about ten percent of the effort required to have a product that can be used by “mere mortals” in their everyday, actual work environments! Notice that the ten percent refers to the effort. It does not refer to the time or money required to complete and commercially release the product or service. Both the time and money required could be far greater or far less than ten percent. The additional efforts required fall into several categories, some of which are described below.
Good Path Only
The demo, probably run or closely monitored by the company’s developers, shows the product’s core capabilities when everything is done “right.” Procedures and steps are taken in exactly the correct order, at the exact right time, with each interim result occurring exactly as planned. Experience has shown that the “good path” represents about ten percent, best case, twenty percent, of the effort required to add the necessary robustness to the product to accommodate user error or real-world anomalies that will randomly occur.
Accommodating Process Variation
Similar to the “good path” issue described above, processing variations will occur when products are produced or services are offered in any quantity by “normal” production methods. In all likelihood, the demo product was carefully constructed by developers who painstakingly made sure that “All the pieces fit together” exactly as planned. To put this issue in perspective, the Six Sigma Quality approach, solely developed by Motorola was focused on accommodating manufacturing process variation.
Features and Functions
The demo is probably short on features and functions and what is available was probably based on what the company envisioned to be what customers want and need. Even with prospect involvement in the design and specification phase, it is likely that some key, or even show stopper, features were not available. When identified, adding the required features and functions might be easy, or they might require significant modifications. One unrealistic but instructive example could be the design of a new car. If the product specifications were 99% accurate in terms of what customers require, everyone would be overjoyed. A 99% accuracy rate is, of course, totally unrealistic. What if the 99% was applied to the direction in which a user drove the vehicle? The 99% requirement would indicate that the car didn’t need reverse. So, the ability to drive in reverse was never specified. The vehicle may pass the demo phase with flying colors, but adding reverse may be a significant challenge later.
Scalability
Building a single demo or demonstrating the product with one user may result in impressive performance. But what happens when there are hundreds, thousands, or millions of users, or that many products need to be supplied? Can the product, service, or even the business scale to meet future demands?
Demand Creation and Fulfillment
Producing and demonstrating a single unit, perhaps by the CEO, to a single or small group of prospects is dramatically different than making mass markets aware of the product or service and then proposing, accepting, building, shipping, and supporting the product or service. Virtually everyone has experienced or heard tales of woe about companies that were not able to satisfy customer demand. Aside from raising capital, the inability to scale operations, is probably the next biggest reason for startup failures.
Ability to Integrate
The demo product, shown as a standalone offering, may be very impressive. But, how will it work in a customer’s environment? If it must be part of a customer’s end-to-end solution, it must work with other existing components. In most instances, the company has no control over the other customer components and, generally, the burden of integration falls directly on the new component or company. Customers will want seamless integration to minimize their operational pains. The situation is even worse if the new product or service requires changes in the customer’s existing business methods or practices. The “Power of Incumbency” can stop even very attractive new products from ever being accepted. Provisions to integrate the new product into the customer’s existing business are usually not obvious during the initial development or demo phase.
Many other factors can become major inhibitors that impact the effort, cost, or time between the initial demo of a product or service and its high volume, profitable deployment, and customer acceptance. The articles associated with this stage highlight many of those issues. There are fewer articles included in this stage than the previous stages only because it has been assumed that the reader has already considered the issues described during the previous stages encountered on their journey.
