APQP says: turn what the customer wants into things you can check. QFD is the heavy-duty tool for doing exactly that.
What it is
Quality Function Deployment was developed in Japan by Yoji Akao, starting in the late 1960s. Its best-known form, the House of Quality, came out of Mitsubishi's Kobe shipyard in the early 1970s and was later used heavily at Toyota and in the U.S. auto industry.
The House of Quality is a matrix that looks like a house:
- Left wall: the "whats." Customer needs, in their words, with an importance weight.
- Ceiling: the "hows." Engineering characteristics you can measure.
- Middle: the relationships. How strongly each "how" delivers each "what." Usually strong (9), medium (3), weak (1).
- Roof: the correlations. Which "hows" help or fight each other. Make it lighter, and it gets weaker.
- Right wall: competitors. How you and they rate on each need.
- Basement: targets and priorities. Which "hows" matter most, by adding up weight × relationship.
The result is a ranked list of what engineering should focus on, traced back to what customers said.
Why people skipped it
A House of Quality can have 30 needs and 30 characteristics. That's 900 cells to score by consensus. Teams spent days on it, got tired and filled in the rest with guesses. Many stopped using it.
How a bot does it
- Give it the voice of the customer. Real complaints, survey answers, interview notes, sales emails. Not a summary.
- Have it group the needs into a clean list in customer language, and propose weights from how often each comes up.
- Have it propose the "hows." Measurable characteristics, with units.
- Have it fill the matrix, with a one-line reason for every strong relationship.
- Have it fill the roof and flag the conflicts.
- Have it compute the priorities.
- People argue the weights and the strong cells. That's where judgment matters.
The bot brief
Build a House of Quality.
Voice-of-customer inputs: [files]. Product description: [file]. Competitor info: [file, optional].
1. Extract customer needs in the customer's own words. Group duplicates. Weight
each 1-5 by how often and how strongly it appears; show the count behind each weight.
2. Propose measurable engineering characteristics ("hows") with units and direction
(more is better / less is better / target).
3. Score each need x characteristic: 9 strong, 3 medium, 1 weak, blank none.
Give a one-line reason for every 9.
4. Roof: mark pairs of characteristics that help (+) or conflict (-).
5. Priority for each characteristic = sum of (need weight x relationship score).
Rank them.
Mark any need, weight or score not grounded in the inputs as GUESS.Starting point only. Test it on your own data and model, and adjust as needed before you rely on it.
An example (small)
A bot that writes weekly status reports. Customer is the plant manager.
| Need (weight) | Lines ≤ 40 | Owner column filled | Sources per figure | Delivered by 8 AM |
|---|---|---|---|---|
| "Quick to read" (5) | 9 | 1 | ||
| "Know who owes what" (4) | 9 | |||
| "Numbers I can trust" (5) | 9 | |||
| "Ready when I start" (3) | 9 | |||
| Priority | 45 | 41 | 45 | 27 |
Roof: "Lines ≤ 40" conflicts (−) with "Sources per figure," because citations take space. That's a real trade-off for a person to decide.
Where bots differ
QFD's power was supposed to come from the team arguing over every cell. That argument built shared understanding. A bot can skip straight to a filled matrix, which saves time but loses some of that. So hold the review meeting anyway, and spend it on the weights, the 9s and the conflicts in the roof.
And the "whats" must come from real customers. A bot imagining what customers want builds a beautiful house on sand. See APQP.
What this means for you
- Use QFD when a product has many needs pulling in different directions.
- Feed the bot real customer words.
- Let it fill the matrix. People argue the weights and the strong cells.
- Watch the roof for trade-offs.