When you start centralizing customer feedback in a tool like Productboard, Harvestr, Dovetail, or a homegrown system, one question comes up fast: how do you cleanly classify feedback that isn't all talking about the same thing?

Some verbatims are very concrete:

• an annoyance on a screen;
• a request about a feature;
• a product behavior judged to be bad.

Others are far broader:

• a cross-cutting need;
• a job to be done;
• a business constraint;
• a business stake.

That's often where the trouble starts. The problem isn't just about "organizing" feedback better. The problem is that a single classification model isn't enough.

The trap of classifying along a single axis

Many teams classify their feedback according to a single logic:

• by feature;
• by problem;
• by theme;
• by stake;
• by customer type.

The trouble is that this logic works well for some of the feedback, then goes wobbly for all the rest.

An approach centered solely on features is handy for local annoyances, but it reduces feedback too quickly to pieces of product. You then lose the business logic, the cross-cutting need, or the underlying business objective.

Conversely, an approach centered solely on stakes keeps its altitude, but it turns fuzzy the moment you need to handle a specific problem on a journey, a screen, or an interaction.

In other words:

• a model that's too local lacks perspective;
• a model that's too global lacks precision.

The real need: cover the whole scope without building a Rube Goldberg machine

So the goal isn't to keep piling on more and more categories.

You need to find a framework that is:

• simple to understand;
• fast to use;
• robust enough;
• able to cover feedback ranging from the very strategic to the very tactical.

That's the whole difficulty.

With too few classifications, you mix together things that aren't on the same level. With too many, you make the system painful to use, and therefore poorly adopted.

The right model isn't the most "elegant" one in theory. It's the one a team can actually use over time.

The framework I settle on: 4 classifications

The model I settle on rests on 4 classifications:

1. Business stake
2. Use case / JTBD
3. Product capability
4. Local friction point

The idea is simple: classify feedback by the level at which it's expressed.

1. Business stake

We're dealing with a business stake when the customer expresses:

• a business objective;
• an organizational constraint;
• an operational priority;
• a risk;
• an ambition to transform.

Examples:

• harmonize practices across several teams;
• reduce a compliance risk;
• improve oversight;
• absorb growth without hiring more people.

At this level, the customer isn't yet talking about a specific feature or use. They're talking about what matters for their business.

2. Use case / JTBD

We're dealing with a use case / JTBD when the customer describes what they're trying to accomplish in their work.

Here we're at the level of the business action:

• qualify an incident;
• track a treatment;
• compare several entities;
• retrieve context before acting;
• coordinate several people.

This level is particularly useful, because it helps you understand the real work without locking the analysis into a solution too early.

3. Product capability

We're dealing with a product capability when the customer expresses what the product should make possible.

For example:

• configure alerts;
• manage access rights;
• consolidate a history;
• automate an assignment;
• link several objects or events together.

We're no longer at the level of the business objective, but not yet at the level of a local annoyance either. We're at the level of the capability expected from the product.

4. Local friction point

We're dealing with a local friction point when the feedback concerns something specific in the product:

• a screen;
• a feature;
• a filter;
• a button;
• a form;
• an unexpected behavior.

Examples:

• the filter resets;
• the export button is hard to find;
• a field has to be re-entered;
• a form is too long.

This is the most tactical level, but it remains indispensable. A good insight system must not lose this granularity.

The simple rule for classifying feedback correctly

To avoid hesitation, I hold to a very simple sorting rule.

Is the customer talking about a business objective or an organizational constraint? → Business stake

Are they talking about what they're trying to accomplish in their work? → Use case / JTBD

Are they talking about what the product should make possible? → Product capability

Are they talking about a screen, a feature, a behavior, or a specific annoyance? → Local friction point

This rule has one essential merit: it avoids classifying by the apparent topic, and pushes you to classify by the real level of the signal.

Why this framework strikes me as the right trade-off

This 4-classification model strikes me as more solid than an approach centered solely on features.

Why? Because a piece of customer feedback isn't always about a feature. It can also be about:

• a cross-cutting need;
• a workflow problem;
• an organizational constraint;
• an oversight stake;
• a more strategic expectation.

Conversely, this framework also strikes me as more useful than an approach centered solely on stakes.

Why? Because a good insight management system must also let you get back to the concrete:

• what's blocking in the product;
• what's missing;
• what deserves a local improvement;
• what can directly feed discovery, design, or the backlog.

So this framework holds the balance better between a high vantage point and operational usability.

Conclusion

Classifying all customer feedback along a single axis isn't enough. It works as long as the feedback is homogeneous. But the moment you want to cover business stakes, uses, expected capabilities, and very local frictions all at once, the model becomes too thin.

The 4-classification framework I settle on offers a better trade-off:

• Business stake
• Use case / JTBD
• Product capability
• Local friction point

It stays simple, covers the whole useful scope, and can be used in a real tool without becoming a Rube Goldberg machine.

This is the model I'm going to put in place in my own Insight Manager project. The goal isn't just to organize verbatims better. The goal is to better connect the voice of the customer to product decisions, with a system light enough to actually be used, and structured enough to stay useful over time.

Learn more

The PM as Architect of Context The second brain is a dead end for product management