Optimal Product Process™ Phase Four: Qualify
This post describes the fourth phase in the Optimal Product Process: Qualify. Download the entire Optimal Product Process 2.0 book: CLICK HERE
Many companies either minimize or rush this phase, compressing the amount of time originally allotted or deciding to ship a product that may not have been used in real-world scenarios. This omission can cause a major catastrophe…
With Agile development testing of the product is done during the sprints based on the mutually agreed upon test cases.
With traditional development it is done once the product officially reaches “Beta”. In either case, there is a need for validation and use by real customers. As the end of development nears the team uses customers to determine if the product is ready to release to the public. Though there may have been testing done up to this point in terms of product functionality and reaction from customers, the product has not been considered final enough yet to determine whether it can meet the required level of quality to fulfill the overall product objectives in the eyes of the customer.
Many companies either minimize or rush this phase.
Compressing the amount of time originally allotted or deciding to ship a product that may not have been used in real-world scenarios. This omission can cause a major catastrophe for the product and/or company if the quality level should prove to be sub-par for their brand image. It can also result in spending significantly large amounts of money launching and marketing the product without having verified that the quality and customer satisfaction levels would be adequate to drive sales.
Note: as an example consider the Microsoft Kin phone
After spending hundreds of millions of dollars (perhaps billions including acquisitions) developing it, they spent a huge amount to launch the product and even had a launch party at their campus. Sales were so anemic they cancelled the product in LESS THAN SIX WEEKS. Had they done testing with real users (in addition to their internal quality testing) they could have avoided serious embarrassment.
Another tactic that is used is to push the product out and tell the general public that it is “Beta” quality.
For some products, such as gmail, their feature set was robust enough and the basic functionality worked (and they were completely free), so the company was able to get away with doing this. However, the great idea graveyard is littered with products that were released as Beta and ended up having such significant problems that they never recovered.