By Simon Sovič, Senior Product Manager

You have a feature backlog that keeps growing. Everyone on the team has opinions. Users say they want everything. The Kano model gives you a framework to cut through that noise and figure out which features will actually make users happy, which ones they expect by default, and which ones waste your time. This guide walks you through the full process in six steps. You do not need a statistics background. You need roughly two to four hours for your first run and a small group of users willing to answer a short survey.

What You'll Need

  • A list of five to fifteen candidate features you are considering building
  • Access to ten to thirty users or target customers willing to answer a survey
  • A free survey tool such as Google Forms, Typeform, or Tally
  • A spreadsheet for scoring results
  • About two to four hours for setup, and another hour to analyze results

Step 1: Understand the Five Kano Categories

Before you build a survey, you need to know what you are measuring. The Kano model, developed by Professor Noriaki Kano in 1984, sorts product features into five categories based on how users feel about having or not having them.

  • Must-Be (Basic):Features users expect as a baseline. Their absence causes frustration. Their presence goes unnoticed. Example: a checkout button in an e-commerce app.
  • Performance (Linear):Features where more is better. Users notice improvements and feel proportionally satisfied. Example: page load speed.
  • Delighters (Excitement):Features users did not expect. Their presence creates genuine delight. Their absence causes no frustration. Example: a personalized onboarding message using the user's name and goal.
  • Indifferent:Features users do not care about either way. Building these wastes resources.
  • Reverse:Features some users actively dislike. Adding them hurts satisfaction for a segment of your audience.

Your goal is to identify which category each candidate feature falls into before you commit engineering time to it.

Step 2: Write Kano Survey Questions for Each Feature

The Kano survey uses a specific question format. For every feature, you ask two questions.

  • Functional question:"How would you feel if this feature were present?"
  • Dysfunctional question:"How would you feel if this feature were absent?"

Each question gets the same five answer options:

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

Keep language simple and concrete. Describe the feature in one sentence. Avoid internal jargon. If you are asking about a feature in a SaaS dashboard, say "a weekly summary email showing your top three metrics" rather than "automated reporting cadence."

Pro tip: limit the survey to ten features maximum. More than that and response quality drops sharply because respondents lose focus.

Step 3: Recruit the Right Respondents

The Kano model only works if your respondents match your actual target user. Ten responses from the right people beat one hundred from the wrong audience.

  • For a B2B product, recruit users who hold the role you are building for, not executives who approved the purchase.
  • For a consumer app, recruit people who already use competing products or have the problem you are solving.
  • Aim for at least fifteen to twenty responses per user segment if you have more than one segment.
  • Offer a small incentive. A $10 gift card or a free month of your product increases response rates significantly in practice.

If you are an early-stage startup with limited access to users, start with your existing beta users or power users from your waitlist. Even ten responses give you directional signal.

For a deeper look at how product managers at early-stage startups approach user research and prioritization decisions, see the Early-Stage Startup PM Job Description: What to Look For Guide.

Step 4: Run the Survey and Collect Responses

Build your survey in your chosen tool. Set up one section per feature with the functional question followed immediately by the dysfunctional question. This pairing is important. Respondents need to answer both while the feature is fresh in their mind.

  • Use radio buttons, not dropdowns. Dropdowns add friction and slow completion time.
  • Add a brief intro that explains what the survey is for. One to two sentences is enough. Transparency increases honesty.
  • Test the survey yourself before sending. Check that the question pairs make logical sense when read together.
  • Send a reminder after 48 hours. Many people open surveys and close them without finishing.

Collect responses over five to seven days. If you have not reached fifteen responses after seven days, extend by three days before closing.

Step 5: Score Responses Using the Kano Evaluation Table

This is where you translate survey answers into categories. Use the standard Kano evaluation table to map each pair of functional and dysfunctional answers to a category.

The table works like this. For each respondent and each feature, take their functional answer and their dysfunctional answer, then look up the category in the grid below:

  • Functional: Like / Dysfunctional: Dislike= Performance
  • Functional: Like / Dysfunctional: Expect= Delighter
  • Functional: Expect / Dysfunctional: Dislike= Must-Be
  • Functional: Like / Dysfunctional: Live with it or Neutral= Delighter
  • Functional: Neutral / Dysfunctional: Neutral= Indifferent
  • Functional: Dislike / Dysfunctional: Like= Reverse

Create a spreadsheet with one row per respondent and one column per feature. Fill in the category for each cell. Then count how many respondents assigned each feature to each category. The category with the highest count for a feature is that feature's classification.

Warning: if a feature has a high split between Must-Be and Delighter responses, you may have two distinct user segments reacting differently. Segment your results before drawing conclusions.

Step 6: Prioritize Features Based on Categories

Now you have a clear picture. Use the category results to make build decisions.

  • Must-Be features first:Ship these before anything else. Skipping them blocks user satisfaction entirely. These are your table stakes.
  • Performance features next:Improve these incrementally. More investment = more satisfaction. These features justify your pricing tiers or your premium plan.
  • Delighters strategically:Pick one or two Delighters per release cycle. They create memorable moments and drive word-of-mouth without requiring huge engineering effort in many cases.
  • Indifferent features: cut or defer:Remove them from your roadmap unless they have other business justification. Building things users do not care about is the most common waste in product development.
  • Reverse features: avoid entirely:These are features where a segment of your users actively wants them gone. Shipping them risks churn in that segment.

In practice, the biggest value of this exercise is not the ranking itself. It is the conversation it forces within your team. When you show stakeholders that a feature they love is classified as Indifferent by 70% of surveyed users, the backlog debate becomes data-driven rather than political.

To connect this to your broader product process, the Kano model pairs well with customer journey mapping. If you have not done journey mapping yet, the Customer Journey Mapping for Product Managers: A Practical Guide Is a strong companion read.

Common Mistakes to Avoid

  • Surveying the wrong people:Internal stakeholders are not users. Survey the people who will actually use the product, not the ones who commissioned it.
  • Asking about too many features at once:More than ten features per survey causes respondent fatigue. Split into multiple surveys or multiple sessions if your backlog is large.
  • Ignoring segment differences:One user segment's Delighter is another segment's Must-Be. Always check whether your user base is homogeneous before treating aggregate results as universal.
  • Treating categories as permanent:Delighters decay over time. A feature that delighted users in 2024 may become a Must-Be by 2026 as the market matures. Re-run the Kano survey every six to twelve months for features you have already shipped.
  • Skipping Must-Be features to chase Delighters:Many teams want to build useful things. The Kano model shows that shipping a Delighter while missing a Must-Be produces a net-negative user experience. Sequence matters.
  • Using the output in isolation:Kano tells you about user satisfaction. It does not tell you about technical feasibility, cost, or strategic fit. Combine Kano with an effort-impact matrix for better roadmap decisions.

If you find prioritization decisions causing stress or decision paralysis in your role as a founder or solo product manager, you are not alone. Many find that having an accountability structure helps them act on analysis rather than stall. The Best Accountability Tools for Solopreneurs in 2026 Covers practical options.

FAQ

How many users do I need for a Kano survey to be reliable?

Fifteen to twenty responses per user segment is the minimum for directional signal. For higher confidence in feature decisions affecting large user bases, aim for thirty or more per segment. For early-stage startups with limited user access, even ten responses from well-matched users provide useful guidance.

Can I use the Kano model before I have built anything?

Yes. You can describe features conceptually in the survey without building them. Use simple one-sentence descriptions or wireframe screenshots. The Kano model is designed for pre-build prioritization, which is precisely when it saves the most time and money.

How is the Kano model different from a simple feature ranking survey?

A simple ranking survey asks users to rate or rank features by importance. The Kano model reveals a different dimension: how users feel about having versus not having a feature. A feature ranked as very important may be a Must-Be rather than a Delighter. That distinction changes how you prioritize it. Must-Bes need to be present at baseline. Delighters earn loyalty. A ranking survey cannot separate these two categories.

How often should I re-run the Kano survey?

Run it every six to twelve months for your core feature set, and before each major release cycle when you are evaluating new candidate features. Categories shift as the market matures and as competitors ship similar features. What delights users today becomes expected tomorrow.

What should I do if results are evenly split between two categories?

An even split usually means you have two distinct user segments responding differently. Separate your responses by user type, company size, use case, or another relevant variable and re-score each segment independently. If the split persists within a segment, treat the feature as a Performance feature. This is the conservative default because it means any improvement adds satisfaction without the risk of negative reactions.

This page was made by SuperDuperSEO →