Methodology
The Kano Model sorts customer requirements into categories so you know which ones protect you and which ones delight. This guide walks through one fictional delivery case from survey input to a finished classification, then sets out what the tool will not tell you.
The Kano Model answers a question that most improvement teams get wrong at the start. Not all customer requirements behave the same way. Some earn you nothing when you deliver them, but cost you dearly when you fail. Others earn you goodwill when present, and cost you nothing when absent. If you treat every requirement as equal, you spend effort in the wrong place.
In Ci Flow the Kano Model sits in the Define phase of RDMAICS. That is deliberate. Define is where you turn a vague problem into a scoped set of customer requirements. Kano gives those requirements a shape. It tells you which ones form the floor of acceptable service and which ones sit above it.
The tool supports two ways of working. You can run a quick facilitated classification, where a team agrees a category for each requirement in a workshop. Or you can calculate Kano categories from paired customer survey responses, where each respondent answers how they would feel if a feature were present and how they would feel if it were absent. The second route is slower and firmer. This guide uses the second route.
The example used throughout this guide is fictional. It comes from the sample data that loads with the tool, and no real company, product or person is involved.
Picture a food delivery service. The team has two candidate requirements on the table. The first is live driver tracking, a map that shows where the driver is between pickup and door. The second is an accurate order, meaning the customer receives the items they actually ordered.
The team has an argument running. One group wants to invest in tracking, because customers mention it often and competitors show it. Another group wants to fix order accuracy, because complaints keep arriving. Both sides can point to customer comments. Neither side can point to structure. That is the gap Kano fills.
So the team runs a short paired survey. Ten respondents. Each respondent answers for one requirement, with a functional answer and a dysfunctional answer. Each respondent is also tagged by segment, either Frequent or Occasional, so the team can look at behaviour differences later.
The input table is deliberately plain. One row per respondent per requirement. You fill in a respondent identifier, the requirement being assessed, the segment, the answer if the feature is present, and the answer if the feature is absent. The tool then returns a result for that single row.
The answer options follow the standard Kano scale. Like, Must-be, Neutral, Live with, Dislike. The pairing matters more than either answer alone. Like plus Neutral is a very different signal from Like plus Dislike, even though the first half of each pair is identical.
In the sample data, respondent R01 answers Like if present and Neutral if absent for live driver tracking. The tool marks that row Attractive. Respondent R02 answers Like if present and Dislike if absent for the same requirement. That row comes back Performance. Respondent R04 answers Neutral if present and Dislike if absent, which the tool marks Must-be. The same feature produces three different categories depending on how the customer reacts to its absence.
Order accuracy behaves differently. Five respondents cover it, from R05 to R09, and every one of them answers Dislike if absent. Their present-case answers vary. R05 and R07 say Must-be, R06 and R09 say Neutral, R08 says Live with. All five rows return Must-be. The present-case answer barely moves the result once the absence reaction is strong.
The result view aggregates the rows into one line per requirement. Live driver tracking shows 5 responses and a category of Attractive. Accurate order shows 5 responses and a category of Must-be.
Two numbers sit beside each category. Satisfaction potential tells you how much satisfaction you gain by delivering the requirement well. Dissatisfaction if absent tells you how much you lose by failing it. Live driver tracking scores 80% satisfaction potential and -40% dissatisfaction if absent. Accurate order scores 0% satisfaction potential and -100% dissatisfaction if absent.
Read those two lines together and the argument resolves. Accurate order cannot make anybody happy. At 0% satisfaction potential, getting it right buys you nothing. At -100% dissatisfaction if absent, getting it wrong costs you everything. It is the floor. Live driver tracking is the opposite shape. It can lift satisfaction, and its absence hurts less.
The final column shows the vote spread as M / O / A / I / R / Q. Live driver tracking reads 1 / 1 / 3 / 0 / 0 / 0, which is one Must-be, one Performance, three Attractive. Accurate order reads 5 / 0 / 0 / 0 / 0 / 0. That second spread is unanimous. The first is not. A three to two split on five responses is a thin majority, and the tool shows you that rather than hiding it behind a single label.
The satisfaction curve chart plots both requirements against degree of functionality. The tool also offers an AI review that explains the result in words, which is useful when you need to hand the output to someone who did not sit in the survey design.
The first decision is sequencing. A Must-be requirement gets fixed before an Attractive one gets built. Order accuracy at -100% dissatisfaction if absent is not a project you schedule after the tracking map ships. It is the condition of being in business at all.
The second decision is how you set targets. For a Must-be requirement, the target is conformance. You are chasing the absence of failure, and there is no upside past that point. For an Attractive requirement, the target is reach and quality of experience, because the 80% satisfaction potential is only realised if the feature actually works well.
The third decision is what you measure in the next phase. Must-be requirements point you towards defect rates and failure counts. Attractive requirements point you towards adoption and preference measures. Classifying requirements in Define saves you from building the wrong measurement system in Measure.
The fourth is segmentation. The sample tags respondents Frequent or Occasional. With only ten rows there is nothing conclusive to say about segment differences, but the field is there so that a real study can test whether the categories hold across groups.
The most common mistake is asking only the present-case question. Teams write a survey that asks whether customers would like a feature. Almost everybody says yes. Without the absence question there is no category, only enthusiasm. The sample data shows why. Three respondents answered Like if present for live driver tracking, and their rows split across Attractive and Performance based purely on the absence answer.
The second mistake is leading the question. If you describe a feature in glowing terms, you push respondents towards Like. The functional and dysfunctional wording should be neutral and symmetrical.
The third mistake is reading a thin majority as a settled fact. Live driver tracking returned Attractive on a 3 of 5 vote. That is a direction, not a verdict. The honest reading is that the requirement leans Attractive and needs more respondents before anyone commits budget to it.
The fourth is forgetting that categories move over time. A feature that is Attractive today becomes expected tomorrow, and eventually becomes Must-be. Kano is a snapshot. Date your results.
The Kano Model will not tell you what a requirement costs to deliver. Nothing in the sample output speaks to effort, build time, or operational load. A requirement at 80% satisfaction potential may be cheap or it may be ruinous. You have to bring that information from somewhere else and weigh it against the category yourself.
It will not validate your sample. Ten rows across two requirements is a demonstration, not research. The tool reports what you entered. It does not warn you that five responses per requirement is too few, and it does not know whether your respondents resemble your customers. Sampling quality remains entirely your responsibility.
It will not tell you whether you asked about the right requirements. Kano classifies the list you bring. If the real driver of customer loss is something nobody put in the survey, the output will look clean and point you nowhere useful. Pair the tool with open voice of customer work before you build the question set.
It will not predict behaviour. A category describes stated feeling about presence and absence. It does not forecast whether customers will switch providers, pay more, or order more often. The -100% dissatisfaction figure for accurate order is a measure of how respondents said they would feel. It is not a churn rate.
It will not make the trade-off call for you. Two requirements, two categories, two very different shapes. The tool lays out the shapes clearly. Deciding how much of your capacity goes to protecting the floor and how much goes to raising the ceiling is a judgement, and the Kano Model gives you a better basis for that judgement rather than removing the need to make it.
RDMAICS, A3, Just Do It and Kaizen projects with the full Lean Six Sigma toolset, AI interpretation and tollgate presentations built from your real evidence.
5S Workplace Design converts a confirmed root cause into five concrete future-state actions with owners and dates. This guide walks through the tool's built-in sample case and shows how to size the gain before you commit to the change.
Read the article
Batch-Size Optimisation takes a diagnosed cause and turns it into a change you can pilot with a number attached. This guide walks through the tool's built-in sample data, from four candidate batch sizes to a single recommended answer.
Read the article
Setup Reduction / SMED takes a diagnosed cause and turns it into a change you can test. This guide walks through the tool's built-in sample data, task by task, and shows how to read the result before you spend anything.
Read the article