the customer's specification is not the customer's need

Quality is often defined, in practice, as conformance to specification. The part meets the print, so it is good. This is a workable and necessary definition, and it is also incomplete in a way that causes real trouble, because the specification is not the customer's need. It is a written attempt to capture that need, translated into measurable requirements, and like any translation it can lose things, get things wrong, or fail to capture what actually matters. You can conform perfectly to every requirement on the specification and still fail the customer, because meeting the spec and meeting the need are not the same thing.

the spec is a proxy, not the thing itself

A specification exists because the customer's actual need, that the product function correctly in their application, is hard to measure directly. So it gets translated into requirements you can measure: dimensions, tolerances, material properties, tests. Those requirements are a proxy for the real need, an attempt to define measurable conditions that, if met, should mean the product works. When the translation is good, conformance to the spec does mean the need is met. But the spec is always a model of the need, not the need itself, and the gap between the model and the reality is where conforming parts can still fail the customer. The print is a map. The customer's need is the territory, and the map is never perfectly the territory.

how the two come apart

The specification and the need diverge in ordinary ways. A requirement gets written that does not actually capture what matters, so a part can meet it and still not function. A real requirement gets left off the specification entirely, because whoever wrote it did not think to include it, so a part can meet every stated requirement and still fail on the unstated one. The customer's application changes and the specification does not keep up, so conformance to the old spec no longer means fitness for the new use. In each case the part is good by the letter of the specification and bad by the reality of the need, and an organization focused only on conformance will ship it confidently and be genuinely surprised when the customer is unhappy.

conformance can create false confidence

The danger of defining quality purely as conformance is the confidence it produces. When every requirement is met, the organization believes it has done its job, and that belief discourages the harder question of whether the requirements actually captured what the customer needed. A perfect conformance record can coexist with customers who are not getting what they need, and the conformance record actively obscures the problem, because it says everything is fine. The most dangerous version of a quality failure is the one where you met every specification, because it is the one your system is least equipped to detect, having been built entirely around conformance to those specifications.

understand the need behind the requirement

The stronger practice is to understand the need behind the specification, not just the specification itself. That means knowing what the customer is actually trying to accomplish, how the product functions in their application, and what really matters to them, so you can recognize when a requirement fails to capture the real need or when a real need is missing from the requirements. It means treating the specification as a living attempt to capture the need, one worth questioning and improving, rather than as the final and complete definition of quality. An organization that understands its customers' needs can catch the cases where conformance and fitness diverge. One that knows only the specification cannot, because it has no reference point outside the print.

meet the need, not just the spec

None of this diminishes the importance of conformance, which remains essential. You cannot meet the need without a good specification and disciplined conformance to it. The point is that conformance is necessary and not sufficient, and that the goal is meeting the customer's actual need, of which conformance to a well-written specification is the means, not the end. Keep the specification and hold it rigorously, and also keep sight of what it was trying to capture, so that when the two come apart, you notice, rather than shipping a perfectly conforming part into a failure the print never anticipated.

When you say a part is good because it meets specification, do you know whether the specification actually captures what your customer needs, or are you trusting a translation that no one has checked against the reality it was meant to represent?