Process / pipelineExperimental designEngineering methodsPipeline

Quality Function Deployment — House of Quality

Also known as: QFD, House of Quality, customer-driven engineering, voice of the customer matrix

OriginatorYoji AkaoYear1966 (Japan); popularised in the West ~1988Sources2Related methods16

Quality Function Deployment (QFD) is a structured method for translating customer needs — the voice of the customer — into specific technical requirements at every stage of product or service development. Originating in Japan in the 1960s, QFD uses a matrix-based tool called the House of Quality to make customer priorities visible, link them to engineering parameters, expose trade-offs, and maintain focus on what customers actually value throughout the design process.

Key highlights

  • Directly links customer requirements to engineering decisions, reducing the risk of building features customers do not value.
  • Reveals technical trade-offs and parameter conflicts early — before costly design commitments are made.
  • Provides a structured, visual artefact that aligns marketing, engineering, and manufacturing teams around shared priorities.
  • Supports competitive benchmarking by comparing both customer perception and technical performance simultaneously.
  • Can be cascaded across four planning phases — product planning, part deployment, process planning, production control — for end-to-end traceability.

Intuition

This section is available to Pro members. Upgrade to Pro

How it works

This section is available to Pro members. Upgrade to Pro

When to use it

Use QFD at the outset of a new product or service development project, or when redesigning an existing offering, when there is a risk of engineering effort being misaligned with what customers actually value. It is particularly valuable in competitive markets where differentiating on customer-relevant performance matters, in complex products with many interacting design parameters, and when cross-functional alignment between marketing and engineering is difficult. Do not use QFD as a substitute for quantitative testing or validation — it structures priorities and targets but does not replace physical experiments, prototype testing, or statistical process control in production. Avoid it for very short-horizon, low-complexity changes where the cost of building the matrix outweighs the benefit.

Strengths & limitations

Strengths
  • Directly links customer requirements to engineering decisions, reducing the risk of building features customers do not value.
  • Reveals technical trade-offs and parameter conflicts early — before costly design commitments are made.
  • Provides a structured, visual artefact that aligns marketing, engineering, and manufacturing teams around shared priorities.
  • Supports competitive benchmarking by comparing both customer perception and technical performance simultaneously.
  • Can be cascaded across four planning phases — product planning, part deployment, process planning, production control — for end-to-end traceability.
Limitations
  • Building a full House of Quality matrix is time-intensive and requires sustained cross-functional collaboration.
  • Quality of outputs is highly dependent on how well customer needs have been captured; poor voice-of-customer data produces misleading importance rankings.
  • Relationship scores are often assigned subjectively; without structured expert elicitation the matrix can reflect team biases rather than true relationships.
  • QFD does not itself generate solutions — it structures the problem and sets targets, but engineering creativity and experimentation are still required.
  • For services or software products where requirements change rapidly, the static matrix can become outdated before it is fully deployed.

Common pitfalls

This section is available to Pro members. Upgrade to Pro

Applications

This section is available to Pro members. Upgrade to Pro

Frequently asked

How is QFD different from a requirements document?

A requirements document lists what a product must do. QFD goes further by explicitly linking requirements to customer importance weights, showing how engineering parameters affect each requirement, exposing conflicts between parameters, and benchmarking against competitors. The matrix format makes prioritisation visible and forces cross-functional agreement on which engineering investments matter most.

What are the four phases of QFD?

Phase 1 (Product Planning) translates customer needs into engineering characteristics. Phase 2 (Part Deployment) translates critical engineering characteristics into part characteristics. Phase 3 (Process Planning) translates critical part characteristics into key process parameters. Phase 4 (Production Planning) translates key process parameters into production and quality control requirements. Many projects apply only Phase 1; all four phases are used for full traceability from customer voice to shop-floor control.

How many customer requirements should be included?

In practice, 15–30 customer requirements is a workable range for a Phase 1 matrix; above 50 the matrix becomes unwieldy. Use affinity diagrams or hierarchical structuring to consolidate similar wants. Focus on requirements that are rated high in importance or where you suspect a competitive gap exists.

Can QFD be combined with Design of Experiments?

Yes, and this is strongly recommended. QFD identifies which technical parameters are most important and sets target values; Design of Experiments (DoE) then provides an efficient way to validate or refine those targets by running structured experiments that quantify the actual effect of each parameter on product performance, replacing subjective relationship scores with measured data.

Is QFD applicable to software and service development?

Yes, though adaptations are needed. For software, customer requirements map to functional and non-functional specifications; technical parameters become architecture decisions and performance metrics. For services, customer requirements map to service delivery standards, staff competencies, and process times. The core logic of prioritising by customer importance and exposing trade-offs is equally valid, but the matrix must be rebuilt as requirements change — agile or iterative QFD variants exist for faster-moving contexts.

Sources

  1. 1.
    Akao, Y. (Ed.). (1990). Quality Function Deployment: Integrating Customer Requirements into Product Design. Productivity Press.
    ISBN 978-0915299416
  2. 2.
    Hauser, J. R., & Clausing, D. (1988). The house of quality. Harvard Business Review, 66(3), 63–73.

You have read it. What now?

Cite this page

ScholarGate. (2026, June 3). Quality Function Deployment. ScholarGate. https://scholargate.app/experimental-design/quality-function-deployment

Quality Function Deployment | ScholarGate