Main idea

A customer feedback taxonomy degrades from both sides. Too few categories and you file together things that aren't on the same level: a screen friction and a growth stake end up in the same bin, and the bin no longer means anything. Too many categories and classifying becomes work in itself: the person entering a verbatim after an interview hesitates, puts it off, then stops entering anything.

The second failure is the more expensive one, because it doesn't show in the model. On paper, the fine-grained taxonomy is better: it distinguishes more, it loses less. In use, it is empty.

The deciding criterion is therefore not the theoretical completeness of the breakdown but what a team actually sustains over time — after six months, once the novelty has passed and nobody is watching the entries. A framework is good when it is still being filled in at that point.

Why it matters

This changes who decides. Conceived as a modelling problem, the taxonomy is designed alone, cold; conceived as an adoption problem, it is tested on real verbatims with the people who will do the entering — support, customer success, sales.

And it gives a reason to stop adding. Faced with a piece of feedback that fits badly, the reflex is to create the missing category; deciding on adoption forces you to set against it the cost of using that extra category.

Nuances and limits

Adoption isn't the only criterion: a framework trivial to fill in but unable to distinguish two levels of decision is adopted and useless. The constraint is a floor — covering the whole spectrum of feedback — below which simplicity buys nothing.

The threshold also depends on who does the entering. A team of dedicated analysts tolerates a granularity that a field team entering things between two meetings will not.

Open questions

• How do you assess the adoption of a classification framework before having deployed it?