The AI Kano Model Analyst skill for Claude

The problem the skill solves is probably one you recognise from your own roadmap meetings. Everything on the list feels important, because someone has a good story attached to it. The feature the team is proudest of turns out to be invisible to the customer. The feature the customer simply expects gets a round of applause once it finally works. And somewhere near the bottom sits something that eats up capacity without anyone being able to explain what it delivers. The Kano model sets an ordering against that which follows from a single insight: satisfaction is not a linear function of features. Some functions deliver nothing when they are there and a great deal of damage when they are missing. Others do exactly the opposite.

This file is written for product and marketing teams, founders who have to choose their MVP scope, and anyone sitting with a list of functions who has to decide what comes first. The typical occasions the file itself names are: choosing between features, MVP scope discussions, roadmap planning, setting up a customer survey and formulating the question pair. It belongs with the AI and automation service, where we actually set up this kind of working method for businesses.

Kano organises stated preference responses; it does not itself prove realised satisfaction, conversion, revenue or retention. The file therefore makes no promise that an attractive feature causes growth. Its classifications or hypotheses can inform a roadmap, while business value, cost and feasibility require separate evidence.

Must Be, the basic features. Customers expect it to be there. Presence earns no satisfaction, absence causes strong dissatisfaction. The example in the skill is clean bedding in a hotel: an illustration of an expected basic condition, not a prediction of a particular review. The consequence for your roadmap is counterintuitive: prioritise validated expectations, then assess reliability, accessibility, safety and other requirements before deciding whether to invest further.

One Dimensional, the performance features. The conceptual model associates better fulfilment with greater satisfaction, not a measured straight-line relationship. Specify direction for speed, battery life or price; a higher price is not automatically better. Choosing two or three is a focus convention. A linear satisfaction sketch says nothing about the cost of each improvement.

Attractive, the wow features. Customers do not expect it. The feature can delight respondents, while loyalty remains a separate outcome to measure. The example from the file is the handwritten note included with an online order. The rule the skill attaches to it is sharp: consider one or two at a time as a scope convention, but estimate actual cost and complexity; attractive does not mean cheap.

Indifferent, the neutral features. The customer does not care either way. Whether it is there or not makes no difference. These are often internal features the team is proud of but which the customer never sees. Consider deferral or removal only after checking other segments and operational, accessibility or mandatory dependencies. Survey indifference does not measure wasted capacity.

Reverse, the reverse features. Presence leads to dissatisfaction. Too many notifications, too many onboarding steps, functions that mainly get in the way. Actively remove them or make them switchable per segment, because what one group experiences as Reverse can be a wow feature for another.

There is a sixth outcome, and it is not a category: Q for Questionable. It appears when the two answers contradict each other. The skill is not allowed to make anything of that either. It asks the question again or marks the feature as undetermined, and that is a result, not a problem.

These are shortened hypotheses from the worked example, not measured customer findings. The table preserves a distinction between a proposed category and the decision to develop, defer or investigate an item.

After that comes the framework itself: the five categories with an example for each, and the dynamic principle Kano Drift as a separate part. Only then comes the method, and it counts seven steps. Step 1 is drawing up or asking for the feature list. Step 2 is gathering the context: who is the customer, which segment, which phase of the product lifecycle, which competitors. Step 3 is the question pair, which the skill calls the functional pair: the functional question, how you feel if the feature is there, and the dysfunctional question, how you feel if it is not. Both questions use the same five categorical response options, not numerical ratings to average.

Step 4 maps each complete answer pair to a table category; missing answers are not guessed. Hypothetical pairs remain hypotheses. Step 5 separates the category from a proposed roadmap action. Step 6 asks for evidence of possible drift over a two-year planning window, leaving dates unknown when unsupported. Step 7 proposes five time-bound actions subject to validation and other constraints.

Classify each respondent’s complete pair before reporting category counts by feature and segment. Show ambiguity, Q, missing responses and Reverse outcomes explicitly. The Better/Worse extension is contributed by Mike Timko in Berger and colleagues (1993). With D = A + O + M + I, Better = (A + O) / D and Worse = -(O + M) / D. A positive dissatisfaction magnitude may be shown only if labelled as such. When D is zero, both are undefined; R and Q are excluded from D but reported separately. These are response summaries, not predicted satisfaction percentages.

The output structure is also fixed, in five parts: a context summary of three to five lines, the classification table with the functional and dysfunctional answer per feature, the category, the development action and the drift, then the priority per category, then the Kano Drift warning and finally the five actions with a timeline. The file closes with seven refusals, five limits of the model and five sources. Want to learn to write a file like that yourself, then writing SKILL.md NL explains that structure step by step.

Without survey responses, the skill may propose hypothetical pairs from sufficient context, with HYPOTHESIS stated in every affected row. It must separate supplied facts from assumptions and validation questions. A tidy table does not turn those estimates into respondent data or prove that a model followed the instructions at runtime.

The method comes from Noriaki Kano. Together with Seraku, Takahashi and Tsuji, he published the paper Attractive Quality and Must-be Quality in 1984, in the Journal of the Japanese Society for Quality Control. That is the source of the core idea: quality is not a single scale. There is quality you must have, quality you can get better at, and quality that surprises. That distinction sounds obvious until you have a roadmap in front of you where all three are mixed together.

The evaluation table comes from Berger and colleagues. The 1993 compendium presents the paired questions, categorical options and evaluation table used here. The Better/Worse coefficient extension is contributed by Mike Timko; it uses a signed dissatisfaction coefficient, with a clearly labelled magnitude as an alternative. This is why the instruction says you read off the category rather than interpret it: the translation from answers to category is fixed, not left to the analyst.

The application in product development comes from Sauerwein, Bailom, Matzler and Hinterhuber. Their 1996 paper The Kano Model: How to Delight Your Customers describes how to put the model to use in practice, and Matzler and Hinterhuber linked it to Quality Function Deployment in Technovation in 1998. That is where the emphasis on what you do with the outcome comes from, so the development action per category rather than just a label.

The criticism comes from Witell and Löfgren. Classification of Quality Attributes, from 2007, deals with the weak points and the reliability of the method, and it says something that a skill wanting to use the model includes its own critic in its list of sources. That criticism reappears in the limits further down: the model measures stated preference and not behaviour, and small samples give a false sense of certainty.

Even without installing the skill, you can use these principles to clean up your own list: ask both questions per feature, see where the two answers take you, and dare to write down what you are not going to build. If you put the model next to other prioritisation methods, the RICE Prioritisation skill is the logical second look, because it works with reach and effort where Kano only looks at satisfaction.

After that, using it is simple: paste your feature list and describe who you are building for, what phase you are in and what competitors offer as standard. Those four pieces of context are not a formality, because the skill refuses to analyse while they are missing. If you have real survey data, supply it as answer pairs per respondent: then the skill counts the categories and takes the most frequent one instead of estimating. The knowledge base has the broader explanation of working with AI.

There are also situations where you are better off leaving it aside. For a general strengths and weaknesses analysis or generic prioritisation this is the wrong instrument, and the file says so itself in the frontmatter. For the market side you are better off starting with the SWOT Analysis skill, and for the question of whether the business model around it holds up, the Business Model Canvas Coach skill.

It also states five limits of the model itself, and they are more honest than you would expect from an instruction file. The model measures stated preference, not behaviour. What people say about a feature that does not exist yet often differs from what they do once it is there. The categories are snapshots. According to the file, Kano Drift is not a footnote but the model's most important limitation. Delighters are hard to ask about directly, because a customer cannot long for something they cannot imagine: fill that side in with observation and with complaints about the current way of working.

The model says nothing about cost, feasibility, technical dependencies or legal obligations, so always set the outcome against those separately. And small samples give a false sense of certainty: twenty is not a universal validity threshold. Report sample size, recruitment, segments, distributions and uncertainty; size alone does not establish representativeness.

That last limit deserves a warning the skill already gives itself but which easily gets lost in the tidy table. If you work without respondents, the output states that it is an estimate. Take that sentence seriously. An estimated category is a structured assumption, not a measurement, and the table around it does not make it any more valid. Want to test the assumptions under your product with real customers first, then the MOM Test Coach skill was made for exactly that: it helps formulate questions about concrete customer experience without guaranteeing truthful answers.

You can build the perfect features and still stay invisible. If your product is barely found, that is a problem for the roadmap, not after it. The free SEO scan shows in a few seconds where your site stands. And if you want to talk further about what AI can do for your business beyond this, from individual skills to full automation, we simply do that in a conversation.