A product can be beautifully engineered, genuinely useful and still fail as a business. That is an uncomfortable idea, particularly for those of us who have spent years improving software quality. But it is also where the conversation about AI, product judgement and quality needs to go next.

In the first article in this series, I explored why technically correct code can still implement the wrong functionality. In the second, I examined how AI can generate a flood of plausible features, creating product noise rather than meaningful value.

There is a third decision beyond both: even when we build the right product, are we building a sustainable business?

1. A quality product is not automatically a valuable business

Imagine a reliable, accessible, elegant application. Customers appreciate it. Its performance is excellent, its defects are few and its engineering is maintainable.

Now imagine that acquiring and supporting each customer costs more than the revenue that customer generates. Or that the product solves a real problem, but not one customers will pay enough to solve.

The product may have strong technical and experiential quality. Its business proposition may still be unsustainable.

Quality matters because of the outcomes it enables—not simply because of the sophistication it demonstrates.

This does not reduce quality to profit. Customer trust, accessibility, safety, reputation and resilience are all meaningful outcomes. Some are obligations rather than optional investments. But it does mean that quality decisions should be connected to a clear understanding of the value being protected or created.

2. How much quality is enough?

We often speak about improving quality as if every improvement is equally valuable. It isn't.

A payment platform may need exceptionally high availability because minutes of downtime can interrupt transactions and damage trust. A low-use internal reporting tool may need a different availability target, provided its users and operational risks are understood.

Both need appropriate quality. They do not necessarily need identical quality targets.

The relevant questions are: What happens when this fails? Who is affected? What level of reliability do users reasonably expect? What contractual, security, accessibility or regulatory obligations apply? What would improving the outcome cost—and what other valuable work would that displace?

Quality is not a contest to maximise every metric. It is the discipline of setting defensible standards for the context.

3. AI can create strategic noise, too

AI can help us explore markets, pricing models, adjacent customer segments, monetisation strategies and new services in seconds. That breadth is useful during discovery.

But a plausible opportunity is not a validated business opportunity. A polished business case is not proof of demand. A forecasted saving is not a realised saving.

The same pattern we see in product backlogs can appear in business strategy: one suggestion becomes an initiative, then a project, then a commitment. Teams spread their attention across ideas that sound reasonable but have not been tested against the business proposition.

We can become extremely busy pursuing possibilities while making little progress toward sustainable value.

AI can accelerate opportunity discovery. Business judgement decides which opportunities deserve investment.

4. Connect quality decisions to business outcomes

Quality teams often report defects, coverage and release activity. Those measures can be useful, but they do not explain the full business consequence of quality.

Instead, ask which outcome each quality investment is intended to improve.

Quality dimension Business consequence Evidence to examine

Reliability Lost transactions, disrupted operations, customer trust Failure frequency, downtime cost, recovery time

Usability Adoption, conversion, support burden Task completion, abandonment, support contacts

Functional suitability Whether the product solves a valued problem Research, retention, observed usage

Maintainability Cost and speed of future change Rework, change lead time, maintenance effort

Security and trust Customer harm, exposure, continuity Threat assessments, incidents, audit findings

Release confidence Risk of delivering change Escaped defects, rollback frequency, recovery

Not every organisation needs every metric. A handful of measures tied to meaningful outcomes is more useful than a large dashboard that nobody can act on.

5. Quality is an investment decision—but not everything has a price tag

Every additional control, test, design refinement or reliability improvement uses resources. The business needs to understand what those resources achieve.

Sometimes an investment reduces rework or support costs. Sometimes it increases conversion or retention. Sometimes it prevents a rare but catastrophic failure. Sometimes it is necessary to meet a legal or ethical obligation, regardless of whether it produces an attractive short-term return.

The mistake is to treat all quality work as either unquestionable good or avoidable overhead. Both positions ignore context.

The goal is not to spend as little as possible on quality. It is to invest deliberately in the characteristics that protect people, meet obligations and create durable value.

6. Use AI to challenge the business case, not merely write it

AI is useful for comparing scenarios, exposing assumptions and finding inconsistencies. But its outputs should be treated as hypotheses until checked against actual customers, financial data, operating constraints and credible evidence.

Instead of asking AI, “How could we monetise this product?”, try asking: “Which of these revenue assumptions are unvalidated? What evidence would disprove them? What is the smallest experiment that would test demand?”

Instead of asking, “How do we improve quality?”, ask: “Which failures create the greatest user harm or business consequence? What evidence supports the proposed improvement? What would we stop doing to fund it?”

AI becomes more useful when we ask it to expose uncertainty rather than conceal it behind polished recommendations.

7. The three judgements that shape value

Across this series, I keep returning to three connected disciplines.

Engineering judgement asks whether the implementation is technically appropriate and dependable.

Product judgement asks whether the functionality belongs in the product and solves a meaningful problem.

Business judgement asks whether delivering and sustaining that value justifies the investment and supports the organisation's purpose.

None can replace the others. A technically correct feature can be unnecessary. A useful product can be commercially unsustainable. And a profitable product can still fail essential standards of safety, fairness or trust.

Good decisions require the disciplines to challenge and inform one another.

Final thought: Value is the reason quality matters

AI is making it easier to build software, imagine products and develop business cases. That is a tremendous advantage—provided we do not confuse the volume of possibilities with the quality of our decisions.

We should not ask only whether we can build something, whether it works or whether customers might like it. We must also ask what it contributes, what it costs, what risks it introduces and whether it creates sustainable value.

Engineering judgement determines what works. Product judgement determines what matters. Business judgement determines what creates sustainable value.

The future of quality is not simply more testing, more features or more sophisticated technology. It is better judgement about where quality matters most—and the discipline to act on that judgement.

That is where strategy meets quality.