Kano Model

What it is

A model, developed by Noriaki Kano together with Nobuhiku Seraku, Fumio Takahashi, and Shinichi Tsuji, and published as "Attractive Quality and Must-Be Quality," Journal of the Japanese Society for Quality Control, 14(2) (1984), pp. 39–48, that classifies product features by how they affect customer satisfaction, rather than by how much effort they take to build. It sorts features into five categories: Must-be (basic expectations that cause dissatisfaction if missing but generate no delight if present, such as a login that works), Performance (features where more is simply better and satisfaction rises linearly with how well they are delivered, such as sync speed), Delighters (unexpected features that create disproportionate satisfaction precisely because customers did not expect them, such as a support agent solving a problem before the customer noticed it), Indifferent (features customers do not care about either way), and Reverse (features that actively reduce satisfaction for some customers, such as added complexity a simplicity-focused segment does not want). The insight that makes Kano useful for PMM is that these categories are not fixed: a delighter today (fast sync) becomes a must-be tomorrow, once competitors match it. Kano gives PMM a shared vocabulary with product for a question roadmap debates usually argue past each other on: not "is this feature good?" but "which of these five effects does it have on satisfaction, and does our launch messaging match that effect?"

When to use it

• Launch messaging is leading with the wrong feature. A team about to headline a launch with a must-be feature (something customers assume is already there) will underwhelm; Kano flags that the headline should be the delighter instead.
• The roadmap is a flat list with no sense of which items move satisfaction and which just remove complaints. Kano forces a distinction between fixing dissatisfaction (must-be) and creating advocacy (delighters), which are different jobs with different payoffs.
• A packaging or Good-Better-Best tier decision needs to decide which features are baseline versus premium. Must-be features belong in every tier; delighters are strong candidates for a premium tier precisely because their absence is not felt as a loss.
• NPS or churn feedback keeps citing missing basics that the team assumed were "solved" years ago. This is the clearest sign a feature has quietly moved from delighter or performance into must-be territory, and needs re-prioritising as a retention risk, not a nice-to-have.
• Competitive parity is eroding a delighter's impact. If competitors have shipped an equivalent to a feature that used to differentiate you, Kano gives PMM the language to flag it as reclassified, and route messaging and roadmap attention accordingly.

Ownership

At a scaled company with a specialised PMM team, the Head of Product Marketing owns running the survey, the segmentation, and translating the classification into launch messaging, while final decision rights on which features actually get built or resourced sit with the VP Product or Head of Product, since Kano output is an input to roadmap prioritisation, not a roadmap in itself. The two functions should agree the feature list together before the survey goes out, so the classification answers a question product actually needs answered. At a solo or founding-PMM stage, the founding PMM typically runs the survey and shares the results directly with the founder or whoever holds the product decision, since there is no separate product organisation to hand it to.

How to apply it

1. List the candidate features. Gather the roadmap items, recent releases, or a mix of both that need classifying, typically 10 to 20 at a time so a survey stays a manageable length for respondents.
2. Write a paired question for each feature. For every feature, ask two versions of the same question: a functional form ("How would you feel if this feature were present?") and a dysfunctional form ("How would you feel if this feature were absent?"), each answered on a five-point scale from "I like it" to "I dislike it".
3. Survey a representative sample of the target segment. Aim for at least 30 to 50 responses per segment if the finding needs to hold up for a launch or roadmap decision; fewer than that produces a directional read only.
4. Cross-tabulate the paired answers using the standard Kano evaluation table. Plot each respondent's functional and dysfunctional answers against the standard Kano scoring grid, which maps every combination of the two answers to one of the five categories (Must-be, Performance, Delighter, Indifferent, Reverse, plus a Questionable category for internally inconsistent answers that should be discarded or re-asked). Most survey platforms with a Kano template automate this step.
5. Classify each feature by its most common category across respondents. A feature is not always unanimous; report the category the plurality of respondents landed on, and note if a meaningful segment (for example, power users versus new users) classified it differently, since that split is itself a useful finding for segmented messaging.
6. Translate the classification into roadmap and messaging decisions. Must-be features get resourced defensively (fix gaps fast, do not headline them). Performance features get resourced proportionally to their measured impact on satisfaction. Delighters get protected from being cut for schedule pressure and get the launch headline. Indifferent features get deprioritised unless they unlock a must-be or performance feature. Reverse features get flagged to the segment they harm, sometimes meaning they should be optional or hidden behind a setting rather than removed outright for everyone.
7. Re-run the exercise periodically, not once. Kano categories drift as the market and competitors move; a feature classified 18 months ago should not be assumed to still hold the same classification, particularly for anything that started as a delighter.