We usually discuss software quality somewhere in the middle of the product lifecycle. Requirements have been defined. Work has entered the backlog. Engineering has started. Testing, Quality Assurance and Quality Engineering help ensure that the software is built and delivered well.
But the product’s quality story began earlier. It began when the organisation formed an intention: solve a problem, serve a customer, enter a market, reduce a cost or create a business outcome.
And the story does not end when the product is released. It ends—if it ends at all—when we can understand whether the product produces the outcome for which it was created.
This suggests a broader definition:
Quality is the integrity of the chain from business intent to business outcome.
The chain
The chain may be expressed simply:
Business intent
→ product decisions
→ engineering delivery
→ operational reality
→ business outcome
Each link translates something into something else.
Business ambition is translated into a product direction. Product direction is translated into capabilities, priorities and quality expectations. These are translated into engineering decisions and working software. The software enters an operational environment where customers, users, integrations, data and real workloads affect its behaviour. That behaviour contributes—or fails to contribute—to the intended outcome. Quality depends on the integrity of all these translations.
How the chain breaks
A product may fail because the original intent was unclear. It may fail because the organisation misunderstood the customer need or selected the wrong route to its ambition. It may fail because the right intent was translated into the wrong product. It may fail because engineering realised the product poorly. It may function as designed but prove unreliable, difficult to use, expensive to operate or impossible to scale. It may operate successfully and still fail to produce adoption, efficiency, customer value or commercial results.
These failures look different, but they share something important:
Somewhere between intent and outcome, the chain lost integrity.
This expands the meaning of a quality failure. A defect is a quality failure. But so is building a technically excellent capability that customers do not need. So is improving performance when the real obstacle to enterprise adoption is permissions, auditability or integration. So is meeting every acceptance criterion while failing to create the intended outcome.
Different disciplines protect different parts
Testing, Quality Control, Quality Assurance and Quality Engineering remain essential. But they do not protect the complete chain. Testing guards against not knowing how the product behaves. Quality Control guards against accepting outputs that do not conform to defined expectations. Quality Assurance guards against relying on processes and controls that cannot consistently produce dependable results. Quality Engineering guards against treating quality as something that can be inspected into the product at the end. Each protects an important part of the chain.
Product-quality assessment asks a more complete question:
Does the available evidence support the judgement that the product is right, good enough for its intended context and capable of producing its intended outcome?
It therefore guards against false confidence. Tests may pass. Requirements may be met. Delivery metrics may be healthy. The system may operate as designed. The organisation may still be wrong about the product.
The role of Product Ownership
Someone must preserve continuity of intent as the product moves through the chain. That does not mean one person owns every quality decision. But Product Ownership has a central responsibility for maintaining coherence between:
- the business ambition;
- customer and stakeholder needs;
- product decisions;
- quality expectations;
- engineering work;
- operational evidence;
- product learning.
Product Ownership should not merely feed work into engineering. It should help ensure that what emerges from engineering can still be traced to the purpose that justified the investment—and that evidence from operation changes future product decisions.
The role of governance
Product-quality assessment creates a basis for judgement. Governance determines what happens next. Leadership must decide:
- which outcomes and risks matter;
- what evidence is sufficient;
- which trade-offs are acceptable;
- who may accept remaining risk;
- whether to release, invest, redirect or stop.
This is why the complete view of quality cannot be delegated to testing or contained within delivery. It reaches into product strategy, investment and accountability.
The economic meaning of integrity
When the chain lacks integrity, the organisation pays in several ways. It pays the cost of being wrong when it invests in the wrong capability, assumption or market response. It pays the cost of failure through defects, incidents, disruption and lost trust. It pays the cost of operation through support demand, workarounds and recurring interventions. It pays the cost of future change when complexity, weak maintainability and unclear intent make every next improvement slower and more expensive.
When the chain retains its integrity, the organisation increases the likelihood that engineering effort becomes product value and that product value becomes business outcome. That may be the most complete business definition of quality:
Quality is the integrity of the chain from business intent to business outcome.
Everything else helps us understand where that chain can break, what evidence reveals its condition and how the organisation should respond.