The Kano Model: Classifying Baseline, Performance, and Delighter Features

The Kano model is a framework for classifying product features by how they affect customer satisfaction rather than by how hard they are to build. It sorts requirements into categories — basic features customers assume will be there, performance features where more is better, and delighters that surprise and impress — so a team can see which work merely prevents complaints and which work creates enthusiasm. Developed by Professor Noriaki Kano in the 1980s, it shows up on the PK0-005 exam wherever a scenario asks how a team decided which features matter most.

What the Kano model is for

Most prioritization tools treat every requirement as a point on a single scale: high priority or low, must-have or nice-to-have. The Kano model’s insight is that features do not all pay off the same way. Some features generate zero goodwill when present but intense frustration when absent. Others earn satisfaction in direct proportion to how well they perform. A third group earns outsized delight precisely because nobody expected it.

Because those three payoff curves are different shapes, ranking every feature on one list hides critical information. A team that pours effort into delighters while a baseline expectation is broken ships a product customers reject — no personalized surprise compensates for an app that crashes. The Kano model forces the team to ask, for each candidate feature, which curve does this sit on? before deciding where effort goes.

On an IT project, this classification typically happens during planning — while the team is gathering requirements, building a backlog, or deciding scope for a release. It pairs naturally with backlog refinement in Agile work and with requirements analysis in predictive (Waterfall) work.

The categories

The model defines three primary categories, plus two that teams use to filter out noise:

Category	Also called	When present	When absent or weak	Example (booking app)
Basic	Must-be, expected, baseline	No extra satisfaction — it’s assumed	Strong dissatisfaction	The app doesn’t crash; payments process correctly
Performance	One-dimensional, linear	Satisfaction rises as it improves	Dissatisfaction rises as it degrades	Search speed; number of filter options
Delighter	Excitement, attractive	Disproportionate satisfaction	No penalty — nobody expected it	A surprise personalized room upgrade offer
Indifferent	—	No effect either way	No effect either way	An internal logging format the user never sees
Reverse	—	Actually reduces satisfaction for some users	Preferred absent by those users	Aggressive pop-ups, forced tutorials

Three distinctions carry most of the exam weight:

• Basic features are invisible when they work. Nobody praises a hotel app for not crashing. But if it does crash, satisfaction collapses. Basics are the floor — you must deliver them, and you get no competitive credit for doing so.
• Performance features scale linearly. Faster search makes users happier; slower search makes them unhappier. These are the features customers consciously compare between competing products, so they’re where “more is better” investment pays off predictably.
• Delighters are asymmetric. Their absence costs nothing because users never expected them, but their presence can differentiate a product in a crowded market. They are the “wow” features.

How the categories shift over time

A feature’s Kano category is not permanent. Yesterday’s delighter becomes today’s performance feature and tomorrow’s baseline expectation. Free Wi-Fi in hotels was once a delighter; now its absence is a complaint. Smartphone cameras followed the same arc. This decay is why teams re-run Kano analysis periodically rather than classifying once — a competitive advantage built on delighters erodes as the market catches up, and a product that stops refreshing its delighters slowly becomes merely adequate.

How teams actually classify features

Formal Kano analysis uses a paired-question survey. For each feature, customers answer two questions: how they’d feel if the feature were present (the functional question) and how they’d feel if it were absent (the dysfunctional question). The combination of answers maps to a category. A feature customers are neutral about when present but angry about when missing is a basic. One they love when present and dislike when missing is performance. One they love when present but don’t miss is a delighter.

In practice, many project teams skip the formal survey and classify collaboratively during backlog refinement or requirements workshops, using customer feedback, support tickets, and competitor comparisons as evidence. Either way, the output feeds prioritization: deliver all basics first (they’re non-negotiable), invest in performance features to the level the market demands, and select a small number of delighters deliberately for differentiation.

Kano vs. other prioritization approaches

Don’t confuse Kano with MoSCoW, the other classification scheme PK0-005 candidates meet. MoSCoW sorts requirements by delivery commitment — Must have, Should have, Could have, Won’t have (this time) — answering “what ships in this release?” Kano sorts by satisfaction impact — answering “how will customers react to this feature?” They complement each other: a Kano basic will almost always be a MoSCoW must-have, but a delighter might land anywhere in MoSCoW depending on capacity. If a scenario mentions satisfaction, expectations, or “delight,” it’s Kano; if it mentions release commitments or negotiating scope, it’s MoSCoW.

Kano classification also informs, but does not replace, ordinary backlog prioritization by the business value the project was chartered to deliver — and its outputs often surface during stakeholder identification work, since different stakeholder groups can classify the same feature differently.

How the PK0-005 exam tests this

• The classification scenario. A team labels one feature “expected,” another “more is better,” and a third “an unexpected differentiator,” and the question asks which model they’re using. The three-part structure — baseline, linear performance, delighter — is the Kano fingerprint. Recognize it.
• The category-matching scenario. You’re given a specific feature and asked which Kano category it belongs to. Apply the asymmetry test: penalized when absent but unpraised when present = basic; satisfaction tracks quality in both directions = performance; loved when present, unmissed when absent = delighter.
• The model-discrimination scenario. A prioritization vignette where the wrong answers are MoSCoW, a weighted scoring matrix, or a probability-impact matrix. Kano is the only one framed around customer satisfaction; the probability-impact matrix is risk, not features; weighted scoring compares options against criteria.
• The misallocation scenario. A team ships delighters while a baseline feature is broken, and users are furious. The tested concept: basics must be satisfied before performance features or delighters generate any value.

The Kano model appears in the Project Life Cycle Phases domain — see the full PK0-005 study guide for the complete domain breakdown and study plan, and use Project+ practice questions to make the category labels stick.

Quick reference

• The Kano model classifies features by their effect on customer satisfaction, not by effort or cost.
• Basic (must-be): assumed; absence causes dissatisfaction, presence earns no credit.
• Performance (one-dimensional): satisfaction rises and falls linearly with quality — “more is better.”
• Delighter (excitement): unexpected; creates disproportionate satisfaction, absence costs nothing.
• Indifferent features move satisfaction in neither direction; reverse features annoy some users when present.
• Delighters decay into basics over time — re-run the analysis periodically.
• Kano measures satisfaction impact; MoSCoW records delivery commitment. Different questions, complementary tools.
• Deliver basics first: no delighter compensates for a broken baseline expectation.