Voice of the customer
CTQ tree
CTQ tree is licensed CC BY 4.0. Attribution: Katafacts (katafacts.com).
Customise with AISkill file ↓1 · What it is
What it is
A CTQ (critical-to-quality) tree closes the gap between 'customers want X' and something a team can actually build to and measure against. It's a three-level tree: a customer need at the top, the quality drivers that make that need satisfied or not underneath it, and one or more specific, measurable characteristics with a concrete target under each driver. 'Fast support' isn't a CTQ — 'time to first response, target under one hour' is. The tree also tracks its own coverage: any need with no measurable CTQ beneath it yet is named directly, not silently left incomplete.
2 · When to use it
When to use it — and when not to
Use it when
- You have real customer needs — ideally traced to a VOC evidence log or affinity diagram — and want to translate them into something a team can design, build, and measure against.
- You want to know exactly which needs are actually specified and which are still just good intentions with no measurable target.
- You're about to hand a need to engineering, design, or messaging and want it stated as a concrete target, not a vague direction.
Not when
- You don't have a real customer need yet, just a feature idea — start with VOC evidence, not a CTQ tree, or you'll be specifying something nobody asked for.
- You want the raw synthesis of quotes into themes — that's the VOC evidence log or affinity diagram; a CTQ tree assumes the need is already named.
- The 'measurable' target you're about to write is really just a restated aspiration ('better', 'faster', 'easier') — push for a real number or concrete criterion before treating it as a CTQ.
3 · How to fill it in
How to fill it in
- Scope
- Which customer population or segment do these needs come from?
- Needs → drivers → measurable CTQs
- List each need, ideally traced to a specific VOC evidence-log theme or affinity-diagram cluster. Drivers and measurable CTQs get drafted beneath each one — don't fill those in at intake.
- Coverage
- Computed for you: total needs, drivers, and measures, and which needs still have no measurable CTQ beneath them — nothing to enter here.
- Narrative
- Drafted from the tree and any coverage gaps — which needs are well-specified, which still need more VOC work.
- Next steps
- What will you do about a coverage gap or a specific need, ranked by impact and effort, owned and dated? A next step not tied to a named need is a coaching failure mode, not a real action.
4 · What good looks like
What good looks like
The example below translates two evidence-backed needs from the VOC evidence log's onboarding-friction and pricing-confusion themes into concrete drivers and targets, and honestly leaves a third need with no drivers yet — because the evidence for it doesn't exist yet either, which the coverage check names directly instead of hiding.
Same example, as a downloadable xlsx workbook.
Download .xlsxCTQ tree
New-account onboarding — CTQ tree
Dana Whitfield, Product Lead · 2026-03-01
Team: Marcus Lee, Support · Sponsor: Alex Romero, VP Product
Scope
Translates the top two themes from the Q1 onboarding VOC evidence log into measurable requirements, plus one additional need flagged in early discovery but not yet fully evidenced.
Needs → drivers → measurable CTQs
Get up and running without needing IT's help
Evidence: Traced to VOC evidence log's 'Onboarding friction' theme — quotes about SSO setup and team invitations both taking too long.
Self-serve account setup
- Time from signup to first successful login< 30 minutes
- Setup steps requiring IT/admin involvement0 for teams under 10 seats
Clear team invitation flow
- Steps to invite a teammate≤ 2 clicks
Trust that the price I'm quoted is the price I'll pay
Evidence: Traced to VOC evidence log's 'Pricing confusion' theme — quote/invoice mismatch quotes.
Consistent quote-to-invoice matching
- Quote/invoice line-item match rate100%
See the data the way my team actually needs to see itNo CTQ yet
Coverage
Needs
3
Drivers
3
Measures
4
No measurable CTQ yet: See the data the way my team actually needs to see it
Narrative
The two evidence-backed needs are both well-specified: onboarding friction translates into concrete setup-time and invitation-step targets, and pricing confusion translates into a single, clean match-rate target. The third need — seeing data the way the team actually needs to — has no drivers or measures yet, which is an honest reflection of where the evidence currently stands, not a gap in the tree-building itself. It needs its own VOC pass before it can be specified the same way the other two are.
Next steps
Run a dedicated VOC evidence-gathering pass on the reporting-flexibility need before attempting to specify drivers or measures for it.
Linked finding: See the data the way my team actually needs to see it — no measurable CTQ yet
Impact: medium · Effort: medium · Owner: Dana Whitfield · Due: 2026-03-21
Set the setup-time and invitation-step targets as engineering acceptance criteria for the onboarding-flow redesign already underway.
Linked finding: Get up and running without needing IT's help — fully specified with two drivers
Impact: high · Effort: low · Owner: Marcus Lee · Due: 2026-03-14
5 · Common mistakes
Common mistakes
Writing a driver or measure that's really just a restated aspiration.
"High quality support" as a measure has no target and can't be built to — "time to first response, under one hour" can. A CTQ that isn't concrete enough to fail against isn't actually a CTQ.
Treating a coverage gap (a need with no measurable CTQ) as good enough to ship.
A need with no driver or measure beneath it is still just an intention, not a specification — the whole point of this tool is surfacing that gap honestly rather than letting a vague need pass as done.
Writing needs that aren't traced to any real VOC evidence.
A CTQ tree translates real customer needs into specifications — starting from an assumed need rather than evidence risks specifying something with real precision that nobody actually asked for.
6 · What it connects to
What it connects to
upstream
Affinity diagram
A theme with real weight behind it from an affinity-diagramming session is exactly the kind of need this tree exists to translate into something measurable.
downstream
Deal A3
Once a CTQ has a concrete target and the team isn't meeting it, an A3 is where you'd run root cause analysis on the gap.
7 · Where AI helps
Where AI helps
Judgement — stays yours
- Deciding whether a drafted driver or measure is actually right for the need, or reworking it during review
- Deciding which coverage gap to close first
Analysis — AI helps
- Drafting drivers and measurable targets from a stated need and its supporting evidence
- Drafting the narrative from the tree and any coverage gaps
Drudgery — automated
- Counting needs, drivers, and measures across the whole tree
- Identifying which needs still have no measurable CTQ
- Exporting to xlsx in the house format
9 · Rate this kata