Kano model for product managers
Our reviewers evaluate writing services independently. Learn how we stay transparent, our methodology, and tell us about anything we missed.
The Kano model helps me understand how different product capabilities affect customer satisfaction. Instead of treating every requested feature as a simple vote, I ask what happens when the capability is absent, adequate, or better than expected. That distinction changes prioritization: a basic need can create frustration when missing, a performance feature can improve satisfaction as it improves, and an attractive feature can delight some customers without being expected.
I use the model as a conversation tool, not as a permanent label. Customer expectations change, segments differ, and a feature can move from surprising to ordinary. The value is in making those assumptions visible before a roadmap decision.
The three reactions I look for
The classic model describes several categories, but I start with three practical reactions.
A must-be need is an expected condition. Customers may not praise it when it works, but they notice quickly when it fails. Reliability, accurate billing, sensible permissions, and a usable mobile experience can behave this way depending on the product. Improving a must-be feature beyond an acceptable threshold may not create excitement, yet ignoring it can undermine trust.
A one-dimensional, or performance, need has a more direct relationship between delivery and satisfaction. Faster processing, better search relevance, lower effort, or more useful reporting can make the product feel better as performance improves. Customers can often compare this dimension across alternatives, which makes it useful for competitive positioning.
An attractive, or delighter, need is not expected by every customer. When it is useful and well-timed, it can create disproportionate positive reaction. If it is absent, customers generally do not feel cheated because they did not assume it would exist. Delighters are appealing, but I do not let them distract the team from broken basics.
The model also includes indifferent features, which do not materially change the experience for a segment, and reverse features, where more capability or a particular implementation makes the experience worse. Those categories are reminders that not every improvement is valuable and that customer preferences are not uniform.
Start with a specific segment and situation
I do not ask, “Is this feature a delighter?” in the abstract. I define who is reacting, what job they are trying to complete, and what alternative they use today. A capability can be a must-be requirement for an administrator, a performance improvement for a daily operator, and irrelevant to an occasional viewer.
I write a short context statement before research: “For [segment] doing [situation], how does the presence or absence of [capability] affect the experience?” This keeps the discussion anchored in a customer situation rather than a feature label.
I also separate the underlying outcome from the proposed solution. Customers may care about recovering from a mistake, finding trustworthy information, or collaborating with less coordination. A request for a specific button is evidence about a problem, not automatic proof that the button is the best answer.
Design a paired question
A common Kano research pattern asks two questions about the same capability. First, I ask how the customer would feel if the capability were present. Then I ask how they would feel if it were absent. Response options can include “I like it,” “I expect it,” “I am neutral,” “I can live with it,” and “I dislike it.”
The paired structure matters because a positive reaction to presence alone does not tell me whether the capability is expected, optional, or merely interesting. The absence question exposes the cost of not delivering it.
I keep the wording concrete. “How would you feel if the product let you export a report?” is easier to answer than “How valuable is reporting?” I describe the capability without overselling it, and I test comprehension before collecting a larger set of responses.
A survey can provide directional evidence, but I do not treat a category assignment as objective truth. Interviews, support conversations, usability sessions, product usage, and competitive context help explain why people answered as they did. I record the segment, sample source, wording, date, and notable limitations.
Turn responses into a decision
After collecting responses, I group patterns rather than chasing a false precision. If most target customers treat a capability as expected, I ask whether the current experience clears the minimum acceptable bar. If it behaves like a performance need, I look for the dimension customers compare and define a measurable improvement. If it is a delighter, I test whether it supports a meaningful outcome or is simply novel.
I then combine the Kano signal with other decision inputs: customer reach, severity of the unmet need, strategic fit, confidence, effort, risk, and dependencies. A must-be item may deserve investment because it protects retention or trust, but the model does not tell me whether to fix it this sprint or next quarter. A delighter may be a good experiment rather than a full commitment.
I write the decision in a one-page brief:
- Target segment and situation.
- Capability being evaluated.
- Evidence and research limitations.
- Expected customer reaction if present and absent.
- Minimum acceptable experience.
- Guardrails, risks, and dependencies.
- Decision, owner, and next learning step.
This format keeps the Kano result connected to action without pretending that a label is a prioritization score.
Watch for changing expectations
The model is dynamic. Once competitors make a capability standard, customers may begin to expect it. Once a team teaches customers a new workflow, the absence of that workflow can become frustrating. I revisit important assumptions after launches, major market changes, and shifts in customer mix.
I also check for negative tradeoffs. A feature can add convenience for one group while increasing complexity, cost, latency, or risk for another. I segment feedback and pair satisfaction research with behavioral and operational measures. “Customers like it” is incomplete if usage creates errors or support burden.
Common mistakes
The first mistake is treating every feature request as a performance need. Requests often describe a solution while leaving the desired outcome unstated. The second is using a small or convenient sample as if it represents every customer. I label the audience and keep the conclusion proportional to the evidence.
Another mistake is assuming delighters are always strategically superior. A delightful extra cannot compensate for unreliable core behavior. Teams also misuse the model when they turn categories into fixed backlogs or believe the research removes judgment. It does neither. It improves the quality of the questions I bring to judgment.
A practical starting exercise
I choose one upcoming roadmap decision and list five capabilities connected to it. For each, I write the target segment, the likely reaction if present, the likely reaction if absent, and the evidence behind my assumption. I then test the two most uncertain items with a small set of customers or frontline colleagues.
The result is not a perfect taxonomy. It is a clearer discussion about expectations, tradeoffs, and what we need to learn next. That is why I use the Kano model: it helps me prioritize the experience customers are actually trying to have, not just the features that are easiest to request.
Next step
Build stronger product strategy, discovery, and prioritization skills in the Product Manager Certification. Subscribe to the Product HQ newsletter for practical frameworks and career-ready product lessons.
