Decoding the Dance: Customer Value Meets Quality
I suggest we begin exploring different ways to think about quality. Let's take a step back and critique our existing assumptions on quality. If we question what we accept as truth in testing, we may begin to identify new ways of achieving quality products that our customers really value.
The voice of the customer
Even before I started in this industry, there's been an interplay between customer value and quality—Juran's 1962 2nd edition of the Handbook of Quality talks about the interplay between the two.
In software engineering, quality typically means 'product quality'. When quality professionals describe their role, it's often to be a 'voice of the customer' providing that perspective to the rest of the team.
Jerry Weinberg, the doyen of software testing1, defined quality as "value to some person". Value and quality are intrinsically linked and sometimes mean the same thing.
The current elevation of product discovery in our software product lifecycle, particularly in SaaS, means we must explore this relationship again. How does an emphasis on innovation of customer value impact our understanding of quality?
Discovering Customer Value
What exactly is product discovery, and how does it interact with product delivery?
Product discovery is an exploration of the problem space to discover customer value. Product discovery investigates the problem space to identify hypotheses on potential customer value. We only know if these hypotheses are correct once we deliver that value to our customers. Product delivery is that medium. The process of designing, building, releasing and maintaining software allows us to know for sure if business value is delivered.
It's not unfamiliar territory for most of us. Many say quality is "building the right thing and building the thing right"3.
We've previously treated these two phases as entirely separate entities. We look at the quality of discovery independent of the quality of delivery. In SaaS, we can't do that because the success of product discovery is dependent on the speed of product delivery. In fact, for some, dev velocity is a proxy for innovation5.
Building the right thing over building it right
Failing to build the right thing is more important than failing to build the thing right. If we make a product that nobody wants, how perfectly it works is irrelevant. Building a desirable product means how it works will matter more.
That means if a tradeoff between the two is required, the ability to innovate customer value matters more than the ability to deliver a perfect product.
That tradeoff exists and is called "speed to market". Because customer value is constantly changing, morphing, and evolving, the ability to quickly iterate and test assumptions on customer value is critical.
This is not great news for quality in the delivery space, where time is already the enemy of quality4. It could potentially impact the ability to test for product quality well.
Do we accept this tradeoff, or can we identify new ways to ensure quality that perhaps look beyond software testing?
