The Kano Model for Product Prioritization

7 min read ยท 2026-10-08

The Kano model classifies product features by how their presence or absence affects customer satisfaction. Basic features are expected and only cause frustration when missing, performance features increase satisfaction the better they get, and attractive features, often called delighters, create outsized satisfaction because nobody expected them. Prioritizing with Kano means securing basics first, investing in the performance features customers care about most, and adding a few delighters.

This guide explains each category, how to run a Kano survey with paired questions, how to interpret results, a worked example for a mobile app, and a phased plan to apply Kano analysis to next quarter's roadmap.

The roadmap at a glance

Goal: Run a Kano analysis on candidate features and use it to shape a balanced roadmap for next quarter. Duration: 3 to 4 weeks of research, then a 13-week quarter

  1. Select Features to Test (Days 1-3)

    Choose a focused set of features worth asking customers about.

    • Shortlist 10 to 20 candidate features from the backlog and discovery work.
    • Describe each feature in plain customer language without internal jargon.
    • Include a few existing features to validate how the survey classifies known basics.
    • Define the customer segment you will survey for this analysis.

    Milestone: A list of clearly worded features and a defined target segment.

  2. Design the Survey (Days 4-7)

    Build a Kano questionnaire with functional and dysfunctional questions for each feature.

    • Write a functional question asking how customers feel if the feature is present.
    • Write a dysfunctional question asking how they feel if the feature is absent.
    • Use the standard five answers from I like it to I dislike it.
    • Add an importance rating per feature to help break ties later.
    • Pilot the survey with a handful of customers and fix confusing wording.

    Milestone: A piloted survey with paired questions and importance ratings for every feature.

  3. Collect Responses (Weeks 2-3)

    Gather enough responses from the right segment to see clear patterns.

    • Send the survey through in-app prompts, email, or your research panel.
    • Monitor responses by segment to avoid one group dominating the results.
    • Follow up with a few respondents by interview to understand surprising answers.
    • Close the survey once category patterns stop changing with new responses.

    Milestone: A response set from the target segment, plus interview notes on surprising answers.

  4. Analyze and Classify (Days 22-25)

    Translate responses into a Kano category for each feature.

    • Map each response pair to a category using the Kano evaluation table.
    • Assign each feature its most frequent category across respondents.
    • Calculate satisfaction and dissatisfaction coefficients to compare features within categories.
    • Flag features with split results for segment-level analysis.

    Milestone: Every feature classified with coefficients and notes on segment differences.

  5. Build the Roadmap (Weeks 1-13 of the quarter)

    Use the classification to balance basics, performance, and delighters on the roadmap.

    • Schedule any missing basic features first because their absence drives dissatisfaction.
    • Rank performance features by satisfaction coefficient and effort.
    • Reserve limited capacity for one or two high-scoring attractive features.
    • Drop or park features classified as indifferent.
    • Plan a repeat survey next year since categories shift over time.

    Milestone: A quarterly roadmap with basics covered, top performance features scheduled, and one delighter.

The Kano Categories

The model is named after the Japanese quality researcher who introduced it in the 1980s, and its core insight is that satisfaction is not linear. Some features only prevent unhappiness, some scale satisfaction proportionally, and some create delight from nothing.

Basic (or must-be) features are taken for granted: password reset in a web app, offline maps in a hiking app. Customers rarely request them and never praise them, but their absence is a dealbreaker. Performance (or one-dimensional) features scale: faster sync, more storage, better search results. Attractive features surprise customers and create delight, but nobody complains when they are missing. Two more categories help clean up results: indifferent features nobody cares about, and reverse features that some customers actively dislike.

  • Basic: expected; absence causes frustration, presence goes unnoticed.
  • Performance: more is better; satisfaction rises with quality.
  • Attractive: unexpected; presence delights, absence is fine.
  • Indifferent: no effect either way; usually safe to drop.
  • Reverse: some users prefer it absent; consider making it optional.

Running the Kano Survey

For each feature you ask two questions. The functional question: "If the product had automatic backup, how would you feel?" The dysfunctional question: "If the product did not have automatic backup, how would you feel?" Each uses the same five answers: I like it, I expect it, I am neutral, I can tolerate it, I dislike it.

The combination of answers determines the category through a standard evaluation table. Liking presence and disliking absence indicates a performance feature. Expecting presence and disliking absence indicates a basic. Liking presence while feeling neutral about absence indicates an attractive feature. Contradictory pairs, such as liking both presence and absence, are marked questionable and usually signal a confusing question.

Keep descriptions concrete and short. If respondents cannot picture the feature, their answers are noise. A short image or one-line example per feature improves response quality noticeably.

A Worked Example for a Mobile App

A budgeting app team tested twelve features. Bank sync and data export came out as basics, which surprised nobody, but sync for a secondary bank type also landed there, revealing a gap some users found unacceptable. Faster transaction categorization and better spending reports were performance features. Shared budgets with a partner and a weekly summary notification came out attractive. A gamified savings badge system was indifferent, and an AI chatbot was split between attractive and reverse.

The quarter's roadmap fixed the secondary bank sync first, then improved categorization accuracy as the top performance feature, and added shared budgets as the single delighter. Badges were parked. The chatbot got a small interview round to understand why some users disliked the idea before any build decision.

Turning Kano Results Into Roadmap Decisions

A sensible default order is basics first, performance features next, and a deliberate slice of attractive features. Missing basics quietly drive churn because customers do not ask for them; they just leave. Performance features are where you compete day to day. Delighters differentiate, but a product full of delighters with broken basics still frustrates people.

Combine Kano with effort estimates. A cheap basic gap is an obvious win; an expensive delighter needs a strong strategic reason. Satisfaction and dissatisfaction coefficients help rank features within a category, while RICE or a value versus effort matrix can handle the final ordering across categories.

  • Close basic gaps before adding anything new.
  • Rank performance features by coefficient and effort.
  • Limit delighters to one or two per quarter.
  • Remove indifferent features from the backlog.

Limitations and How to Handle Them

Kano categories decay over time. Today's delighter becomes tomorrow's performance feature and eventually a basic, as happened with features like mobile apps and dark mode across many product categories. Repeat the survey periodically rather than treating results as permanent.

Results also vary by segment. Enterprise admins and individual users can classify the same feature differently, so analyze by segment when results look split. Finally, surveys capture stated preferences, not behavior. Validate surprising results with interviews or usage data before committing significant effort.

Common mistakes to avoid

  • Ignoring basic features because nobody requests them leads to silent churn; audit and close basic gaps first.
  • Filling the roadmap with delighters while basics are broken frustrates users; limit delighters to a small capacity slice.
  • Writing vague feature descriptions produces noisy answers; describe each feature concretely in customer language.
  • Mixing very different segments in one analysis hides real differences; split results by segment when categories look divided.
  • Treating results as permanent ignores category decay; repeat the survey periodically.
  • Using Kano alone ignores effort; combine categories with effort estimates or RICE before finalizing the roadmap.

Frequently asked questions

What are the categories of the Kano model?

The main categories are basic or must-be features, performance or one-dimensional features, and attractive features, also called delighters. Survey analysis also identifies indifferent features that have no effect on satisfaction, reverse features that some customers prefer absent, and questionable results that usually indicate a confusing question. The first three drive most roadmap decisions.

How many respondents do I need for a Kano survey?

There is no fixed number, but you need enough responses from your target segment that each feature's dominant category is stable. A practical approach is to watch the results as responses arrive and stop when adding more no longer changes category assignments. Smaller samples work for directional insight, especially when paired with follow-up interviews.

How is Kano different from RICE?

Kano classifies features by their effect on customer satisfaction using survey data, while RICE scores features by reach, impact, confidence, and effort to estimate value per unit of work. Kano tells you what kind of value a feature provides; RICE helps rank features against each other. Many teams use Kano to inform the impact estimate in RICE.

What is a delighter in the Kano model?

A delighter, or attractive feature, is something customers do not expect, so its absence causes no dissatisfaction, but its presence creates strong positive reactions. Delighters help differentiate a product. Over time they tend to become expected, so a delighter today can become a performance feature or basic requirement in later years.

Do I always need a survey to use the Kano model?

No. A full survey gives the most reliable classification, but you can apply Kano thinking informally by reviewing support tickets, churn reasons, and interview notes. Complaints about absence point to basics, requests for improvement point to performance features, and enthusiastic reactions to unexpected ideas point to delighters. Use a survey when the decision is significant.

Generate this roadmap with AI