CTQ Tree: How to Define Critical to Quality

A CTQ tree is one of the most practical tools in Six Sigma. It takes a broad customer need, something like "I want a reliable product," and breaks it down into specific, measurable requirements that engineers and process teams can actually work against. Without that translation step, teams end up optimizing for things that sound right but don't map back to what the customer cares about.

The full name is critical to quality (CTQ) tree, and it's typically one of the first tools deployed in the Define phase of DMAIC. It bridges the gap between raw customer voice and a project's target metrics.

What Is a CTQ Tree?

A critical to quality (CTQ) tree is a structured diagram that translates a customer need into driver categories, then into specific, measurable quality characteristics with defined performance targets. It runs left to right: one need, two to four drivers per need, and two to four measurable CTQs per driver.

The purpose is precision. "Customers want fast delivery" is a need. It tells you the direction but not the destination. A CTQ tree forces you to ask what "fast" actually means to the customer (is it order-to-ship time, or door-to-door transit time, or real-time tracking visibility?) and then define the measurable spec that, if met, satisfies the need.

CTQ trees come from Voice of the Customer (VoC) research. The VoC captures raw customer language. The CTQ tree translates that language into engineering and operational terms. From there, those CTQs become the Y's (dependent variables) that a DMAIC or DMADV project is built around.

Key Facts

• Companies that link quality metrics directly to customer requirements reduce defect costs by 20-30% compared to those using internally-derived specs alone (American Society for Quality, 2023 State of Quality report).
• Poor quality costs U.S. manufacturers roughly 5-30% of gross sales depending on the maturity of their quality systems (ASQ Quality Cost Survey).
• Six Sigma projects that begin with a validated CTQ tree reach the Improve phase 40% faster on average because the measurement system is already scoped correctly (iSixSigma industry benchmarks).

The Three Levels of a CTQ Tree

Every CTQ tree has exactly three levels. Each level answers a different question.

The CTQ at Level 3 must always carry a target and a spec limit. "Under 3 days" is a CTQ. "Fast" is not. If you can't write a pass/fail test for it, you haven't gotten to Level 3 yet.

CTQ Tree vs Other Quality Tools

CTQ trees work as part of a chain, not in isolation. Understanding where they sit relative to other tools prevents confusion about when to use each one.

Voice of the Customer (VoC) captures what customers say in their own words, through surveys, interviews, support tickets, and NPS comments. It's qualitative and often vague. A VoC exercise might surface "I wish the ordering process were less confusing," which is a need but not a measurable spec.

The CTQ tree sits immediately downstream of VoC. It takes that raw customer language and structures it into the three-level hierarchy. The output of the tree is a list of measurable CTQs with targets. Those CTQs then feed into the measurement plan.

KPIs are operational metrics the business tracks on an ongoing basis. They may or may not map to customer CTQs. The tree is how you confirm the mapping. If a KPI doesn't trace back to a driver and need in the CTQ tree, it's tracking something internal that may not matter to the customer.

Quality Function Deployment (QFD) (the House of Quality) takes CTQs and maps them to design or process parameters. CTQ tree comes first; QFD is what you do with the output.

In a DMAIC project, the tree fits into the Define phase, the VoC feeds the tree, and the tree feeds the measurement system in the Measure phase.

Common Mistakes

Stopping at Level 2. Teams often define drivers and call them CTQs. "Order processing speed" is a driver, not a CTQ. You need to push one level further and assign a numeric target.

Creating CTQs that can't be measured. If your team doesn't have a system that can capture data against a CTQ, it's not a working CTQ yet. Either fix the measurement gap or revisit the spec.

Conflating internal process goals with customer CTQs. "Reduce warehouse pick time by 15%" is an internal operational goal. It might support a driver, but it's not a CTQ unless a customer cares about pick time specifically. CTQs live in the customer's frame of reference, not the process owner's.

Too many CTQs. A single need can realistically be supported by six to ten CTQs. Teams that generate thirty CTQs per need are usually mixing needs, and the project scope bloats. Keep the tree tight. One well-scoped CTQ is worth more than five overlapping ones.

Skipping validation. A CTQ tree built in a conference room without checking it against real customer data is a hypothesis. Always verify the drivers and CTQs against actual VoC input before locking them in.

How to Build a CTQ Tree

Step 1: Gather Voice of the Customer Data

Before you draw anything, collect raw customer input. Interviews, surveys, complaint logs, NPS verbatims, sales call recordings. You need at least 20-30 distinct customer statements to see patterns. Group similar statements into themes.

Step 2: Identify the Customer Need

From your VoC themes, write one need statement in plain customer language. Keep it at the outcome level. "Receive my order quickly and intact" is a good need statement. "Have a 98% on-time delivery rate" is already starting to prescribe the solution.

One CTQ tree per need. If you have three distinct needs, build three trees. Don't combine them.

Step 3: Brainstorm Drivers

Ask: what factors, if they perform well, would satisfy this need? Drivers are categories of performance, not measurements yet. For "receive my order quickly and intact," drivers might be: order processing speed, shipping carrier performance, packaging integrity, and tracking visibility.

Aim for two to five drivers per need. Fewer means you're probably missing something. More than five means some of your drivers might be CTQs in disguise.

Step 4: Define Measurable CTQs with Targets

For each driver, define two to four CTQs. Each CTQ must have:

• A clear, measurable characteristic (e.g., "transit time in business days")
• A target value (e.g., "3 days")
• A spec limit (e.g., "no more than 5 days for 99% of orders")

Check the SIPOC diagram for your process at this point. It helps confirm which outputs in the process actually correspond to each CTQ, so you know where to collect data.

Step 5: Validate with Customers

Take your draft CTQs back to a sample of customers. Ask: if we hit this target consistently, would that meet your need? If they shrug, the CTQ is wrong. If they say yes but add a caveat, you have a new driver or a tighter spec.

This step prevents the most common project failure: teams spend weeks optimizing a metric that customers don't actually care about.

Step 6: Prioritize and Scope the Project

Not every CTQ becomes the focus of a project. Rank CTQs by their impact on customer satisfaction and the current gap between performance and target. The CTQs with the biggest gap and highest customer impact are where you start. Use DPMO and sigma level calculations to quantify the current defect rate against each CTQ spec.

CTQ Tree Example

This example follows an online food delivery company responding to customer feedback that "delivery feels unpredictable and slow."

A project team would then assess current performance against each CTQ spec to determine which ones are failing, by how much, and in which parts of the process. That feeds directly into the Measure phase of DMAIC, where the process capability (Cpk) for each CTQ gets calculated.

Best Practices

Keep the need statement in the customer's voice. Resist the urge to clean it up into business language. "Fast and predictable delivery" stays closer to the customer than "minimize order-to-door cycle time."

Date your trees. Customer expectations shift. A CTQ tree built for a 2022 e-commerce context may have targets that are too loose by 2026 standards. Review CTQs annually or whenever VoC data shows a shift in satisfaction drivers.

Link each CTQ to a process output. If you can't name the step in your process that produces the CTQ output, you can't measure it. Using a SIPOC diagram as a companion document makes this step fast.

Don't skip the measurement plan. A CTQ with no data collection plan is a wish. Before the tree is finalized, confirm that the data source, measurement frequency, and owner are all assigned.

Involve the process team in Step 3. Drivers brainstormed only by project leaders tend to miss the operational realities that frontline staff know. Mixed sessions produce better driver sets.

Frequently Asked Questions

What is the difference between a CTQ and a KPI?

A CTQ is a measurable characteristic defined from the customer's perspective, with a specific target tied to customer satisfaction. A KPI is an internal performance metric the business tracks for operational management. CTQs are customer-derived; KPIs are business-derived. A well-designed operation tries to make its KPIs trace back to CTQs, but many KPIs exist for reasons that have nothing to do with what customers care about.

How many CTQs should a Six Sigma project have?

A single DMAIC or DMADV project typically focuses on one to three CTQs. If your tree generates fifteen CTQs under one need, that's normal for the tree itself, but you'd then prioritize down to the most critical ones for the project scope. Trying to close a performance gap on too many CTQs at once dilutes team focus and makes it hard to isolate root causes.

Can you use a CTQ tree outside of Six Sigma?

Yes. The tool works anywhere you need to translate qualitative requirements into measurable specifications: product development, service design, software QA, supply chain onboarding. The methodology is Six Sigma in origin but the problem it solves (turning vague needs into measurable specs) is universal.

Where does the CTQ tree fit in DMAIC?

It belongs in the Define phase, after VoC research and before the project charter is finalized. The CTQ outputs become the Y variables in the charter and the target metrics for the Measure phase. If you're using DMADV for design projects, the tree sits in the Define phase there too.

What is the difference between a driver and a CTQ?

A driver is a category of performance that influences customer satisfaction. It explains why a need is or isn't met, but it's not measurable on its own. A CTQ is the specific, measurable characteristic within a driver, with a target and a spec limit. "Delivery speed" is a driver. "Door-to-door time under 35 minutes for 90% of orders" is a CTQ.

---

Translating customer needs into measurable specs is the foundation of every quality improvement project. Without that translation, teams improve the wrong things. With a CTQ tree in place, every project metric connects back to something a real customer said they cared about, and that's what separates process work that moves satisfaction scores from process work that just moves numbers.

Related reading

• Six Sigma
• DMAIC: The Five-Phase Improvement Cycle
• DMADV: Design for Six Sigma
• Voice of the Customer (VoC)
• Quality Function Deployment (QFD)
• SIPOC Diagram
• DPMO and Sigma Level
• Process Capability (Cpk)