Kano model (and how to use it in a 2026 PM interview)

The Kano model is a classification tool, not a scoring formula. Noriaki Kano published “Attractive Quality and Must-Be Quality” in 1984 at Tokyo Rika University to explain why some features delight users while others only reduce dissatisfaction. In an interview, it earns points when you use it to reason through a tradeoff, not when you recite the taxonomy.

The five categories

Must-be (basic): Features users never notice when working but immediately notice when broken. Authentication, data save, core navigation. Must-bes do not generate satisfaction when present; they generate active churn when absent. These are the viability floor: without them, the product does not survive.

Performance (one-dimensional): Features where more is better and users can feel the gradient. Load time, search relevance, storage limit. These drive retention and willingness to pay.

Attractive (delighter): Features users did not know to ask for. When present, satisfaction spikes; when absent, no dissatisfaction. This is where lovable moments live.

Indifferent: Features that produce no meaningful satisfaction change either way. Cut these from the roadmap until proven otherwise.

Reverse: Features that actively reduce satisfaction when present. Aggressive AI suggestions sent without user review, forced onboarding interruptions, AI rewrites that destroy a user’s voice. In 2026, reverse features appear most often in AI assistants that optimize for engagement over user control.

How the survey works

Kano uses paired functional and dysfunctional questions per feature. Functional: “If this feature is present, how do you feel?” Dysfunctional: “If this feature is absent, how do you feel?” Each question gets five responses: like it, expect it, neutral, can live with it, dislike it. Mapping the two answers against each other places the feature in a category. You need 15 to 30 representative users to get stable signal. This is the discovery method, not the interview answer.

Worked tradeoff

You have a fixed block of engineering capacity. Two candidates: (A) fixing a flaky authentication flow and (B) adding AI-powered smart compose.

A is a must-be regression. B is an attractive feature. The Kano rule is immediate: fix A first, regardless of how high the delight ceiling is on B. Must-be failures drive active churn; a missing delighter produces zero dissatisfaction. If you ship B while A is broken, you are optimizing for retention of users who are already leaving.

strong

"I'd use Kano to classify the two features. The authentication issue is a must-be regression: users expect it to work and when it doesn't, they leave. Smart compose is attractive: delightful if present, zero dissatisfaction if absent. Kano's rule is that you never ship a delighter with an unresolved must-be regression. Authentication goes first, every time. I'd also flag that smart compose needs explicit user review before acting. AI features that send or modify without confirmation routinely score as reverse features for privacy-sensitive segments."

weak

"Smart compose would really delight users, so I'd prioritize it. The login issue we can handle in a patch." This inverts the asymmetry: dissatisfaction from broken basics damages trust faster than delight from new features can rebuild it. Calling a must-be regression a "patch item" signals the candidate does not understand the model at all.

Category migration is the real skill

Features move: delighters become performance expectations become must-bes. This happens faster in AI products than anywhere else.

Dark mode was a delighter in 2018, a performance feature in 2020, and a must-be across productivity apps by 2022. AI grammar assist followed a similar arc in three years rather than five. AI-generated meeting summaries (Otter, Notion AI, Zoom AI Companion) moved from attractive in 2023 to near-must-be for knowledge worker tools by 2026. If you call AI meeting summaries a “delighter” in an interview this year, the interviewer registers it as a signal that your mental model is behind.

In 2026, AI feasibility is effectively free for a wide class of features. Summarization, smart reply, and intent-aware search are API calls away. This collapses the delighter-to-must-be timeline from years to months. The 2026 Kano job is not just classifying features: it is forecasting migration velocity so your roadmap reflects where user expectations will be when the feature ships, not where they were when you scoped it.

Features that have already crossed the must-be line for most knowledge worker products: inline AI editing, meeting transcription and summary, search that understands intent. Features still in delighter territory: multi-step agentic tasks completed without user review, proactive surfacing of information the user did not know to ask for.

Cross-segment divergence

The same feature can hold different Kano positions across segments. Slack’s AI-generated channel summaries were an attractive feature for SMB users in 2024. For enterprise IT buyers, the same feature triggered compliance review: data handling, retention policy, and model training opt-outs became must-be requirements before adoption was even on the table. One feature, two Kano positions, by segment.

In an interview, this signals senior thinking. Name the segment explicitly, assign the Kano category per segment, and note that the build or configuration requirements differ.

What Kano does not do

Kano classifies features by satisfaction impact; it does not estimate effort or size the opportunity. The correct interview sequence: classify with Kano, size with an effort estimate, apply the rule (never defer a must-be regression for a delighter), then make the call. Reach for RICE when you need to rank a longer list by expected impact per unit of effort. The two work together: Kano sets priority order by category; RICE ranks within categories.