While I didn’t talk at all about what the most profitable level of quality is – and to your point, that’s a much bigger topic – I hope that I provided good suggestions on tactically addressing the decisions around a particular (undefined) level of quality.

I hope future readers of this article also read your comments – there is absolutely a strategic decision to be made about a desired level of quality. Once that decision has been made, these tips will help people make penny-wise choices about how to achieve that target level of quality (which hopefully was not made pound-foolishly).

Thanks again for reading and for commenting!

Scott

This depends on the product (or service), the maturity of the industry, customer expectations, brand positioning, legal exposure, and a bunch of other stuff.

- If you are creating a luxury car then quality is more important than price or speed to market.
- If you are creating version 1.0 of some hot new software app, then speed to market may be most important.
- If you are producing a commodity or an older technology product then price may be your primary driver.

So it really depends on the product. And even having a good understanding of the importance of quality to the product it is very hard to turn this into specific decisions regarding increases or decreases in quality spending.

Any product or service has some optimal mix of features, quality, cost and speed to market. Each of these product attributes impacts the competitive advantage and the profit generated. The competitive advantage is based on the level of customer expectation, which increases over time.

So now removing my MBA hat and putting my CQM hat on …there should be some optimal quality level (balanced with speed, cost and feature set) that will produce the greatest customer satisfaction (and revenue).

This level of quality requires some $ amount put toward quality assurance. This $ amount should then be split between automation and manual testing that will generate the greatest level of quality.

Now you can certainly argue that there are processes or automation techniques that reduce overall cost and speed the development cycle …but my response would be that this activity would generate more code, which would in turn require more testing.