Quality Function Deployment
Translating the Customer’s Voice into Engineering Language
The past two articles in this series established two things that are in tension with each other. First, customers have wants which can be identified, understood, categorized, and prioritized with the right tools. Namely, the Kano Model. At the same time, the physical world imposes hard constraints on what a design can deliver, and optimizing in one direction always costs something in another. If you have been following along, you might be wondering how those two realities get reconciled in practice. How does a design team take a prioritized list of customer wants and turn it into actual design specifications, while keeping the tradeoff landscape visible throughout the process? Essentially, how does design emerge from knowledge of customer desires?
It turns out that the translation from customer language to design language is one of the most consequential and most poorly executed steps in the entire product development process. If done well, it produces a design brief that is both customer-grounded and technically executable. If done poorly, it produces a product that technically meets its specifications and still manages to disappoint the people it was built for. The gap between those two outcomes is wider than most product teams realize, and closing it requires rigor and structure rather than genius and intuition.
The Voice of the Customer
Before you can translate customer wants into technical specifications, you have to capture those wants in a form that is usable. This is the domain of Voice of the Customer work, commonly abbreviated as VoC. Collecting the Voice of the Customer is not simply a matter of sending out a satisfaction survey or reading through product reviews. Those inputs have value, but they tend to surface symptoms rather than causes, and they reflect the experience of existing products rather than the requirements for new ones.
We’ve of course already encountered VoC, in the Kano model. The Kano model is just one approach to VoC, and I started with it, because I find it extremely helpful to understand the dynamics of customer wants. But VoC writ large, is a more encompassing idea and practice which we should give a bit more attention to.
Fundamentally, VoC is structured listening. It involves direct customer interviews, contextual observation, focus groups, and in some cases the kind of paired survey methodology we discussed in the first article when we covered the Kano model. The goal is not to collect opinions but to uncover the underlying needs that customer opinions point toward. A customer who says a carpet cleaner is too heavy is expressing a frustration, but the underlying need is ease of use during extended cleaning sessions. Those are related but not identical, and the distinction matters enormously when it comes time to write a specification.
The raw output of VoC work is typically a list of customer statements, verbatim or paraphrased, describing what customers want, what frustrates them, and what would make their experience better. These statements are sometimes called customer requirements, customer needs, or simply the voice. They are expressed in customer language, which tends to be qualitative, contextual, and occasionally vague. “Easy to use” is a voice of the customer statement. “Lightweight” is a voice of the customer statement. “Doesn’t leave streaks” is a voice of the customer statement. None of them is a specification yet. They are the raw material that the design process needs to refine.
The discipline of VoC work is making sure that the raw material is complete and representative before the translation process begins. Missing a customer segment, over-weighting one type of user, or focusing only on current customers rather than potential ones can introduce bias into the process that propagates all the way through to the final design. The output of VoC is only as reliable as the inputs that generated it, and most organizations underinvest in this step relative to the downstream engineering work it is meant to inform.
The Translation Problem
The core challenge is taking this VoC and translating it into specification for a design. After all, customer language and engineering language describe the same product from fundamentally different perspectives, and those perspectives do not map onto each other neatly. A customer says they want a vacuum cleaner that is easy to push across carpet. An engineer needs to know the rolling resistance of the wheel assembly in newtons, the coefficient of friction between the base plate and carpet fiber, and the maximum push force that a typical user can comfortably sustain over a thirty-minute cleaning session. How do you map those? Both descriptions are about the same physical reality. But one is expressed in terms of human experience and the other in terms of measurable physical quantities. Getting from the first to the second without losing the intent of the customer requirement is genuinely difficult, and it requires a deliberate process rather than an informal one.
How this mapping exercise usually fails is something called specification drift. The design team receives the voice of the customer, translates it informally into technical requirements, and somewhere in that translation the original customer intent gets compressed or lost. The customer wanted “easy to maneuver in tight spaces.” The engineering requirement became “minimum turning radius of 18 inches.” The product ships with a turning radius of 17 inches, the team declares success against the specification, and the product reviews still describe it as hard to maneuver in tight spaces. What went wrong is that the specification captured one dimension of the original customer want but not all of it. Maneuverability in tight spaces is not merely about turning radius, but also depends on other aspects of the product (say hose flexibility, wheel placement, handle ergonomics, weight). The translation was too narrow and technical. The narrowness was invisible because no one built a map between the customer requirement and the full set of engineering characteristics that needed to respond to it.
That mapping process is exactly what Quality Function Deployment is designed to provide.
Quality Function Deployment
Quality Function Deployment, known almost universally by its abbreviation QFD, is a structured methodology for translating customer requirements into technical specifications in a way that preserves the connection between the two throughout the design process. It was developed in Japan in the late 1960s, introduced at the Mitsubishi shipyard in Kobe, and subsequently adopted by Toyota and a wide range of manufacturers who found that it produced designs with fewer late-stage revisions and stronger market reception. The core insight behind QFD is that every technical decision in a product design should be traceable back to a customer requirement, and that the relationships between customer requirements and technical characteristics should be made explicit rather than assumed.
QFD is not a single tool but a family of connected matrices that can be applied across the entire product development process, from initial concept through production planning. In practice, most teams encounter QFD through its first and most prominent matrix, which is called the House of Quality. The House of Quality is where the translation from customer language to engineering language actually happens, and it is worth understanding in some detail.
As a side note to our topic, you can use QFD internally too. So after your product designs have been finalized, you might apply the QFD to your manufacturing processes to understand what is required to build the products themselves. This is actually what QFD was developed for - the deployment of quality within an organization, to ensure that everything works together to support the needs of the customer. Kind of cool.
The House of Quality
The House of Quality gets its name from its visual structure, which resembles a building with a triangular roof sitting atop a rectangular body. It is a matrix, but a matrix with several distinct regions that work together to capture not just the what and the how of product design but also the relationships between them and the tradeoffs they imply. Walking through each region in order is the clearest way to understand how the tool works and why the structure is the way it is.
The left side of the matrix is where the customer requirements live. These are the VoC statements, organized and sometimes grouped into logical clusters. Each requirement is also assigned an importance weighting, typically drawn from the Kano survey data or from direct customer prioritization exercises. A must-have requirement carries more weight than a performance attribute, which in turn carries more weight than an indifferent feature. The importance weightings are critical because they propagate through the entire matrix and ultimately determine which engineering characteristics the design team should invest most heavily in. Getting the weightings right is as important as getting the requirements right in the first place.
The top of the matrix is where the engineering characteristics live. These are the technical parameters that the design team controls, the measurable, objective descriptors of the product that can be specified, tested, and verified. For a carpet cleaner, these might include total unit weight in kilograms, handle height in centimeters, wheel diameter, hose flexibility measured in minimum bend radius, suction power in air watts, and noise output in decibels at one meter. Each of these is a number that can be put on a drawing, tested against a target, and verified in production. The engineering characteristics are the bridge between the customer’s experience and the physical reality of the product.
The body of the matrix is where the translation actually happens. Each cell in the body represents the relationship between one customer requirement and one engineering characteristic. The team works through each cell and asks a simple question: if we improve this engineering characteristic, does it help us deliver this customer requirement? If the answer is yes, they record the strength of that relationship, typically using a numerical scale where nine indicates a strong relationship, three indicates a moderate relationship, and one indicates a weak relationship, and empty cells indicate no meaningful relationship at all. This relationship mapping is the intellectual heart of the House of Quality. It is where the team is forced to think explicitly and collectively about which technical levers actually move the customer satisfaction needle and which ones are disconnected from customer experience entirely.
The roof of the matrix is where the tradeoffs from Article 2 of this series show up explicitly. And for my money, this is the part that I find most interesting and exciting. The triangular roof section maps engineering characteristics against each other and identifies where they conflict. Improving one characteristic helps another, which is a positive correlation marked with a plus sign, or improving one characteristic hurts another, which is a negative correlation marked with a minus sign. For the carpet cleaner, reducing total unit weight is positively correlated with ease of maneuverability, because a lighter unit is easier to push and lift. But reducing weight may conflict with suction power, because the motor and impeller assembly that generates strong suction adds mass. The roof makes that conflict visible on paper, in the planning phase, before it becomes a problem in the lab or on the production floor.
The Value of the House of Quality
It is worth stepping back and asking what problem this tool is really solving, because the House of Quality can look, at first glance, like an elaborate way to document things a good engineering team already knows. This reaction misses the point completely, however. The House of Quality is not primarily a documentation tool but a communication tool and a decision-forcing mechanism.
Product development involves multiple functions with genuinely different perspectives and priorities. Marketing understands what the customer says they want. Engineering understands what is physically achievable. Manufacturing understands what can be produced and scaled reliably. Each of these functions brings legitimate expertise to the table, and each of them also brings the natural tendency to optimize for the things within their own domain. The House of Quality creates a shared artifact that all of these functions can look at together, argue about together, and ultimately align around. The relationship matrix in particular forces conversations that might otherwise never happen. When marketing sees that a customer requirement which was rated as highly important has no engineering characteristic with a strong relationship to it, that is a signal that something is missing. It triggers a discussion about how to actually produce this design in a product.
When engineering sees that two highly-weighted customer requirements pull in opposite directions through the roof matrix, this should trigger a conversation about tradeoffs. And conversely, if there are two highly-weighted customer requirements pulling in the same direction, this should trigger a conversation about procuring the best, highest quality materials, regardless of cost, because the customer is going to reward you for your efforts.
The House of Quality also creates accountability over time. When a product ships and a customer requirement is not well served, the team can return to the matrix and ask where the breakdown occurred. Was the customer requirement missing or underweighted? Was the engineering characteristic that should have addressed it poorly specified? Was the target value set too conservatively? Was the relationship between the requirement and the characteristic overestimated? The matrix provides a structured place to diagnose the failure, rather than simply experiencing it as a vague sense that the product missed the mark.
Conclusion
Quality Function Deployment is not sexy. It is not exciting, and as far as product development is concerned, it is probably the most technical and driest aspect of the whole process. Nevertheless, it’s necessary. If there is no way to map the desires of the customer to the technical specifications of the product, or if the mapping is inconsistent and highly variable the result will be catastrophic for the project. Indeed, the product development process itself may be responsible for the success or failure of the product.
I don’t like to lean too heavily on or speak too often about tools, but in this case the House of Quality is the right tool for the job. Particularly paying attention to the roof which allows us to visualize the ways customer expectations support or conflict with themselves. Taken together, QFD and the House of Quality are exactly the right thing to do to bring the wants and expectations into a designed reality.
You finished the article!
It was free!
Please: