You find recurring problems by breaking each piece of feedback into individual claims, then grouping those claims by the problem they describe rather than the words they use. Most teams tag feedback against a preset list of categories instead, which finds the problems they already expected and misses the ones they didn't.

Everyone agrees on the goal. Read the feedback, find what keeps coming up, fix the things that come up most. The disagreement is entirely about method, and the method you choose decides which problems you are capable of finding.

The standard approach — the one nearly every guide describes — is thematic tagging: build a set of categories, label each piece of feedback against them, then count. It works, up to a point. The point where it stops working is exactly where the valuable problems live.

What's wrong with tagging feedback into themes?

Nothing, as far as it goes. Thematic analysis is a legitimate, well-documented research method — NN/G's overview is a good primer on doing it properly. The problem is not the method. It is what happens when you apply it to a live, growing feedback stream instead of a fixed research dataset.

Three things break at scale.

Preset categories can only find problems you anticipated. A tag is a label from a list, and the list was written by someone predicting what would come up. When a genuinely new problem starts recurring, it has no tag, so it gets filed under "other" or split across three loosely related tags and never surfaces as a single thing. The method is structurally blind to the unexpected, which is the category of problem you most need to catch early.

Different taggers split the same problem. Whoever labels the feedback chooses from the list, and two people faced with the same complaint will reasonably choose different tags. Now one problem lives under two labels and neither looks big enough to act on. This is the affinity-mapping issue that qualitative researchers know well — grouping is subjective, and consistency across people is hard — except in a support queue it happens continuously and nobody is checking.

The unit is wrong before you even start. Most feedback contains more than one claim. A single conversation might report a bug, describe a workflow problem, and ask for an integration. Tag it as one thing and you have thrown away the other two. Whatever you tagged, the record was never a clean unit to begin with.

None of these are fixable by tagging more carefully. They are properties of tagging itself.

What's the difference between a theme and a pattern?

A theme is a category you applied. A pattern is a problem you discovered. The distinction sounds subtle and decides everything about what you can find.

When you tag feedback into themes, you start from the categories and sort feedback into them. The themes exist before the feedback does. When you construct patterns, you start from the feedback and let the groupings emerge from what is actually there — which means a pattern can name a problem you had no word for when you started.

This is the same distinction between feedback, requests, and patterns covered in what's the difference between feedback, a feature request, and a pattern. The short version: a pattern is a claim that a specific problem recurs across specific accounts, and nobody can hand it to you pre-formed. It has to be built from the raw feedback, bottom-up.

The practical test for which one you have: if a brand-new kind of problem appeared in your feedback next week, would your system show it to you, or would it disappear into "other"? Themes fail that test. Patterns are designed for it.

How do you actually find the patterns?

Three steps, and the order matters more than the tooling.

Step one: split before you group. Break each piece of feedback into its individual claims first. One conversation becomes zero, one, or four separate claims, each about a single thing. This is the step tagging skips, and skipping it is why tagged data groups badly — you cannot cleanly group records that each contain several unrelated problems. Group the claims, not the conversations.

Step two: group by meaning, not by words. "Dispatchers can't reassign a route mid-shift" and "we end up calling drivers directly when plans change" are the same problem in different vocabulary. A human doing affinity mapping would put them together; keyword search and tags will not, because they share no terms. Doing this automatically means comparing what claims mean, not what words they contain. In Lane this runs on hybrid retrieval — lexical search for exact terms like error codes and competitor names, combined with vector search for meaning — because either one alone leaves a visible class of misses. Meaning-only grouping misses exact-term matches; word-only grouping misses everything phrased differently.

Step three: decide explicitly in the ambiguous middle. Some claims obviously belong together and some obviously don't. The interesting ones sit in between. A workable approach treats the confident matches automatically — above a high similarity threshold, a claim joins an existing pattern directly — and routes the ambiguous middle to a slower, more careful judgment about whether it genuinely fits or should start a new pattern. Below the threshold, it seeds something new. Most of the real work is in that middle band, and it is exactly the part a simple clustering script gets wrong.

What you get at the end is not a tag count. It is a set of problems, each carrying the distinct accounts affected, the revenue behind them, whether the problem is growing, and the verbatim feedback underneath. That is the input a decision can actually use.

How do you know a pattern is real and not noise?

By what it carries, not by how many mentions it has.

Raw frequency is a weak signal on its own. Ten mentions from ten trial accounts and three mentions from three enterprise accounts approaching renewal are not the same finding, and a count treats them identically. A real pattern is legible along several dimensions at once: how many distinct accounts, what they pay, how fast it is accelerating, and whether the underlying claims actually describe the same problem when you read them.

That last check matters most and gets skipped most. A grouping algorithm will happily assemble a cluster that shares vocabulary but not meaning — everything mentioning "export," for instance, regardless of whether the problem is speed, format, or permissions. The guard against it is keeping the verbatim evidence attached, so any grouping can be read back and confirmed rather than trusted blindly. A pattern you cannot open and inspect is a pattern you cannot defend.

There is a specific failure to watch for when models do the summarising: fabricated specifics. A summary of a cluster will sometimes introduce an account name, a number, or a detail that was in none of the source feedback. It reads convincingly and is wrong. Anyone building this should be testing for it directly, because a confident fabrication is more dangerous than an obvious gap.

Once you've found a pattern, then what?

Finding it is not deciding on it, and the two get conflated constantly.

A confirmed pattern tells you a problem is real and recurring. It does not tell you the problem is worth solving, worth solving now, or worth solving by you — that is a prioritisation question that strategy answers, not the feedback. The mechanics of turning a confirmed pattern into a defensible product decision are covered in how customer feedback becomes a product decision.

The one thing worth doing immediately is closing the loop. When a pattern leads to something shipped, the customers whose feedback formed it should hear about it, in the channel they originally used. This is the step that keeps feedback flowing, and it is the first one teams drop when busy.

Tagging vs. pattern-finding, compared

When this doesn't apply

If your feedback volume is low enough that one person reads all of it, you don't need any of this. A human reading everything is the best pattern-finder there is, and formalising the process adds overhead without adding insight. This starts to matter at the volume where nobody can hold it all in their head anymore.

If your feedback is already highly structured — fixed-choice survey responses, numeric ratings — then counting is the right tool and pattern construction is overkill. This approach is for unstructured feedback: the open text in tickets, calls, and messages, where the problem is buried in the wording.

And tagging is not worthless. For a stable, well-understood product where the categories genuinely are known and rarely change, thematic tagging is faster and perfectly adequate. The case for pattern-finding gets stronger the more your product is changing and the more of your important problems you haven't thought of yet.

Frequently asked questions

1. Isn't this just automated tagging? No, and the difference is the direction. Tagging sorts feedback into categories that already exist. Pattern-finding builds the groupings from the feedback itself, so it can produce a group you had no category for. Automating a preset taxonomy is still bound by the taxonomy; this isn't.

2. Can I do this without AI? Yes, by hand, using affinity mapping — physically grouping individual observations until problems emerge. It works well and does not scale. The manual method is the right one at low volume; automation matters when the feedback outgrows what a person can sort in a reasonable time.

3. How is a pattern different from just the most-mentioned tag? Mention count measures who talks, not who is affected or what it costs. A pattern carries the accounts, the revenue, and the trend alongside the count, so a small fast-growing problem in high-value accounts is visible as more urgent than a large flat one in trial accounts. The raw tally hides that.

4. What feedback sources does this work on? Any unstructured text: support tickets, sales and success call transcripts, in-app messages, reviews, churn notes. The one rule for transcripts is to extract only the customer's side, or you record your own team's guesses as customer problems.

5. How many pieces of feedback do you need before a pattern is trustworthy? There is no fixed number, because trust comes from the weight behind a pattern, not the count. Three enterprise accounts describing the same blocker is a stronger pattern than twenty trial users mentioning a minor annoyance. Read the evidence rather than the total.

Lane finds these patterns for you: it splits feedback into individual claims, groups them by meaning, and shows you each recurring problem with the accounts and revenue behind it — bottom-up, not from a preset list of tags.