# Kano Model The Kano model sorts product features into basics, performance features, and delighters by how each one moves customer satisfaction. **The question.** For each feature, does adding it raise satisfaction, or does missing it only cause complaints? Also known as: Attractive quality and must-be quality. The three labels used with customers are often basics, performance, and delighters. ## When to use it - A roadmap is a pile of feature requests, and you need a way to separate table stakes from attributes that would actually move preference. - Customers say everything is important, so a single importance score cannot rank the list. - You are about to spend on a delighter while a must-be is failing, and complaints are rising. - A Kano-style dual questionnaire is feasible, because you can name discrete attributes and reach people who use the product. ## When to avoid it - You do not yet know the job or the segment. Sorting features first locks in the current product. Find the job, then classify. - Attributes cannot be named as present or absent, such as a vague "better experience." The dual questions need a concrete feature. - Sample sizes are tiny and you will still treat the category labels as facts. A handful of answers produces noise, not a type. - The decision is go or kill for a whole product. Kano ranks attributes inside an offer. It will not tell you whether to be in the market. ## Overview The Kano model sorts product attributes by how they move satisfaction: must-be basics that only cause complaints when missing, one-dimensional performance features where more is better, and attractive delighters that please when present and are not missed when absent. Indifferent and reverse types catch spend that will not help, or will hurt some customers. It supports the choice of what to fund first on a roadmap. The classification comes from paired questions, not from a workshop or from a single importance score. Must-be gaps beat delighters. Attractive features decay as competitors copy them, so a type is a reading, not a permanent label. ## The five types ### Must-be (basics) Expected attributes. If they are missing, customers are dissatisfied. If they are present, satisfaction does not rise. A hotel's clean room and a car's brakes sit here. Funding them does not win the sale. Failing them loses it. ### One-dimensional (performance) Attributes where more is better and less is worse, in a roughly linear way. Battery life, delivery speed, and price-for-quantity are typical. These are the attributes customers will name when you ask what they want, and where competitors often fight. ### Attractive (delighters) Attributes that raise satisfaction when present and do not cause dissatisfaction when absent, because nobody was expecting them. They are usually unspoken. They move preference until rivals copy them, at which point they start to become must-be. ### Indifferent Attributes that do not move satisfaction either way. Teams still build them because they are easy, or because someone inside likes them. The classification is the reason to stop. ### Reverse Attributes that some customers want and others actively do not. A feature that delights one segment can be reverse for another, such as a highly automated flow that removes a control a professional user wants. Reverse is a signal to split the offer or drop the feature for that group. ## What it is not - A ranking by stated importance. Everything important looks like a must-be if you only ask "how important is this." The dual questions are the method. - A substitute for talking to customers. Filling the three columns from a workshop produces the team's types, not the customer's. - A permanent classification. Attractive features decay. Re-run the questions when the competitive set changes. ## The steps 1. **List attributes as present-or-absent features.** Name each item so a customer can imagine it in and out of the product. Split bundles. Drop slogans. Output is a short list, usually under twenty, or the questionnaire will not be finished. 2. **Ask the functional and dysfunctional pair.** For each attribute, ask how they would feel if it were present, and how they would feel if it were absent. Use the five answers: like, expect, neutral, live with, dislike. Do this with people who use the product, not with the team. 3. **Classify from the pair, not from importance.** Combine the two answers with the standard Kano evaluation table. Tally must-be, one-dimensional, attractive, indifferent, reverse, and questionable. Questionable pairs, such as like and like, mean the question was unclear. Rewrite those items. 4. **Fund in order, and split reverse.** Fix must-be gaps first, compete on one-dimensional, spend on attractive only when the basics hold, cut indifferent, and split or drop reverse. Write the sequence on the roadmap with the counts behind each label. 5. **Reclassify when rivals copy you.** Attractive becomes must-be as it spreads. Set a date to ask the pairs again, especially after a competitor ships your delighter. ## In practice A B2B invoicing product has eighteen items on the next-two-quarters roadmap. Sales says customers want all of them. The consultant runs the dual Kano questions with 46 paying users, one pair per item. Generating a legally valid tax invoice and keeping an audit trail classify as must-be: dislike if absent, expect if present. Speed of bulk send classifies as one-dimensional. A cash-flow forecast tile classifies as attractive. Branded invoice themes classify as indifferent. An auto-chase of late payers classifies as reverse for the accountants, who want to approve each chase, and attractive for owner-managers. The must-be audit trail had been scheduled behind the forecast tile because the tile photographed well. The sequence is reversed: trail defects are fixed first, bulk-send speed second, the forecast tile third as a delighter once the basics hold, themes are dropped, and auto-chase is offered only on the owner-manager plan. NPS comments from the last two quarters had already mentioned audit surprises. The Kano pass explained why those comments sat next to high scores on "ease of use." ## What you leave with - A list of attributes written as present-or-absent features. - A classification table with counts for each type, including indifferent, reverse, and questionable. - A funding sequence: must-be gaps, then performance, then delighters. - Items to drop or to offer only in a split plan. - A date to re-run the pairs. ## Failure points ### Workshop categories The team assigns types from instinct. Must-be inflates, because every internal stakeholder can imagine a complaint, and nothing is indifferent. The dual questions are what make the model empirical. ### Delighters funded while basics fail A wow feature ships on top of a broken must-be. Complaints rise and the delighter is blamed, or never noticed. Basics first is not conservative. It is the model. ### Treating attractive as permanent Last year's delighter is this year's expectation. The roadmap keeps celebrating it, and a rival's copy now sits in must-be for your customers. ### Importance scores mixed in A separate "how important" question is averaged with the Kano type. Everything important then looks mandatory, which is the problem the dual questions were built to avoid. ### One sample for two jobs Users with different jobs produce mixed types and a large reverse pile. Split the sample the way you would split a jobs interview, then classify. The failures above are usually [Framing](https://usefulconsultingframeworks.com/your-edge/#framing): the wrong problem was chosen before this framework was applied. ## Origin Noriaki Kano and colleagues published "Attractive Quality and Must-Be Quality" in 1984 in the Journal of the Japanese Society for Quality Control. The paper argued that quality is not one-dimensional: some attributes only cause dissatisfaction when they are missing, some raise satisfaction in proportion to how well they are done, and some delight when present without being expected. Classification uses a pair of questions for each attribute, one functional (how do you feel if it is present) and one dysfunctional (how do you feel if it is absent), with answers from like through expect, neutral, and live with, to dislike. The model is not licensed and carries no trademark. Later writers renamed the categories as basics, performance features, and delighters, and added the observation that attractive attributes decay into must-be attributes as competitors copy them. This note uses Kano's terms, with the later names in brackets. ## Further reading - [What is the Kano Model?](https://asq.org/quality-resources/kano-model). ASQ's free practitioner page, with the three main need levels (expected, normal, exciting) and how they feed voice-of-customer work. - [Kano model](https://en.wikipedia.org/wiki/Kano_model). Wikipedia's account of the five categories, the dual-question method, and the 1984 paper. Check its sources before quoting. ## Related frameworks - [Jobs to Be Done](https://usefulconsultingframeworks.com/frameworks/jobs-to-be-done/): Finds the progress the customer is hiring for. Pick it before Kano when you do not yet know which attributes to put on the questionnaire. - [Value Proposition Canvas](https://usefulconsultingframeworks.com/frameworks/value-proposition-canvas/): Matches pains and gains to the offer. Pick it when you are designing the offer, and use Kano to rank the attributes on that offer. - [MoSCoW and RICE Prioritization](https://usefulconsultingframeworks.com/frameworks/moscow-rice/): Prioritizes what to build in a timebox. Pick it after Kano has labeled the types, so Must is not a dumping ground for every request. - [Net Promoter Score](https://usefulconsultingframeworks.com/frameworks/nps/): Tracks whether customers would recommend you. Use the comments behind low scores to spot failing must-be attributes. Last updated October 20, 2026.