How to run a Kano model analysis

Most teams run a Kano model analysis for the picture: a scatter plot with features sorted into must-be, performance, attractive, and indifferent. The team prints the chart, picks the two delighters at the top, ships them next quarter, and the renewal rate does not move. The classification was correct. The roadmap that came out of it was wrong. The reason is the same in every team that does this: the chart told them what category each feature falls into and nothing about why participants put it there.

This is a working guide on how to run a Kano model analysis that returns a roadmap instead of a chart. What the model classifies. The three failure modes that fake the result. How to design the questionnaire so participants' answers carry their reasoning with them. And how to read the output with the why attached.

What the Kano model classifies

The Kano model is a feature-prioritization framework, developed by Noriaki Kano in 1984, that classifies features by the relationship between their presence and a customer's satisfaction. Each feature is sorted into one of six categories from a paired question per feature: how the participant would feel if the feature were present (the functional question), and how they would feel if it were absent (the dysfunctional question). The original paper, "Attractive Quality and Must-Be Quality" by Kano, Seraku, Takahashi, and Tsuji, sits in the Journal of the Japanese Society for Quality Control and is older than the SaaS industry it now sits inside.

The six categories:

• Must-be. Features whose presence is unremarkable and whose absence is dealbreaking. Brakes on a car. Login on a SaaS app. The participant does not get a satisfaction lift from having them; they would have churned without them.
• Performance (one-dimensional). Features where more is better in proportion. Battery life. Page load speed. Number of integrations. Satisfaction scales roughly linearly with the level delivered.
• Attractive (delighter). Features whose absence is barely missed and whose presence delivers an out-sized satisfaction spike. The thing that earns the screenshot to a colleague. Most short-term competitive advantages live here.
• Indifferent. Features that do not move satisfaction in either direction. The roadmap items most quietly responsible for shipped but unused work.
• Reverse. Features whose presence actively reduces satisfaction. Common when the team has misread a segment. A power-user feature shipped to a beginner audience often lands here.
• Questionable. Self-contradictory answers (participant likes the feature both present and absent). Usually a sign that the question is unclear or the feature is poorly described.

The model is not opinionated about what you build. It is opinionated about how you treat each category. Must-be features are floors you defend. Performance features compound and you invest behind the curve. Attractive features wear out as the category matures (today's delighter is tomorrow's must-be) and you keep producing new ones. Indifferent features are roadmap noise you delete. Reverse and questionable answers are warnings, not signal.

Why most Kano studies miss the why

Three failure modes show up across most Kano studies that produced a clean chart and a flat quarter. They tend to appear together.

The first is treating the chart as the deliverable. A Kano scatter plot is the start of a synthesis, not the end of one. Two features can both classify as attractive and earn that classification for entirely different reasons in entirely different segments. The chart hides the difference. A team that ships from the chart alone is shipping from a category label, not a reason.

The second is closed answers with no follow-up. The classic Kano questionnaire is closed by design: a five-option scale on each of the functional and dysfunctional questions. That is a feature of the method, not a bug. The bug is when no open follow-up runs after the pair. A participant who selected "I like it" on the functional question and "I dislike it" on the dysfunctional one has just classified a feature as performance. The team has the label. They do not have the participant's reason, the use case, or the comparison to whatever the participant uses today. The classification is a starting point. The chart treats it as the answer.

The third is a single blended sample. Kano averaged across an undifferentiated sample is one of the noisier instruments in product research. Power users and casual users do not put the same feature in the same category. A must-be for the daily user is often an indifferent for the monthly one, and the blended average tells the team to build for a customer who does not exist. The PMF survey has the same trap, and the product-market fit survey playbook covers the parallel failure mode in more detail.

How to run a Kano model analysis, step by step

Seven steps. The order is deliberate. Most teams want to start at step two (the questionnaire). The cost of starting there is a study that gives a clean-looking answer to the wrong question.

01 · Pick the features you actually want classified

A Kano model analysis is most useful when the input is a short, deliberate list of features the team is genuinely deciding between. Twelve to twenty features per study is the working range. Below twelve, you are over-investing relative to a smaller method. Above twenty, the participant's attention collapses around feature eight and the answers in the back half are noise.

The list should mix categories the team expects to land in: a few suspected must-bes (so the calibration is grounded), a few suspected delighters (the bets you actually want to validate), a few performance candidates (where investment level matters), and a few candidate-killers (features being considered but quietly suspected as indifferent). A list composed entirely of bets returns a chart with everything clustered in attractive and tells you nothing.

If your feature list is still loose, run a concept test on the framing first and a Kano study on the survivors. Kano is for choosing between concepts the team has already shaped.

02 · Write the functional and dysfunctional question pair

The classic phrasing, lightly modernized:

• Functional. "How would you feel if [feature, plainly described] were available?"
• Dysfunctional. "How would you feel if [feature, plainly described] were not available?"

Five answer options on each: I like it, I expect it, I am neutral, I can tolerate it, I dislike it. Keep the wording and the order identical across every feature in the study. The participant's pattern is what gets classified; an inconsistent phrasing breaks the pattern.

The feature description is where most studies quietly tilt the result. A marketing-style description ("a brilliant new way to ...") lands the feature in attractive almost regardless of merit, because the participant is reacting to the copy. A plain, mechanical description ("the product automatically sends a weekly summary email at 9am Monday") lands the feature in the category it actually deserves. The same craft applies as in any survey wording, covered in how to write user research questions: describe what the feature does, not what it is for.

03 · Add a self-stated importance question

After the pair, add one short question: "How important is this feature to you, on a scale of 1 to 9?" This is the Mike Timko addition to the classic Kano method, and it does most of the work of separating ties. Two features that both classify as performance often differ in self-stated importance by a factor of two, and the more-important one is the one you build first. Without this question, the Kano output ties more features than it should and the team breaks the tie by gut feel.

04 · Add a voice or text follow-up after every pair

This is the step that turns a Kano study from a chart into a roadmap input. After the importance question, add one open follow-up: "Why did you answer the way you did?" The participant can answer in voice, text, choice, or rating, with voice and text being the natural ones for this question.

The follow-up is where the why lives. A participant who classified a feature as attractive will, in the open follow-up, tell you which workflow it would have changed, which existing workaround it would have replaced, and which week they last hit the problem the feature solves. That sentence is the input you wanted from the study. The five-option grid is the index.

Probing depth on the follow-up is a per-question setting and worth choosing deliberately:

• Shallow. At most one clarifying probe. Reasonable for the indifferent features, where additional depth burns survey fatigue without adding signal.
• Medium. A short chain of probes when the first answer stays vague. The right default for must-be and performance candidates: the participant has a clear opinion and one or two probes unlocks the use case.
• Expert. The model keeps probing until it has the context a senior researcher would dig out. Worth turning on for the suspected delighters: those are the features whose reasoning is most ambiguous and whose roadmap weight is highest.

The mechanics of the depth decision are covered in how AI follow-up questions work in user research. The participant keeps the right to skip on every probe.

"At first I said 'I like it'. But the real reason is that I lost a whole Friday last month to that exact problem and never told anyone. If the product just did that automatically I would not have to remember to do it. I would notice if it went away."

The classification was attractive. The reason was a lost Friday and a private workaround. The team now has not only the category but also the use case to ship around and the language to put in the changelog.

05 · Recruit a representative cohort, segment-first

Kano studies need at least a few dozen participants per segment you intend to read separately. The number is less important than the structure. A study with sixty responses split cleanly into three named segments (twenty each) returns three useful, comparable charts. A study with sixty responses pooled across all customer types returns one chart that describes nobody.

The screener is built against the use case, not the title. "How often do you use [closest existing workflow]" is a screener. "Are you a power user" is not. The first sorts on observable behavior. The second sorts on the participant's flattering self-description. The wider operational treatment is in how to recruit user research participants.

06 · Score the responses against the classification grid

For each participant, for each feature, the functional answer and the dysfunctional answer are crossed against the standard 5x5 Kano classification grid. The cell each pair lands in is the category for that participant on that feature.

Aggregate across the segment. The dominant category (the modal answer across participants in the segment) is the feature's classification for that segment. Self-stated importance scores then break ties between features in the same category.

A useful sanity check before trusting the output: count the questionable answers. If a feature is producing more than five percent questionable responses, the feature is poorly described and the classification on that row is not trustworthy.

07 · Read the result with the why attached

The deliverable is not the chart. It is a small table: feature, segment, classification, average importance, two or three verbatim quotes from the follow-up that explain why. Every row carries its own justification.

This is where the analysis pays off relative to a static survey. The must-be features are defended with the use case the team can no longer ship without. The performance features are invested in with a clear understanding of which dimension the participant is paying attention to. The delighters are built with the use case from the probed follow-up, not a marketing guess about why the participant said "I like it". The indifferent features get cut, with the participant's own words attached so the team that proposed them has a clear answer to "why not".

The synthesis is the same shape as any structured qualitative pass: themes, quotes, sentiment, citations back to the original answer. Output that arrives this way is also agent-ready, so a weekly digest, a Slack alert when a delighter starts trending toward must-be, or whatever the team builds next can read it without anyone re-keying a spreadsheet. The general pattern is in how to synthesize user research.

Run it as a standing instrument, not a one-off survey

A Kano study run once is a snapshot. The category for a given feature drifts over time. Today's delighter is tomorrow's must-be, an effect Noriaki Kano himself documented as attractive-quality decay. A team that classified a feature as attractive eighteen months ago and uses that classification today is building for a customer who has moved on.

The fix is to stop treating the Kano analysis as a campaign with a send date. The same survey link belongs in the places a product team already collects feedback: a persistent link inside the app, the post-onboarding email when a fresh cohort hits activation, the cancel-confirmation page for participants who just left. Each placement runs the same instrument on a different population, and the synthesis pipeline rolls them up into a refresh of the same table. The wider pattern is in how to build a customer feedback loop.

The same instrument also runs internally. Before a contested roadmap decision goes to customers, share the Kano link in engineering, design, support, sales, and finance. Each function classifies the feature list from their own perspective; the synthesized view shows where stakeholder opinion diverges sharply from the customer signal and where it agrees. The internal cohort is not a substitute for the external one. It is a cheap pre-launch sanity check that catches the deal-killer engineering or support would have raised in a meeting nobody scheduled.

When the Kano model bends

Three cases where the Kano model returns a clean chart and the chart is misleading.

Pre-problem features. If the participant does not have the problem the feature solves, the question is hypothetical and the classification drifts toward indifferent or attractive depending on the participant's mood. The fix is upstream: discover the problem first, then run Kano on solution candidates.

Features that require behavior change. A feature that asks the participant to do something differently (adopt a new workflow, learn a new vocabulary, change a habit) often classifies as attractive in the survey and as indifferent in shipped usage. The Kano answer captures intent; the behavior captures reality. A jobs-to-be-done interview on people who actually switched is the better instrument for these.

Genuinely new categories. Kano works against a reference point the participant already has. If the feature is the first of its kind, the participant has nothing to compare it to and the answers cluster in questionable. Concept testing on the framing, then Kano on the survivors, is the right sequence.

How Kano relates to PMF, JTBD, and concept testing

Each of these methods answers a different question at a different stage of the build:

• Concept testing sits earliest, before the feature has been shaped. It asks whether the framing lands and the demand exists.
• The Kano model analysis sits next, on the surviving concepts. It classifies how each feature contributes to customer satisfaction and ranks them inside their category.
• Jobs-to-be-done interviews sit after the build has shipped, on customers who already switched. They answer why the switch happened.
• The product-market fit survey sits later still, post-revenue. It measures the disappointment a real customer would feel at losing the product.

The four sit inside the wider practice covered in the voice user research guide. The shorthand: concept testing finds the right concepts to invest in, Kano sorts what to build inside the chosen concept, JTBD explains the switches that already happened, PMF measures the fit you built.

FAQ

What is the Kano model?

The Kano model is a feature-prioritization framework, developed by Noriaki Kano in 1984, that classifies a product feature by how its presence and absence affect customer satisfaction. Each feature is sorted into one of six categories: must-be, performance, attractive, indifferent, reverse, and questionable. The classification is produced from a paired survey question per feature, one functional and one dysfunctional. The model is widely used by product teams to choose between candidate features and to plan roadmap investment across the categories.

How many participants do I need for a Kano study?

At least a few dozen per segment you intend to read separately, with a structural floor of about twenty per segment for the dominant category to be stable. The total sample matters less than the segmentation: sixty responses pooled across five customer types returns a single noisy chart, while sixty split into three named segments of twenty returns three useful comparable ones. Below twenty per segment, one or two unusual answers can move the modal classification on their own.

What are the six Kano feature categories?

Must-be (presence unremarkable, absence dealbreaking), performance or one-dimensional (satisfaction scales with the level delivered), attractive or delighter (presence is an out-sized lift, absence is barely noticed), indifferent (neither presence nor absence moves satisfaction), reverse (presence reduces satisfaction, often a segment-mismatch warning), and questionable (self-contradictory answers, usually a sign that the question or feature description is unclear).

How often should I re-run a Kano model analysis?

Continuously, not as a one-off. Kano categories drift over time. Today's delighter is next year's must-be, an effect Noriaki Kano himself documented as attractive-quality decay. A study run eighteen months ago describes a market that no longer exists. The cleanest cadence is a standing trigger: a link that fires when a fresh cohort hits activation, or a routine refresh that runs each quarter on a new sample, with the table updated in place rather than replaced.

What is the difference between the Kano model and MoSCoW?

MoSCoW classifies features by team-side priority (must, should, could, won't). The Kano model classifies features by the relationship between presence and customer satisfaction. The two are not interchangeable: MoSCoW is a decision artifact (the team sorts the backlog), Kano is a research artifact (the customer sorts the features). A team can run a Kano study and use the output as input to a MoSCoW prioritization. The reverse does not work: MoSCoW does not produce the customer-satisfaction signal Kano measures.

---

Run the Kano study so the participant's reasoning travels with the answer and the team's deliverable becomes a table with verbatim quotes attached, not a chart with cluster labels. Talkful is built to run surveys of exactly this shape: a study link goes out, participants answer the functional and dysfunctional pair on the input mode they prefer, the AI interviewer probes the open follow-up into the use case underneath, and the synthesis engine returns the table the team can ship from. Ship with evidence, not vibes.