How to Use the Kano Model When Selecting MVP Features

The Kano model is easy to describe in theory — basic, performance, and delighter features — but founders often stall at the practical step: how do you actually find out which category each of your candidate features falls into? This is the working process, not the concept explainer. If you want the conceptual grounding on why this categorization matters for user satisfaction before you start, our post on what users actually value through the Kano lens covers that; this one is the checklist for running the exercise yourself.

Step 1: Build a Short List of Candidate Features

Start with the features you’re actually debating, not your entire product vision. Ten to twenty candidate features is a workable range for a lightweight survey — more than that and respondents fatigue before finishing.

Write each feature as a single, concrete sentence a non-technical person would understand. “Real-time order tracking with map view” is testable. “Better tracking experience” is not, because different respondents will imagine different things.

Step 2: Draft the Paired Kano Questions

For each feature, write two questions:

• Functional question: “How would you feel if [product] had [feature]?”
• Dysfunctional question: “How would you feel if [product] did NOT have [feature]?”

Each question is answered on the same five-point scale:

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

Keep the scale identical across every feature so respondents don’t have to relearn the question format each time.

Step 3: Recruit 10-15 People Who Match Your Target User

This step gets skipped more than any other, usually because founders survey whoever is easiest to reach — friends, colleagues, existing contacts — rather than people who resemble the actual target customer. A Kano survey answered by the wrong audience produces confident-looking but misleading categorizations.

Ten to fifteen closely-matched respondents is enough for an MVP-stage decision. You’re not publishing an academic study; you’re trying to avoid an expensive misread before development starts.

Step 4: Collect Responses and Score Each Feature

For every respondent and every feature, you now have one functional answer and one dysfunctional answer. Cross-reference the pair against the standard Kano evaluation table:

Functional answer	Dysfunctional answer	Resulting category
Like it	Dislike it	Performance
Like it	Tolerate / Neutral / Expect it	Delighter (Excitement)
Expect it	Dislike it	Basic (Must-be)
Neutral	Neutral	Indifferent
Tolerate it	Like it	Questionable (recheck the question wording)

Tally each respondent’s category per feature, then take the most frequent category as that feature’s overall classification. A spreadsheet with one row per respondent and one column per feature is enough to do this by hand for a short list.

Step 5: Plot the Results

Once every feature has a category, plot them on two axes: how well the feature is implemented (x-axis) against user satisfaction (y-axis). This isn’t required to make a decision, but it makes the trade-offs visible at a glance, especially when presenting the results to a co-founder or investor.

• Basic features form a curve that starts deeply negative when absent and flattens near neutral when present — they never push satisfaction above baseline.
• Performance features form a roughly straight diagonal line — satisfaction rises steadily with how well the feature is executed.
• Delighter features form a curve that stays near neutral when absent and rises sharply when present — the upside is real but capped by novelty.

A simple bar or scatter chart in a spreadsheet is sufficient; you don’t need specialized Kano software for a first-pass MVP decision.

Step 6: Translate Categories Into a Feature Selection Checklist

With every candidate feature scored, apply this checklist before finalizing MVP scope:

• Every basic feature required for the core user journey is included, with no shortcuts
• Performance features tied directly to the core assumption you’re testing have a competent (not exhaustive) first version
• At most one delighter is included, and only after the above two are solid
• Indifferent features are cut or deferred — they add build cost without moving satisfaction either way
• Any “questionable” results are re-examined; the question was likely worded ambiguously, not the user being inconsistent

Step 7: Revisit After Launch

A pre-launch Kano survey is directional, not permanent. Once real users are interacting with your MVP, watch for two signals that suggest a feature’s category has shifted:

• A basic feature generating unexpectedly positive feedback might actually be a performance feature you under-invested in
• A delighter losing its impact over a few weeks is normal — expect its effect to fade as users get used to it, and don’t keep investing there indefinitely

According to Y Combinator’s Startup Library on getting your first users, the most useful early feedback loops focus on watching what users actually do rather than only what they say they want — the same principle applies to reassessing Kano categories after launch: real usage data outranks a pre-launch survey once you have it.

A Worked Mini-Example

Say you’re building a freelancer invoicing MVP and testing five candidate features: automatic tax calculation, one-click PDF export, a client-facing payment portal, in-app messaging, and dark mode.

A quick Kano pass on a small sample of freelancers might reveal: PDF export and tax calculation come back basic — freelancers expect them and would be frustrated by their absence. The payment portal comes back performance — the better and faster it works, the more satisfied respondents are. In-app messaging comes back mostly indifferent — most freelancers already use email or a separate tool. Dark mode comes back a mild delighter for a subset of respondents but indifferent for most.

The resulting MVP scope: ship tax calculation and PDF export solidly, build a competent (not gold-plated) version of the payment portal, drop in-app messaging entirely for v1, and treat dark mode as a possible small delighter only if time remains after the essentials are done.

Frequently Asked Questions

How many users do I need for a lightweight Kano survey before building an MVP?

10-15 users who closely match your target customer profile is usually enough for directional signal at the MVP stage. You are not running a statistically rigorous study; you are trying to catch obvious basic-vs-delighter misreads before committing build budget.

What questions do I ask in a Kano survey?

For each candidate feature, ask a functional question (how would you feel if this feature were present?) and a dysfunctional question (how would you feel if this feature were absent?). Each is answered on a five-point scale from "I like it" to "I dislike it." The combination of the two answers determines the feature's category.

Can I run a Kano survey without specialized software?

Yes. A simple spreadsheet with the standard Kano evaluation table is enough to score responses manually for a short feature list. Dedicated Kano survey tools exist and speed up scoring for larger feature sets, but they are not required for an early-stage MVP with a handful of candidate features.

What do I do when survey responses for one feature are split across categories?

Take the most frequently selected category as the working classification, but note the split. A feature with a genuinely divided response often means your user base is not as homogeneous as you assumed, which is itself useful information for defining your MVP's initial target segment.

How is this different from just asking users which features they want most?

Asking users to rank features by preference produces a wish list, not a satisfaction model. The paired Kano questions separate what users expect by default (basic), what scales their satisfaction (performance), and what would surprise them (delighter) - a distinction a simple ranking question cannot capture.

Should I run this before or after building a prototype?

Before, if possible. A lightweight Kano survey works well against a written feature list, a few mockup screens, or a short description of each feature - you do not need a working prototype to get useful signal, and running it early avoids building features that turn out to be low-value.