The question was raised to us recently, how can you tell if you are building quality products? I think this is an interesting question because you can answer it from two different perspectives – internally or externally. Quality is a fairly nebulous bucket that can include simple bugs, broken functionality, poorly designed flows, and even performance problems. For this discussion we can borrow the ISO 8402-1986 definition of quality as “the totality of features and characteristics of a product or service that bears its ability to satisfy stated or implied needs.” In short, if our service or product is not meeting the needs of our customers then it is falling short with regards to quality.
The external perspective of quality comes from your customers. Signs of poor quality products include customers leaving, customers complaining (on forums or to customer service reps), or even slow adoption rates by new customers. All of these are sure signs that you’re doing something wrong. If you haven’t revamped major functionality or a competitor hasn’t launched some new feature set then functionality is probably not to blame and you should look at the overall quality of your product. The problem with using customers to verify the quality of your product is that once they’ve experienced poor quality, it’s too late. They’ve already had the bad experience and might be considering leaving or not recommending your product to friends.
The internal perspective of quality includes what your teams are doing to ensure they are delivering a high quality product. This does not just include QA and in fact, you cannot test quality into the product. Quality relies much more on good product management and solid engineering than testing. Here are a few processes that tend to improve quality and indicate that you are likely building quality products:
- Cross Functional Design – Whether you are following JAD/ARB processes or DevOps, getting technical operations engineers, quality assurance engineers, and software developers together to design will produce a much higher quality and more scalable product.
- Coding Standards – This includes branching strategies, documentation requirements, formatting (e.g. tabs vs spaces), variable naming conventions, patterns, frameworks, technology stacks, and a defined process for introducing new standards or questioning the use of existing ones.
- Unit Tests – In my opinion, one of the most important measures of quality is the creation of unit tests. Achieving a 75% or greater code coverage in unit tests seems to indicate the delivery of a higher quality product. Creating these tests ahead of time in a Test Driven Development (TDD) methodology is even better.
- Code Reviews – One of AKF’s mantras is “Everything Fails” and this includes people. Buddy checking code is a simple way to help catch these failures. It also serves to help spread knowledge across the team about different ways of coding and solving problems.
We all rely on customers to provide feedback on our product’s quality to some degree but we are better off building and designing quality into our products in the first place. Focus on the internal perspective of quality and then use the external perspective to validate your insights.