Quality is Free

Many years ago I came across a booked titled “Quality is Free”, written by Philip B. Crosby. I must confess that I only skimmed through the book at the time, and haven’t really read it in details. I wish I did though.

Crosby’s concepts are simple, yet powerful. He claimed that quality shouldn’t be an “after thought”, or viewed as the sole responsibility of a “quality control” team that inspects finished products and reports defect. Crosby suggested that quality becomes part of the corporate culture, promoted from the top, and practiced through every action taken by the organization. Crosby called for organizations to adopt a “zero defects” standard, and stated that it is always cheaper to “do things right the first time”. According to him, implementing and practicing quality saves money – hence it comes for free!

When I discussed earlier the process of prioritizing requirements, I mentioned the triangle of “Content, Schedule and Quality”. A veteran program manager once told me that for a given amount of resources, you can only set 2 out of these three parameters when planning a product release. The implications are clear: if you aren’t willing to compromise the release content or its schedule – quality will suffer. And based on Crosby’s teachings, this may be a rather costly outcome.

Poor product quality can bite you in more than one way – and her bites are quite painful. Unfortunately, many of the  defects you leave in the product are likely to be found by customers. Remember Murphy’s law: “If anything can go wrong it will, in the most inopportune time”. Reports on “customer found defects” (CFDs) are never good news for a PM, and they occasionally require emergency responses. Early adopters may be willing to take risks with innovative, yet immature products. However the majority of B2B customers just want products to work, so they get their jobs done. For them, product failures and defects are quite irritating, and often result in business and productivity losses. And if you are in the B2C space, you certainly don’t want to start the rumor mill about how bad your product is.

So, should you make quality your number one priority? For some products, it may very well be the case. Especially if the cost of CFDs can be extremely high. Take medical devices for example: the cost of causing harm to patients are prohibitively high; no wonder companies and regulators spend significant amounts of time, resources and money testing such products before they are publicly released.

But not all products are like that. Many products can sustain a “reasonable” stream of CFDs – provided they aren’t all showstoppers. Striking the right balance between functionality, schedule and quality is where good PMs earn their keep. There aren’t really any clear rules as to how much quality is enough, or when to stop testing your product and start shipping it. What is clear though, is that PMs should keep quality in mind, treat it as an important “feature”, and keep their fingers on the CFDs pulse.

As you create product requirements, don’t forget to address quality related ones. These are sometimes referred to as “non-functional” requirements, since they do not address specific product features/functions. Another nickname I came across was “product ility’s”: i.e. quality, scalability, high-availability, reliability, usability, etc. However you wish to name them, make sure that you spend the time defining and measuring them.

So what about the famous “Move Fast and Break Things” phrase coined by Facebook? Did Facebook manage to shatter the content-schedule-quality triangle? Not really… If you follow the evolution of their motto, you’ll find that it morphed into “Move Fast and Build Things”, then into “Move Fast with Stable Infrastructure” and more recently into simply “Move Fast”. These words actually reflect their product lifecycle, and their maturing approach to product releases.

If you build a product release infrastructure that allows you to quickly test, release and fix new features, you can truly move fast(er) while maintaining quality. Adopting methodologies such as Continuous Integration (CI), Continuous Delivery (CD) and DevOps can improve and accelerate your product release cycle. And the use of Feature Toggles helps control which customers get to experience what features and when.

Whatever approach you take to product development, make sure quality is part of it. That the requirements are clear, resources are invested, and proper procedures are applied. Last but not least – prepare your product to respond (quickly) to any quality problems customers may experience.