Begin with evidence units, not feature requests
A support ticket, call excerpt, review, or churn note is an observation. It may contain a requested solution, but the durable signal is the underlying problem, who experienced it, when it happened, and what consequence followed. Normalize those facts before clustering.
Retain the source reference, account, segment, timestamp, channel, and exact excerpt your team is permitted to use. Mark missing commercial context as missing; do not convert absence into a zero.
Themes are hypotheses
A theme is a claim that several observations describe the same underlying need. That claim should stay open to correction. Review outliers, duplicated conversations, and unusually influential accounts before relying on the count.
Good theme review asks: can a reviewer open the source? Are contradictory signals visible? Did one copied complaint appear in several systems? What would cause this cluster to split?
Use a decision frame, not one magic score
Revenue exposure is important for B2B teams, but it is not the whole roadmap. Pair it with affected users, urgency, strategic fit, confidence in the evidence, implementation risk, and obligations that should not be priced like optional features.
A ranking should explain its inputs and allow an accountable person to override it with a recorded reason. The override is not a model failure; it is part of governance.
Carry the evidence forward
When a theme becomes a requirement, copy neither a vague summary nor a list of quotes. State the problem, include representative evidence, document the chosen outcome, label assumptions, and list what is intentionally out of scope.
The result is a decision record. Engineering can understand why the work matters, product can revisit the tradeoff, and customer-facing teams can close the loop without inventing a story after the fact.