Critical-to-quality (CTQ) characteristics are the specific, measurable requirements that a customer's definition of quality actually depends on. A CTQ tree is the tool that breaks a vague customer need down into quality drivers and then into numbered, measurable specifications you can build and check against.
Every plant has heard a customer say "we need it to be reliable" or "the finish has to look premium." Neither statement is something an operator can act on. The gap between what a customer wants and what a process can measure is where quality projects go to die, teams improve things nobody asked for and miss the one characteristic that drives the complaint. The CTQ tree closes that gap. This guide covers what critical-to-quality means, how to build a CTQ tree from a fuzzy need down to a hard spec, and how CTQs anchor an improvement project so you fix what actually matters.
What does critical-to-quality mean?
Critical-to-quality means a characteristic is one the customer's satisfaction genuinely hinges on, miss it and the customer notices, hold it and they are satisfied. A CTQ is not "everything we measure." It is the short list of features that, if they drift, turn into complaints, returns, or lost business.
The idea comes from Six Sigma, a discipline most plants run alongside lean where CTQs are the bridge between the voice of the customer and the numbers a process is run to. ASQ places the identification of customer requirements squarely in the Define phase of DMAIC, where the team "identifies customers and their requirements" before touching the process (ASQ, DMAIC Process). Get the CTQs wrong here and everything downstream, the measurement, the analysis, the improvement, optimizes the wrong thing with great rigor.
The distinction that trips people up: a CTQ is stated as a measurable requirement, not a wish. "High quality" is not a CTQ. "Fill weight 500 g ± 3 g" is. The whole job of the CTQ tree is to travel from the first to the second without losing the customer's intent along the way.
What are the three levels of a CTQ tree?
A CTQ tree has three levels: the customer need at the top, the quality drivers in the middle, and the measurable CTQ requirements at the bottom. You read it left to right, getting more specific at each step.
- Need. The customer's requirement in their own words, general, often vague, and not directly measurable. "The bottle looks premium." This is what you hear in a complaint or a spec review.
- Drivers. The characteristics a customer actually judges that need by. What makes a bottle "look premium"? Label placement, print sharpness, absence of scratches, color match. Drivers translate the need into the handful of things that move the customer's perception.
- CTQ requirements. Each driver becomes one or more measurable specs with a target and a tolerance. "Label placement within 1.0 mm of nominal." "No visible scratch larger than 0.5 mm." Now the floor has something to build to and check against.
SixSigma practitioners describe the CTQ tree as the tool that translates broad, subjective customer needs into specific, measurable performance requirements (ASQ, Six Sigma). The tree's shape does the work: one need branches into several drivers, and each driver branches into one or more numbered CTQs.
How do you build a CTQ tree?
You build a CTQ tree by starting with a real customer need, expanding it into the drivers the customer judges it by, and pushing each driver until it becomes a number. The discipline is refusing to stop until every leaf is measurable. The sequence:
- Capture the need in the customer's words. Pull it from the voice of the customer, complaints, spec reviews, returns, interviews. Write it as they said it, vague and all. "It jams in our machine." "The seal fails in the cold."
- Ask what drives that need. For each need, ask what specific characteristics the customer is really reacting to. "Jams in our machine" might be driven by dimensional variation, burrs, and packaging orientation. Brainstorm the drivers with people who know the product and the customer.
- Push each driver to a measurable requirement. Keep asking "measured how, to what limit?" until you have a spec with a target and a tolerance. A driver you cannot turn into a number is a sign you do not yet understand it, keep going.
- Set the target and tolerance from the customer, not convenience. The limit has to reflect what the customer actually needs, tied to their spec or a validated requirement, not the tolerance your process happens to hold today. If the two disagree, that gap is your project.
- Confirm you can measure it capably. A CTQ you cannot measure reliably is not usable. Check that the gauge or test has acceptable error relative to the tolerance before you commit to the spec.
- Prioritize the vital few. Not every CTQ carries equal weight. Rank them by impact on the customer and on cost, and focus effort on the handful that drive most of the risk, the same vital-few logic behind a Pareto chart.
- Carry the CTQs into the control plan. The CTQs you land become rows in the control plan each with its spec, its check, and its reaction plan, so the requirement gets controlled on every shift, not just noted once.
Where do CTQs fit in an improvement project?
CTQs are defined at the very start of a project and steer everything after it. In DMAIC, they are a Define-phase output, and they set the target the Measure, Analyze, and Improve phases work toward. The logic is simple: you cannot measure a gap until you know which characteristic matters, and you cannot know that until you have translated the customer's need into a CTQ.
This is also what keeps a project honest. A team without clear CTQs tends to improve whatever is easiest to measure or most annoying to the engineers, and then wonders why the customer is still unhappy. A team anchored on CTQs improves the specific characteristics the customer's satisfaction depends on, and can prove the improvement in the customer's own terms. In practice, most products have only a handful of true CTQs even when the drawing carries dozens of dimensions; the discipline is separating the characteristics a customer would actually notice from the ones that are merely easy to inspect.
| Vague statement | Driver | CTQ (measurable) |
|---|---|---|
| "Seal fails in the cold" | Adhesive bond strength | Peel strength ≥ 12 N at −10 °C |
| "Parts don't fit" | Bore diameter variation | Bore 25.00 mm +0.02 / −0.00 |
| "Looks cheap" | Surface finish | Ra ≤ 1.6 µm, no scratch > 0.5 mm |
| "Runs out too fast" | Fill accuracy | Net weight 500 g ± 3 g |
How does CTQ relate to Six Sigma and cost of quality?
CTQs are where Six Sigma gets its name and its economics. The "six sigma" target, very few defects per million opportunities, is defined against a CTQ's specification limits: the tighter the process sits inside the customer's tolerance, the higher the sigma level and the better its process capability. Without a measurable CTQ, there is no spec limit to be six sigma away from, and the whole framework has nothing to grip.
The money follows the same logic. Missing a CTQ is what generates cost of quality scrap, rework, returns, and warranty. ASQ notes that total quality costs commonly run 15–20% of sales (ASQ, Cost of Quality), and a large share of that traces back to characteristics that were never clearly defined or never reliably controlled. Nailing the CTQs is the front end of holding that cost down: you cannot prevent defects and rework on a characteristic you never pinned to a number.
How do you keep CTQs controlled on the floor?
Defining a CTQ is a whiteboard exercise; holding it is a floor exercise, and the two are often disconnected. A beautifully built CTQ tree is worthless if the resulting check lands on a clipboard nobody reviews until the customer calls. The value of a CTQ is the fast feedback when it drifts, and that requires the check data to come back in the moment, not at month-end.
When the CTQ checks operators run are captured digitally at the station and flow into one operational layer, a drift on a critical characteristic can be caught while the lot is still on the line, and the highest-risk CTQs can be mistake-proofed at the station with a poka-yoke so the defect cannot be made at all. Harmony digitizes those checks and connects them to the machines and systems around the line in one live layer no rip-and-replace of your gauges or software, so a CTQ that starts moving triggers a response during the shift rather than a complaint the following week. When CLS moved its quality logging off paper checks that used to be filed and forgotten became signals the team could act on live.
Start from the customer, not the process. Build the tree, land every leaf on a number, carry the vital-few CTQs into your control plan, and make sure the checks come back fast enough to act on. That is how "we need it to be reliable" becomes something a plant can actually deliver.