Kano Model

For a long time, deciding which feature to build first ran on a single ruler. Build it well and users like it; build it poorly and they don't. On that ruler every feature has the same nature. Raise the quality and satisfaction rises, lower it and satisfaction falls.

Real reactions did not stay on that ruler. Take autosave in a document tool. No matter how well it runs, nobody praises a product for it. Lose someone's work once, though, and they delete the account that day. The satisfaction side of this feature is pinned near zero while only the dissatisfaction side drops through the floor. Other features have the opposite nature. A pasted link that turns itself into the document's title draws no complaint when it is missing, but the first person to see it happen screenshots the screen and sends it to a colleague. Here the dissatisfaction side sits at zero and only the satisfaction side spikes. One feature is judged by how badly it fails and the other by how well it lands, which is not a difference of degree.

Measured on one ruler these two are indistinguishable, and prioritization meetings kept jamming at the same place because of it. Ask users whether they would like to have a feature and all twenty candidates come back above 70 percent. Of course they would all be nice to have. Walk into the meeting with that table and there is nothing to order the list by. The numbers are fine-grained and still nobody knows what can be dropped. When Pagedeck ran that question across twenty candidates, the lowest score was 68 percent and the highest was 91 percent, a spread too narrow to cut anything on.

Quality researchers in Japan split the ruler in two in the early 1980s. The reaction to something being present and the reaction to it being absent are not two ends of one axis but two separate questions. So each feature gets asked about twice: how would you feel if this were there, and how would you feel if it were not. Pair the two answers and candidates that were indistinguishable a moment ago separate by nature.

Prioritization holds several frames for ordering work, and most of them line up candidates that already exist by score. The Kano model's place is before that. Ahead of any lining up, it separates the candidates whose absence breaks the product from the ones that are a pleasant surprise and the ones nobody cares about either way.

The terms under the Kano model form a single group: the five quality types the model sorts features into. The first three carry most of the work and the last two are used for filtering things out.

1. Must-be quality — present and nobody notices, absent and it becomes a complaint. Autosave, staying logged in, and sending a payment receipt belong here. However well it is built, it cannot lift satisfaction above zero, and when it is missing it cancels out everything else by itself. It also has the property of not surfacing when you ask. It is too obvious to be written down on a request list, and instead arrives as a flood of support tickets the day it breaks. Autosave had never once appeared in Pagedeck's feature requests and produced 40 tickets in a single afternoon when it failed.
2. One-dimensional quality — the better it is, the more satisfaction rises in proportion. It is also called performance quality. How fast a document opens, how accurate the search results are, how much storage the free plan gives: anything with a scale on it lands here. It is the only type where the investment and the satisfaction connect in a straight line, which also makes it easy to put side by side with a competitor's numbers. A straight line means a small improvement buys a small gain, so spending only here rarely changes how the product feels.
3. Attractive quality — nobody misses it when it is gone, and people are delighted when it is there. Pasting a link and having it turn into the document title, or a meeting note that pulls out just the decisions and summarizes them, sit here. The satisfaction curve is the steepest of the five, and because nobody was expecting anything in that spot, no request ever names it. People cannot ask for what they did not imagine, so this type comes out of observation and ideas rather than a survey.
4. Indifferent quality — present or absent, satisfaction does not move. Expanding the theme colors to twelve, or detail items on a settings screen nobody opens, belong here. Finding this type is half the practical value of running the model at all. Seven or eight out of twenty candidates landing here is common, and clearing them out buys time for the candidates that remain.
5. Reverse quality — the better it is provided, the more dissatisfaction grows. A feature that notifies people of every activity, or a well-meant auto-tidy that scrambles an order the user arranged on purpose. It shows up most when the user base splits. When the same feature is attractive quality to one group and reverse quality to another, which side the default is set for becomes the decision.

Judging the type takes four steps.

1. Pick the candidate features and write each as one sentence. Vague sentences scatter the answers, so write "show me only the notifications where I was mentioned" rather than "improve notifications."
2. Build two questions per feature: how it would be if it were there, and how it would be if it were not. Answers come from a fixed set of five — I like it, I expect it, I'm neutral, I can live with it, I dislike it.
3. Collect the answers with a survey. Ten features make twenty questions, so six or seven features is the practical ceiling for one round. A sample of around 100 people is usually enough for the types to separate.
4. Pair the two answers on a table and read off the type. Like it when present and neutral when absent reads as attractive quality; expect it when present and dislike it when absent reads as must-be quality. Respondents land on different types, so a feature takes whichever type came back most often, and when first and second place sit a few percentage points apart, read that as the user base splitting and run the groups separately. A feature that came back 44 percent attractive and 41 percent indifferent is not weakly attractive; it is two different audiences answering in the same column.

The types that come out are not the order itself; they are the material for setting an order. How teams use them is mostly the same. Fill in every must-be quality first to build the floor, choose where to compete with one-dimensional quality, and lay one or two attractive qualities on top with whatever capacity is left. Indifferent quality comes off this quarter's list, and reverse quality gets its default turned off or moved to an option. The proportions matter as much as the order: a quarter spent entirely on the floor buys no new reason for anyone to switch to the product, and a quarter spent entirely on top of a cracked floor buys none either.

Types also do not hold still, and that belongs in the same view. Attractive quality settles over time into one-dimensional quality and then into must-be quality. A few years ago several people editing one document at once drew admiration; now its absence knocks a product out of consideration. That is why running an old survey result against the same candidate list goes wrong. In a fast-moving market, teams ask again about once a year.

"This is attractive quality, so nobody complains without it. Let's fill in the must-be items and put this on top afterward."

A proposal to push the feature back, since its absence won't drive anyone away.

"Half the respondents marked it indifferent. Let's take it off this quarter's list."

There's now evidence that building it wouldn't move satisfaction, so it comes off the list.

"It was attractive three years ago and it's expected now. Our competitors all have it."

A note that the same feature's type has settled downward, so it's a baseline condition rather than a differentiator.

This came up at Pagedeck in the meeting where twelve candidates for the next quarter were being ordered. Sofia wanted twenty document templates at the front of the list, saying they drew the most customer requests, while Theo held that faster search had to come first. Each was holding a different ruler, request counts against engineering strain, and an hour in they had not moved closer.

Mia picked six candidates and put two questions each to 120 users. What separated them in the results was not the request count. Templates came back marked indifferent by a majority of respondents, and automatic recovery, which nobody had ever requested, came back as must-be quality. Two of the six cancellations from the previous quarter had in fact cited work lost mid-edit. The team took templates off the list and put automatic recovery at the front, and since search speed was one-dimensional quality, drew a line at a 40 percent reduction for the quarter. What ended the meeting was not a new opinion; it was that two people ended up holding the same ruler.

The most common mistake is believing more attractive quality makes a better product. Its satisfaction curve is the steepest and it reads well in a pitch deck, so the pull that way is natural. The five types do not add up, though. One empty must-be quality is a loss that three attractive qualities cannot cover. A product with several delightful features where saving occasionally fails is not a great product with a shame attached; for users it is a product they cannot rely on. Filling the floor first and laying things on top afterward is the order worth keeping. The cost of skipping it shows up in cancellations rather than in the satisfaction survey, which is why it usually goes unnoticed for a quarter or two.

The second is believing the model hands back a priority order directly. The word model is in the name and the survey produces numbers, so an order looks like it should come out of it too. What this frame answers is one thing only: how this feature acts on satisfaction. It does not ask how many months it takes to build, how many people will use it, or how much revenue it brings. When two features both judged must-be quality sit side by side and one takes three days while the other takes half a year, that order has to be settled outside this model. In practice teams layer it, filtering candidates by type first and then lining up what remains with a scoring frame such as RICE, which multiplies reach, impact, and confidence and divides the result by effort. Execute the list off the types alone and a quarter disappears into one half-year must-be item with nothing visible to show for it.