What's the difference between feedback, a feature request, and a pattern?

Feedback is what a customer said. A feature request is the solution they proposed. A pattern is a problem you have confirmed recurs across multiple accounts. Only the third is evidence for a decision. Most teams treat all three as the same object, which is why their roadmaps are built on request counts.

The three words get used interchangeably in most product conversations, and the cost of that is invisible until you try to justify a decision. "We're building this because it's highly requested" and "we're building this because the same problem is blocking four accounts" sound similar in a meeting. They are not the same claim, and only one survives scrutiny.

The distinction is not academic. It determines what you can store, what you can group, and what you can defend.

What counts as feedback?

Feedback is an event. Someone said something, at a point in time, through some channel, and they belong to an account you can identify.

That last part matters more than the content. Feedback without account context is nearly unusable later, because every downstream judgment depends on who was affected. A complaint from a trialling team and the same complaint from a customer renewing in six weeks are different inputs, and once you have lost the attachment you cannot reconstruct it.

Feedback is also messy by nature. A single support conversation might contain a bug report, a workflow frustration, and an offhand wish for an integration. This is why feedback is a poor unit to work with directly — it is one record containing several unrelated claims, and any label you apply to the record applies to all of them.

The practical rule: capture feedback verbatim, attach the account, and do not try to categorise it at this stage. Categorisation at capture time is where most systems quietly lose information.

What makes something a feature request?

A feature request is a customer proposing a solution.

"Add bulk editing" is a feature request. "I have to update forty records one at a time every Monday" is not — that is a problem description. The difference is that one names an implementation and the other names a situation.

This distinction is the most consequential one in the whole vocabulary, because a feature request is the customer doing your job for you. They have observed their own problem, designed a solution, and handed you the solution instead of the problem. If you build what they asked for, you have inherited their design, which was produced without knowing your architecture, your other customers, or the five better ways the same problem could be addressed.

Requests are still valuable. They are an honest signal that something hurts enough to prompt a suggestion. But they should be treated as a customer's hypothesis, not as a requirement — and the useful work is recovering the problem underneath.

There is a practical consequence. If your system stores requests as its primary unit, you can only ever count them. Counting requests ranks solutions by popularity, which is a different exercise from ranking problems by severity, and it systematically favours the customers who are most comfortable telling you what to build.

When does a group of requests become a pattern?

A pattern is a claim that a specific problem recurs across specific accounts. It is the only one of the three that nobody can submit to you.

That is the defining property. Feedback arrives. Requests arrive. Patterns have to be constructed, because no single customer can observe one — they only see their own experience. A pattern exists across accounts, which means only you are positioned to see it, and only if your system is built to find it.

This is also why voting boards cannot produce patterns. Tools like Canny are genuinely good at what they do: they give customers a visible place to submit and upvote, which creates transparency and reduces duplicate support load. But a vote count aggregates what people explicitly submitted, in the words they chose. Two customers describing the same underlying problem in different vocabulary will file two separate items and split their own vote. The board is working correctly and still cannot see the pattern.

Constructing patterns reliably takes three things:

Split before you group. Each piece of feedback is broken into its individual claims first. We call these insights internally, and the term is worth having because it names the unit everything downstream operates on. One conversation might yield four insights or none. Group at the record level instead and you are grouping a mixed bag.

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. Keyword search will never join them and tags will not either, since the two people who logged them chose different tags. In Lane this runs on hybrid retrieval — lexical search for exact terms like error codes and competitor names, vector search for meaning, results fused together. Either method alone leaves a visible class of misses.

Decide explicitly in the ambiguous middle. Not every candidate match deserves the same handling. Above roughly 0.9 similarity, a new insight attaches to an existing pattern directly. Between roughly 0.6 and 0.9, the top candidates go to a model that decides which one genuinely fits, or whether none do. Below that, it starts a new pattern. All the judgment lives in that middle band, and it is the part pure clustering handles worst.

Once grouped, a pattern carries what no individual request can: how many distinct accounts, what they pay, whether it is accelerating, and the verbatim evidence behind each claim. The mechanics of how patterns then become decisions are covered in how customer feedback becomes a product decision.

Why does the distinction matter in practice?

Because each one answers a different question, and substituting one for another produces a specific, predictable failure.

Using feedback as your working unit means you cannot group anything cleanly, since each record contains multiple unrelated claims. You end up with tags that are true of part of a record and false of the rest.

Using requests as your working unit means you rank solutions rather than problems. The loudest, most articulate, most engaged customers set the roadmap — not because anyone decided that, but because request volume is a measure of who talks, not of who is affected.

Using patterns as your working unit means you can say something defensible: this problem, these accounts, this much revenue, this trend, this evidence. It is the only one of the three that stands up when someone asks why.

There is a second-order effect worth naming. When teams treat requests as decision input, customers learn that the way to get something built is to ask loudly and often. That is a bad incentive to create, and it degrades the honesty of your input over time.

What about bugs, complaints, and churn reasons?

They are feedback, and they contain insights, and they can form patterns. The vocabulary holds.

A bug report is feedback containing a defect claim rather than a problem claim. It routes differently — straight to engineering rather than through prioritisation — but if the same bug is reported by nine accounts, that is still a pattern, and it should be visible as one.

A complaint with no request attached is often the most valuable input you get, precisely because the customer has not pre-solved it for you. "This is frustrating and I don't know what you'd do about it" preserves the problem intact.

Churn reasons are feedback with the highest available weighting and the worst timing. They belong in the same system as everything else, and the common mistake is keeping them in a separate spreadsheet owned by customer success, where they never join up with the patterns they confirm.

Internal requests from sales or support are a different case. They are usually a compressed summary of several customer conversations, which makes them useful but secondhand. Worth capturing, worth marking as internal, and not worth weighting equally with what a customer said in their own words.

The three objects, compared

When this doesn't apply

If you have a small number of customers and speak to all of them, you hold the patterns in your head already and the vocabulary adds ceremony without adding clarity. The distinction starts paying off at the point where no one person reads everything.

If you sell a product with one dominant customer, the request-versus-pattern distinction partially collapses. When one account represents most of your revenue, their request is the pattern, and pretending otherwise is a way of avoiding an uncomfortable commercial fact.

And the vocabulary does not settle prioritisation. Knowing that something is a pattern rather than a request tells you the problem is real. It does not tell you the problem is worth solving, or worth solving now, or worth solving by you. Strategy still constrains the ranking, and no amount of well-structured evidence removes the need to decide.

Frequently asked questions

1. Is a feature request a kind of feedback?
Yes. Feedback is the container; a feature request is one thing a piece of feedback can contain. The reason to name them separately is that requests carry a proposed solution, and solutions need to be unpacked back into the problem before they are useful for deciding anything.

2. Can one piece of feedback belong to two patterns?
It should be able to. A message saying the app is slow and the export is broken describes two distinct problems, and forcing it into one category discards half of it. This requires grouping at the level of individual claims rather than at the level of the whole record.

3. How is a pattern different from a tag or a theme?
A tag is applied by a person from a list that already exists, so it can only describe categories you anticipated. A pattern is constructed from what is actually in the feedback, which means it can surface a problem you had no label for. Themes sit in between, depending on how they are produced.

4. Do I need software to do this?
Not initially. The distinction is a discipline before it is a system, and a shared document with problems rather than requests as headings will take a small team a long way. Software becomes necessary at the volume where manual grouping stops being possible and starts being aspirational.

5. What if a customer insists on their specific solution?
Record the request verbatim, and separately record the problem behind it. You may well end up building what they asked for. The point is not to overrule customers — it is to make sure the decision was made with the problem visible, so that if a better solution exists you had the chance to see it.

Lane is built on this distinction: feedback stays verbatim, the claims inside it get extracted, and the patterns across them become what you decide from.