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.

There is one thing you should know beforehand. Kano predicts satisfaction, not revenue and not conversion. So it explicitly makes no promise that a wow feature leads to growth or retention. What you get back is an ordering of your list and a reasoned recommendation on sequence, nothing more. That is less than a business case and a great deal more than a vote.

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: nobody praises you for it, but if it is missing the review is devastating. The consequence for your roadmap is counterintuitive: you build these features first, up to the level the customer expects, and not a step further. Investing extra in a Must Be earns no extra satisfaction.

One Dimensional, the performance features. Satisfaction rises in a straight line with how fully the feature is present. More is better. Think of load time, battery life or price. This is the category where you can really win, and that is exactly why the skill advises picking two or three of them and not eight. Linear also means: every step costs just as much as the one before it.

Attractive, the wow features. Customers do not expect it. Presence creates strong positive emotion and loyalty, absence is not a problem. The example from the file is the handwritten note included with an online order. The rule the skill attaches to it is sharp: one or two at a time, kept small, because they are cheap in scope and expensive in attention.

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. According to the file, this is the category where most capacity quietly disappears, and the advice is correspondingly simple: cut it or park it.

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.

In diff form, with lines from the skill's own example: how a roadmap statement changes once it comes from the table instead of from the meeting room.

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 answers go on the same five point scale.

Step 4 is the most important, and the instruction there is worded strikingly strictly: combine the two answers in Berger's 1993 evaluation table and read off the category. You do not interpret it yourself, you read it off. Step 5 determines the effect on customer satisfaction, the priority and the development action per feature. Step 6 checks for Kano Drift, with the concrete question of whether this feature shifts to another category over the next two years. Step 7 delivers a roadmap with five concrete actions with a timeline, including what you are actively cutting.

The table itself appears in full in the file, and you see it again in FIG.03 below. There is also an instruction for multiple respondents: count per feature how often each category comes up and take the most frequent one, and if it is close, say that there is no clear category. Optionally, if there are enough respondents, the skill may calculate Berger's two coefficients. The satisfaction coefficient is A plus O divided by A plus O plus M plus I, and the dissatisfaction coefficient is O plus M divided by the same denominator. The closer to 1, the stronger the effect.

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.

One more detail worth mentioning, because it is exactly the kind of rule most AI answers leave out: if you have no real survey data, the skill estimates the answers based on the customer context you give it, and states explicitly that it is an estimate and not a measurement. So it does act without research, but it never calls it anything other than what it is.

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. Their 1993 paper Kano's Methods for Understanding Customer-defined Quality supplied the method this skill takes over word for word: the question pair, the five point scale and the cross table from FIG.03. The two coefficients come from there too. 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: under around twenty respondents per segment, you are talking about signals, not categories.

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 teaches you to ask questions people cannot politely lie their way around.

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.