So?

Most product developers have a product plan, but in many cases, the plan is specious. Some of the commonly missing elements are:

• Lack of detailed product requirements and validation methodologies.
• Little mention of product life costs including what happens at the End-Of-Life of the product.
• Lack of analysis of costs associated with installation, service and warranty.
• Lack of a plan for Cost Reduction milestones.
• Lack of quality definition for the product design and production processes.
• Little thought given to production/manufacturing validation.
• No process improvement plan.

Almost every developer develops the product to some specification, however in many cases the specification is limited to a list of components and general functional requirements. Therefore one can't test to such a specification to prove that the product works 'as expected', since 'as expected' - when put to the test - is usually far more precise and complicated than the specification. This is a major reason why some developers 'back into' a product specification after they begin testing the prototype product.

Every product developer tests the product. However, the testing is usually not gauged to the specification - it is mostly very basic: if it boots-up, or turns on and seems to

perform the generally described functions then it's tested. This demonstrates nothing about Quality or Reliability or usefulness. This is just 'engineers testing their own stuff', which generally validates the technology, but not the product.

In many cases the results of the testing is hardy ever formally measured, and recorded. The 'eye and mind of the engineer' is where the test results live.

Even fewer product developers gauge the test results to 'lines in the sand' (defined in a well-conceived specification) in order to validate that the product IS what was defined. Again, the 'eye and mind of the engineer' is where this informally takes place.

Finally, very few product developers try to improve upon a product by matching the test results to specifications to see where 'differences' can be made smaller (experienced businesses will do this). This is called product improvement, which is quite often viewed as other words for 'product changes' not as cost, performance, reliability or quality improvements. Adding features, more often than not, decreases reliability and quality and increases costs.

A solid product development program should have strong emphasis in all of the phases of the cycle. Of course, one needs to exhibit rational judgment and not go overboard for the sake elegance or boastful minutia; this is where experience is a very valuable supplement to product development.