House of Quality
The House of Quality is a matrix that lines up what customers actually want against the technical requirements engineering can control, so a product team can see which technical choices genuinely move the needs that matter, not just the ones easiest to build.
A grid lines customer needs down the side against technical requirements across the top, capped by a triangular roof of correlations.
Reach for this when…
- Engineering and customer-facing teams disagree about which features matter.
- You're optimising a spec that customers never actually asked for.
- A product redesign needs to prioritise trade-offs and nobody agrees on the order.
How to run it
- List customer needs (the WHATs) and rank their importance to the customer.
- List technical requirements (the HOWs) that the team can actually control.
- Score how strongly each technical requirement affects each customer need.
- Check the correlations between technical requirements themselves - some conflict.
- Set technical targets weighted toward the requirements with the strongest customer impact.
A worked example
Situation. Camila Quispe led product development for a small appliance maker in La Paz, Bolivia, redesigning a pressure cooker where engineering and sales disagreed on what to prioritise.
Applied. Building the matrix, the customer need ranked highest - 'feels safe to leave unattended' - correlated most strongly with a technical requirement engineering had ranked low: valve response time, not the handle redesign sales had been pushing.
Result. They reallocated the budget toward valve response time. Customer safety ratings in testing rose sharply, and the handle redesign, which had eaten most of the original budget, was quietly dropped.
The catch
Building the matrix properly is slow and needs real customer data, not assumptions dressed up as customer needs - weak rankings in produce a confident-looking wrong answer. It also handles trade-offs between technical requirements only as well as the team's honesty about where two requirements actually conflict. Treat the output as a prioritisation aid, not proof.
A high score for a technical requirement nobody asked for is still nobody asking for it - check the customer need it maps to before you fund it.
Origin: Yoji Akao