How to apply the Kano model to feature requests

What the Kano model measures

The Kano model sorts product features by how they change customer satisfaction. Some features are expected, so their absence hurts and their presence goes unnoticed. Others add satisfaction the more you provide. A few delight people who never asked for them. Knowing which kind a request is changes how much effort it deserves.

Noriaki Kano and his colleagues proposed the model in the 1980s. Teams still use it because it forces a question that a raw count of requests skips: what does the customer feel when this exists, and when it does not?

The five categories

Category	What it means	Typical feedback wording
Basic	Customers expect it. Missing it causes frustration. Having it earns little praise.	"I expected this to be there"
Performance	More is better. Satisfaction rises with each improvement.	"Could it be faster?" or "I need more columns"
Delighter	Nobody asked for it, but people are pleased when it appears.	Rare in requests, more often found in praise
Indifferent	Customers do not care either way.	"It would be nice, I guess"
Reverse	Some customers want the opposite of what you built.	"Stop forcing me through the tour"

Basic needs are the easiest to miss in planning, because they never show up as a request. Customers only mention them when they are absent.

Ask the functional and dysfunctional question

The classic Kano survey asks two questions about each feature: how would you feel if it existed, and how would you feel if it did not? The answers place the feature in a category.

Escuta Produto has no surveys, so you rarely get clean answers in a form. You infer the category from what customers wrote. Read each request and ask two questions of your own:

1. If we ship this, does the complaint disappear, or does the customer just feel less annoyed?
2. If we do not ship it, does the customer leave, or do they find a workaround?

A complaint that disappears when the feature exists points to a basic need. A customer who leaves without it points to a basic need as well, and the stronger case is the one where the absence drives churn.

Classify requests from your feedback

Work through the idea items in the inbox. For each request, write the category in an internal note, for example "Kano: basic" followed by one line of reasoning. Notes are private, so your team sees the call without customers seeing it.

Start with the requests that repeat, because repeats show what most customers expect. Then read the praise items for delighter hints. A sentence like "I did not expect this to be included" points to one.

A customer who writes "the export is missing the due date column" describes a basic expectation. A customer who asks "could the reports load in under a second" wants a performance improvement. Both are useful, but they deserve different responses.

Use the categories to order the roadmap

Ship basics first, because a missing basic can cost you customers. Then order performance work by how much each improvement gives people who asked. Delighters are a bonus, so schedule them after the basics and the performance items that matter most. Skip indifferent requests unless they are cheap to build.

Reverse requests usually point to a setting, not a removal. If some customers dislike a tour or a prompt, offer a way to turn it off rather than deleting it for everyone.

Where the Kano model breaks down

The model describes how satisfaction changes. It does not tell you how many people want something. A basic need requested by one customer can still be a basic need, and a delighter can be expensive to build. Combine Kano with reach and effort, as in the RICE approach to feedback.

Categories also move. A performance feature becomes a basic need once customers come to expect it, and a delighter becomes a basic need once it is common. Re-label the top requests once a year.

Free-text feedback is a weak substitute for the paired questions the model was built on. Treat each label as a working hypothesis and confirm it with a few direct conversations before a large build.

Add a Kano label to your Escuta Produto triage

Escuta Produto gives you statuses (new, planned, in progress, done and closed), a type for each item (bug, idea, praise or other) and private internal notes. It has no tags, so the Kano label lives in the note.

1. Filter the product inbox to type idea and status new.
2. Read each request, then write the category and one reason in the internal note.
3. Move the requests you will build to planned, and close the ones you decided against with a note that explains why.
4. Add an entry point that opens the idea form directly. The widget accepts data-escuta-open="idea" on any element, so the requests you collect arrive typed as ideas. Setup details are in the widget docs.

For the next step after labeling, read how to find the problem behind a feature request. For the whole path from requests to a plan, see how to turn customer feedback into a roadmap.