What IS Quality?
Moving beyond vague notions to something you can actually work with
This is the first in a series of posts exploring quality and quality management, with the goal to distill and clarify how to create and maintain great quality products for any given context. As usual for my thinking there will be more abstract posts describing models and structures for reasoning and some concrete examples covering common pitfalls and how to avoid them. We’ll start with a fundamental definition: “What is Quality?”
We throw around the word “quality” constantly in software development. “We need to improve quality.” “This release has quality issues.” “Quality is everyone's responsibility.”
But what does it actually mean?
Most dictionary definitions are about as useful as a chocolate teapot. “The standard of something as measured against other things of a similar kind.” Great. Thanks. That really helps when I'm trying to decide whether to ship this feature or spend another week testing it.
The Problem with Vague Quality
When quality means everything, it means nothing. I've sat in countless meetings where teams argued about quality without anyone bothering to define what they were actually talking about. While there’s often an overall tacit shared “vibe” of goodness, one person thinks quality mainly means “no bugs.” Another thinks it mainly means “elegant code.” Someone else is arguing from a need for “user satisfaction.”
They're all right. And they're all wrong.
The Game-Changing Definition
Years ago, in a Rapid Software Testing course, I was introduced to a definition that completely changed how I think about quality. James Bach/Michael Bolton, running the course, built on a Jerry Weinberg quote to create this profound statement:
Quality is value to some person who matters.
It sounds almost too simple, doesn't it? But this definition does something powerful - it forces you to be specific about two crucial questions:
Who matters?
What do they value?
Why This Definition Actually Works
Let's say you're building a mobile app. Using the Weinberg-Bolton-Bach definition, you might identify:
Who matters:
End users
Your product manager
Customer support team
Your engineering team
Company executives
What they value:
Users: Fast, reliable, intuitive interface
Product manager: Meets requirements, ships on time
Support team: Clear error messages, diagnosable issues
Engineering team: Maintainable and extensible code, good test coverage
Executives: Revenue impact, competitive advantage
Suddenly, “quality” isn't some abstract concept. It's concrete things you can actually work on.
Also note that this means that “quality” changes based on context. A quick internal tool has different quality requirements than a customer-facing product. A proof-of-concept has different standards than a production system.
In Korea, quality often means “cutting-edge and new.” In the UK, it's more about “solid and lasting.” Neither is wrong - they're just optimizing for what their users value.
The Startup Quality “Problem”
This is a scenario I see constantly - it’s almost a caricature in the industry and you’ll all recognise your own version of it. A startup builds something fast and scrappy to find product-market fit. Minimal documentation, shortcuts everywhere, tests that barely cover the happy path. They're moving fast and breaking things, and it works.
Then they get traction. Suddenly they need to sell to enterprises, support multiple customers, maintain uptime. And the conversation shifts to: “We have a quality problem. Why is quality so low? How do we balance improving quality with maintaining velocity?"
Stop. This isn't a quality problem.
The quality hasn't changed. The context has. “Who matters and what they care about” has shifted dramatically:
Before (Startup Mode):
Who matters: Founders, early adopters willing to tolerate bugs
What they value: Innovation, speed to market, solving the core problem
After (Growth Mode):
Who matters: Enterprise customers, sales team, support staff, investors
What they value: Reliability, security, compliance, scalability
The code didn't suddenly become "low quality." It was exactly the right quality for its original context. Now it needs to be the right quality for a new context.
Why This Reframe Changes Everything
When you understand this as a context shift rather than a quality deficit, several things become clear:
You can plan for it. If you're thinking about quality contextually from day one, you can anticipate these shifts and prepare for them.
You can be strategic about improvements. Instead of blanket "improve quality," you can ask: "What specific aspects matter to our new stakeholders?"
You can communicate the change. Your team understands why they're refactoring that hacky authentication system - not because it was “bad,” but because enterprise customers value security differently than MVP users did.
You can preserve what matters. Maybe that scrappy deployment process was actually really good for fast iteration. Don't throw it away just because you're also building robust monitoring.
Making It Practical
So how do you use this in real work? Start by making two lists:
Who are the people that matter for this project? Be specific. Not just “users” but “power users who process 100+ transactions daily” or “new users trying the product for the first time.”
What does each group actually value? Don't guess. Ask them. You'll be surprised how often your assumptions are wrong.
Then use these lists to make decisions. When you're debating whether to fix that edge case bug, ask: “Who does this affect and what do they value?” The answer will tell you how important it is.
Sometimes different groups want contradictory things. Users want new features; operations wants stability. Sales wants customization; engineering wants simplicity.
This isn't a problem to solve - it's a tension to manage. The definition doesn't magically resolve conflicts, but it does make them them visible and discussable. Instead of arguing about trading abstract "quality" against other things, you're negotiating between specific, understandable trade-offs.
The Bottom Line
Quality isn't some mystical property you sprinkle on your software like fairy dust. It's about understanding who you're building for and what they actually need.
Next time someone says “We need better quality!” push back and ask: “Quality for whom? Quality how?” The answers will tell you where to focus your efforts.
And if they can't answer those questions? Well, then you know why your quality efforts aren't working and you’ve got a good place to start!
Next in this series: Measuring Quality - Don’t Tell Me Your %$£&! Bug Counts