The Kano Model for App Teams: Must-Haves, Delighters and Votes

A vote count tells you how many people want something. It does not tell you what kind of want it is. Some features are expected: nobody thanks you for them, but everyone leaves when they break. Others are a pleasant surprise that nobody would have asked for. The Kano model gives you a way to tell them apart, and that changes what you build and when.

This guide explains the model, the survey behind it, and a worked example with Trailmate, a fictional hiking app. It is one of the approaches in the overview of prioritisation frameworks.

The short version

• Kano sorts features by how their presence and absence affect satisfaction: must-be, performance, attractive, indifferent and reverse.
• You find the category with two questions per feature: how would you feel if it were there, and how would you feel if it were not?
• Fix must-be gaps before anything else, invest steadily in performance features, and pick a few attractive ones to stand out.
• Votes and comments tell you which requests to survey, and revenue tells you whose answers to weigh.

Where the model comes from

Noriaki Kano and his colleagues Nobuhiko Seraku, Fumio Takahashi and Shin-ichi Tsuji described the model in 1984 in Attractive quality and must-be quality, in the Journal of the Japanese Society for Quality Control. The core idea is that satisfaction is not a single line from bad to good. Doing more of some things makes people happier. Doing more of other things just stops them being unhappy.

The categories

The survey

For each feature, ask two questions. The functional question: "If Trailmate had offline maps, how would you feel?" The dysfunctional question: "If Trailmate did not have offline maps, how would you feel?" Each has the same five answers: I like it, I expect it, I am neutral, I can live with it, I dislike it.

The pair of answers gives the category. The standard evaluation table, with the functional answer down the side and the dysfunctional answer across the top:

"Questionable" means the person contradicted themselves, usually because they misread the question. Leave those answers out.

A worked example

Trailmate surveyed 40 users about its five open requests. Each cell is the number of respondents whose pair of answers fell into that category. No answers came back Reverse or Questionable.

The category is the most common answer. When two are close, as with trail notes, look closer before deciding.

Satisfaction coefficients

Charles Berger and colleagues, in a 1993 issue of the Center for Quality of Management Journal devoted to Kano's methods, proposed two coefficients that make the table easier to compare. Better = (Attractive + Performance) ÷ total, and shows how much building the feature can lift satisfaction. Worse = (Performance + Must-be) ÷ total, shown as a negative, and shows how much leaving it out hurts.

Reading it

• Offline maps is a must-be. Building it will not make anyone love Trailmate, but its absence hurts more than anything else on the list. For a hiking app, it is the cost of being taken seriously.
• The difficulty filter is a performance feature: high on both coefficients. Each improvement to filtering pays back.
• The elevation profile is attractive, with the highest Better score and a low Worse score. It is a good candidate for the feature people mention when they recommend the app.
• Share a hike is mostly indifferent. A quarter of respondents found it attractive, which is worth noting, but it is not a priority.
• Trail notes is split between attractive and indifferent. That usually means two different groups of users.

What votes and revenue add

Votes tell you what to survey

Nobody fills in a Kano survey about fifty features. Votes narrow the list to the requests people actually care about. They also hint at the category before you ask. Must-be gaps collect votes fast because people are blocked, and the comments say so: "I cannot use this on the trail without it". Attractive ideas collect votes too, but their comments sound different: "this would be lovely". Reading the comments on a request is a quick, rough Kano pass.

Revenue tells you whose answers to weigh

Split the survey answers by whether the respondent pays. Trail notes is the clearest case. Of its 15 attractive answers, 11 came from free users, which matches its low revenue per voter. Among paying users it is indifferent. That turns a split result into a decision: trail notes might help convert free users later, but it does nothing for the customers paying today.

The reverse check matters just as much. A must-be gap among paying users is a cancellation risk. Offline maps has $4,120 of monthly recurring revenue (MRR) behind it, and most of the paying respondents in the survey answered must-be for it. That is the strongest argument on the page for building it next, whatever its RICE score says about effort.

Categories move over time

Today's delight is next year's expectation. Dark mode was once a pleasant surprise in an app, and many users now expect it. Trailmate's already-built dark map style collected 212 votes, mostly from free users, which is what an attractive feature becoming expected tends to look like. Re-run the survey every year or so, and watch whether the comments on a request change tone from "would be nice" to "why is this missing".

Common mistakes

• Building delighters on a broken base. No attractive feature makes up for a missing must-be.
• Surveying too many features. Keep it to the requests with the most votes, five to ten at a time.
• Mixing segments. Hikers who go off-grid and casual walkers will answer differently. Split by segment and by plan.
• Treating Kano as a ranking. It tells you the kind of value. Combine it with effort, using MoSCoW for a release or the impact/effort matrix for the backlog.

How FeedbackKit fits in

FeedbackKit does not run surveys, so the Kano questionnaire itself happens in whatever survey tool you already use. What FeedbackKit gives you is the evidence around it. Users vote and comment on requests inside your app, through the Swift SDK on Apple platforms and, since 8 February, SDKs for Kotlin, Flutter and React Native. A new request starts with its submitter's vote, and voting stops when a request reaches Completed or Rejected. The comments are where you read the tone that hints at a category.

On every plan, your app passes each user's MRR through the SDK, and requests can be sorted by the total MRR of the users behind them in the native admin apps for iPhone, iPad and Mac. That is how you see whether a request's voters are paying customers or free users before you decide whose survey answers carry the most weight. Plans are on the pricing page.

Here is how that looks in FeedbackKit, with sample data from a fictional hiking app:

Votes tell you what people want, Kano tells you what kind of want it is, and revenue tells you whose wants keep the lights on. To collect the votes and the revenue inside your own app, start free.