Kano Model

The Kano Model sorts features by the shape of satisfaction they create, from table-stakes fixes to genuine delight, so teams prioritize what actually moves users.

Also known as Kano analysis, Kano diagram, attractive quality theoryDecide
Xander Minzenmay

Xander Minzenmay. Xander is an Australian entrepreneur and community builder based in Singapore.

Example

Three kinds of feature

fully present →satisfieddelightersperformancemust-be
Must-be features only hurt when missing. Delighters surprise. Performance scales with effort.

What is Kano Model?

The Kano Model is a framework for classifying product features by how they actually affect customer satisfaction, not just whether users say they want them. It's one of the analytical engines behind a working prioritization framework: instead of ranking a backlog by opinion or urgency, you sort it by the shape of the relationship between "we built this" and "the customer is happier."

The model traces to a 1984 paper by Noriaki Kano, Nobuhiko Seraku, Fumio Takahashi, and Shin-ichi Tsuji, "Attractive Quality and Must-be Quality," published in the Journal of the Japanese Society for Quality Control. That paper laid out five categories a feature can fall into. Must-be quality is table stakes: its absence causes anger, but its presence is barely noticed. One-dimensional (performance) quality moves satisfaction in a straight line with how much of it you deliver. Attractive quality creates delight when present but no complaint when missing. Indifferent quality changes nothing either way, and reverse quality actually loses you customers when you add more of it.

The term and its five-way taxonomy trace specifically to Kano and his co-authors, and that is the definition Produck uses. A 2017 empirical study in PLOS ONE by Feng-Han Lin and colleagues re-tested the model against real customer data and confirmed the same asymmetric, nonlinear pattern the original paper described.

Why it matters for product-market fit

Raw feature requests all look the same size on a spreadsheet. The Kano Model gives you a second axis: not just how loud the ask is, but what kind of satisfaction curve it sits on. That distinction matters directly inside Produck's loop.

During Listen, you're collecting requests and complaints without yet knowing which bucket each one belongs to. During Diagnose, Kano thinking helps you separate the must-be fixes users assume you already have from the attractive additions that could actually differentiate you. This is also where Jobs to Be Done pairs well with Kano: JTBD tells you the underlying job a customer is hiring your product for, and Kano tells you where a specific feature sits on the satisfaction curve for that job. During Decide, that separation is what keeps a roadmap honest instead of just reactive. As we've written about what PMF actually requires, fit isn't a single metric, it's a loop you keep re-running, and Kano is one of the lenses you apply on each pass through Decide. During Ship, the same categories tell you what to message: must-be fixes rarely deserve a launch post, but attractive features do.

When it works, and when it doesn't

It works when:

  • You have enough user volume or interview depth to distinguish a genuine must-be complaint from one loud user's preference
  • You're choosing between features that are already validated as worth building and just need a sequencing call

It falls short when:

  • Your sample is too small, so a single vocal customer gets miscategorized as representing the whole market
  • You skip the survey or interview step and just guess which bucket a feature belongs in, which turns Kano into a label for a decision you'd already made
  • Categories shift over time, so a feature you classified as attractive last year has quietly become must-be as the market matures and competitors ship it too
  • You treat the model as a substitute for talking to users instead of a way to structure what they already told you

How to apply it

  1. Pull your last quarter of feedback and requests into one list, grouped by the underlying job each one relates to.
  2. For each candidate feature, ask two questions of a sample of users: how would you feel if this were present, and how would you feel if it were absent. The paired answers place the feature in one of the five categories.
  3. Sort the list by category first, then by build effort within each category.
  4. Fund the must-be gaps before anything else. A missing must-be feature caps your ceiling no matter how many delighters you ship.
  5. Pick one or two attractive candidates per cycle and ship them loudly. This is where messaging and roadmap should agree.
  6. Re-survey every couple of quarters. Categories move as your market and competitors do, and yesterday's delighter is next year's must-be.

Sources

  1. Attractive Quality and Must-be Quality, Noriaki Kano, Nobuhiko Seraku, Fumio Takahashi, Shin-ichi Tsuji, Journal of the Japanese Society for Quality Control (1984)
  2. Empirical research on Kano's model and customer satisfaction, Feng-Han Lin, Sang-Bing Tsai, Yu-Cheng Lee, Cheng-Fu Hsiao, Jie Zhou, Jiangtao Wang, Zhiwen Shang, PLOS ONE (2017)
Xander Minzenmay

Xander Minzenmay. Xander is an Australian entrepreneur and community builder based in Singapore. He co-founded Project 6, a hacker house and founder community running residencies across Singapore, Malaysia, Canada, and beyond — spaces where some of the region's most ambitious builders live, ship, and launch together. He has worked across product management and venture capital, and he brings that same obsession with craft and community to building digital products with taste.