Kano Model for Product Managers

What is the Kano model

The Kano model is a framework for classifying features by how they move customer satisfaction, not by how they move revenue or effort. It was developed by Noriaki Kano in 1980s Japan while studying why some quality improvements delighted Toyota customers and others were invisible. The core insight: the relationship between feature investment and user satisfaction is not linear, and not the same shape for every feature.

Most PMs walk into roadmap meetings armed with RICE scores and a vague sense that "users want this." Kano gives you a sharper question: would users notice if this feature got worse, and would they notice if it got better? That asymmetry is what separates a delighter from a table-stakes hygiene fix.

On PM interviews at companies like Google, Meta, Stripe, and Airbnb, Kano shows up less than RICE but more than candidates expect. A senior PM is expected to explain the difference between a must-be and a delighter without hand-waving, and to know when not to reach for the framework.

The five feature categories

Kano splits every candidate feature into one of five categories. Memorize these — the rest of the model is mechanics on top.

Must-be (basic expectations)

Without these, the product is unusable or unacceptable. Their presence is taken for granted; their absence triggers immediate complaints. A login that actually authenticates. A checkout that processes the card. An inbox that doesn't lose mail. Users will not write a thank-you note when your password reset works — they will write an angry support ticket when it doesn't.

The investment trap with must-be features is over-investment past the threshold. Once your login works 99.9% of the time, going to 99.99% rarely shows up in satisfaction metrics. The ceiling is hard and low.

Performance (one-dimensional)

More is better, linearly. Satisfaction scales roughly proportionally with feature quality. Page load speed is the canonical example: 200 ms is better than 500 ms, and 50 ms is better still. Storage quota, battery life, search relevance, video resolution — all performance attributes.

These are the features where competitive benchmarking earns its keep. If your competitor offers 2× the free tier storage at the same price, performance category says you will lose customers at the margin until you close the gap.

Attractive (delighters)

Features users did not expect, would not have asked for, and love when they appear. A handwritten note in a Notion onboarding email. A free dessert with a DoorDash order. Their absence does not disappoint, because no one was looking for them. Their presence creates loyalty and screenshots in group chats.

The catch: delighters decay. Free shipping was a delighter in 2005, performance by 2015, and a must-be by 2020 once Amazon Prime trained the market.

Indifferent

Features users do not notice and do not care about, in either direction. A backend refactor that does not change perceived performance. A new color theme nobody opens. A feature flag for an A/B test that never ships. Building these is not neutral — it is a direct opportunity cost against the other four categories.

Reverse

Features that actively harm satisfaction for a segment of users. Push notifications for the minimalism crowd. AI summaries inserted at the top of emails for users who wanted to read the original. Aggressive autoplay video. Reverse features are dangerous because the team that built them usually loves them, which makes the survey data essential.

The Kano survey

To classify a feature with data rather than vibes, ask each respondent two questions per feature — the functional pair and the dysfunctional pair. This dual-question structure is what makes Kano different from a NPS-style "do you want this?" survey.

Functional question: "How would you feel if the product had feature X?" Dysfunctional question: "How would you feel if the product did NOT have feature X?"

Both questions use the same five-point answer scale:

1. I like it
2. I expect it
3. I am neutral
4. I can live with it
5. I dislike it

The combination of the two answers determines the category. The asymmetry between how a user reacts to having it and how they react to losing it is the entire signal. A feature where users say "I like it" both with and without is suspicious — that is the Questionable zone, usually a sign of a confusing question rather than a real category.

Scoring the results

The category for each respondent comes from the Kano evaluation matrix. Read functional answer down the left, dysfunctional answer across the top:

Legend: M = Must-be, O = Performance (One-dimensional), A = Attractive/Delighter, I = Indifferent, R = Reverse, Q = Questionable.

The dominant category across respondents wins. If your survey gives 62% Must-be, 18% Indifferent, 12% Performance, 8% other, that feature is a must-be — full stop. Where it gets interesting is split distributions: 45% Attractive, 40% Indifferent means you have two distinct segments and you need to slice by user type before you decide anything.

For each feature you can also compute two satisfaction coefficients to compare across the backlog:

Better coefficient = (A + O) / (A + O + M + I)
Worse coefficient  = -(O + M) / (A + O + M + I)

A feature with Better = 0.8 and Worse = -0.2 is a clear delighter candidate. Better = 0.3 and Worse = -0.7 is a must-be — invest defensively, do not expect upside.

Worked example: a marketplace backlog

Imagine you are a PM on a Linear-style B2B marketplace and you have four candidate features fighting for next quarter. You run the dual-question survey to n = 240 buyers, segmented by usage tier.

The action plan writes itself: must-be features get closed first because the downside of missing them is brutal (-0.84 Worse coefficient). Performance features get a sustained investment tied to competitive benchmarks. Delighters get shipped opportunistically when they are cheap. Indifferent items leave the backlog entirely.

This is also why I push teams to run Kano before the annual planning offsite, not during it — you want the survey data on the wall before the loudest voice in the room starts assigning prizes to their pet feature.

When to actually use Kano

Kano earns its complexity in specific situations:

• A large mixed backlog with features of obviously different shapes (a security fix and a fun social feature in the same sprint).
• A satisfaction-driven product where retention and NPS matter more than transactional revenue per session — consumer subscriptions, communication tools, creator platforms.
• A roadmap decision the team disagrees about and existing frameworks (RICE, ICE) keep producing similar scores that everyone interprets differently.
• Competitive analysis — running the same survey against a competitor's feature set tells you where they have a must-be advantage you must close, versus where they have a delighter you can ignore.

Kano is overkill for small backlogs, for features inside a tightly defined cluster, and for any team that has not yet shipped v1. Build the basic product first; classify second.

Common pitfalls

The single biggest trap PMs hit with Kano is treating every flashy idea as a delighter. New PMs run the survey hoping data will confirm their roadmap, and they write questions that telegraph the right answer. True delighters are rare — most features classify as indifferent, performance, or must-be. If your survey returns more than 30% Attractive, the questions are probably leading.

A second pitfall is surveying mixed segments and averaging the result. A Snowflake power user and a first-week trial user value completely different things. Running the survey across both populations and averaging produces a number that describes nobody. Segment by user tier, tenure, or job-to-be-done before you compute coefficients — minimum n = 100 per segment for stable signal.

The third trap is forgetting that categories decay over time. Voice search on a phone in 2014 was attractive; in 2026 it is performance, trending must-be. Any Kano analysis older than 12-18 months is suspect, and any analysis from before a major competitor launched a category-defining feature is dead. Rerun annually for mature products, quarterly for fast-moving consumer categories.

The fourth trap is running Kano with an undersized sample. Fewer than 100 responses per segment and your dominant-category bars are inside the margin of error. Fewer than 30 responses per segment and you are reading tea leaves. Recruit actual customers from the relevant cohort, not your colleagues or friends-of-friends.

Related reading

• RICE prioritization for PMs
• JTBD framework in product manager interviews
• Activation framework for product managers
• Product manager case interview guide

If you want to drill PM frameworks, prioritization tradeoffs, and product-sense interview prompts every day, NAILDD is launching with structured practice across exactly this pattern.

FAQ

How many features should I classify in a single Kano survey?

Keep it to 5 to 10 features per respondent, maximum. Each feature requires two questions, so a 10-feature survey is already a 20-question instrument plus segmentation. Beyond that, fatigue tanks data quality — the last features get systematically worse answers after about 8 minutes. For more candidates, run separate surveys to different panels, or pre-screen out obvious must-bes first.

Is Kano a replacement for RICE or ICE?

No, and treating it as one is how teams burn cycles. Kano tells you the shape of the satisfaction curve. RICE and ICE tell you the effort-adjusted impact ranking. Classify with Kano first, then prioritize the must-be and attractive piles separately using RICE, because the trade-offs inside each category are different. A must-be will never have the upside of a delighter, but it has catastrophic downside if missed.

How is Kano different from a standard satisfaction survey?

A standard satisfaction survey asks "how much do you want this?" and gets monotonic answers — everyone wants everything. The Kano dual-question structure forces respondents to imagine both the with-it and without-it world, which surfaces the asymmetry between upside and downside. That asymmetry is the entire signal. Without it you cannot distinguish a must-be from a delighter, because users will say they "like" both.

How long should a Kano survey take a respondent to complete?

Aim for under 10 minutes for the entire instrument, including segmentation. That works out to 5-8 features with demographic questions, or 10 features if the panel is pre-segmented. Pilot internally and time it — if the pilot takes 15 minutes, your live response rate will collapse and the responses you get will be from patient outliers, not your modal customer.

What sample size do I need for stable results?

At least 100 responses per segment for a defensible dominant-category signal, and 300 or more if you want tight confidence intervals on the Better/Worse coefficients. Multiple segments — free-tier, paid-tier, enterprise — each need 100, not 100 total. This is what usually kills Kano initiatives at small startups: a 2,000-customer base with a 5% response rate gives you 100 responses, which is the bare minimum across all segments combined.

Can I run Kano on a feature that does not exist yet?

Yes, and that is its highest-value use case. Kano works on hypothetical features — describe the feature in one or two sentences, then ask the dual question. The risk is that respondents have to imagine the feature, so your wording carries enormous weight. Pilot the description on 10-20 users and refine. A feature classified as a delighter on a clean description but indifferent on a sloppy one is not telling you about the feature — it is telling you about the prompt.