Check out our latest free video – 4 steps to incredible story maps Watch now

Kano Model

The definition of Kano Model

Background

In the 1980s a quality management educator named Noriaki Kano created a customer satisfaction framework that ranks various levels about how customers perceive the quality of a product over time. This is now known as the Kano (pronounced “Kah-no”) Model.

Definition

The Kano Model is a product-development/quality-assurance approach to ranking what features to build based on their ability to satisfy or delight customers.

There are five categories these functionalities can fall under:

  • Basic (Must Be): Customers expect this functionality. When done right, customers are neutral. When done wrong or not at all, customers are dissatisfied. These functionalities typically constitute the “Minimum Viable Product” (MVP). Basic features should be considered top priorities or else customers will quickly find alternative products.
  • Performance (One-dimensional Quality): When done right, customers are satisfied with this functionality. When done wrong or not at all, customers are dissatisfied. These functionalities are explicitly requested requirements from customers.
  • Excitement (Attractive Quality): This is functionality that delights customers but these customers don’t expect it and are therefore not disappointed if it’s not present. Usually this is the unspoken “I’ll know it when I see it” functionality. Excitement functionality can quickly become Basic functionality within a short period of time as customer expectations shift.
  • Indifferent (Indifferent Quality): This is functionality that customers don’t care whether the product has or not. Dissatisfaction (Reverse Quality): This is functionality that customers hate.

How the Kano Model applies to product development

The number of items to work on in a product backlog can be limitless. Deciding what to focus on next can be daunting. The Kano Model provides a strategic system to classify the long-term trajectory of what particular development efforts will result in.

In general, Basic, Performance and Excitement functionality should be considered while Indifferent and Dissatisfaction functionality should be ignored.

Real-world examples

  • For a short time after air conditioning came out in vehicles, it was an Excitement feature but has since become expected by customers (aka Basic feature).
  • Hotel WiFi quickly went from being an Excitement feature to a Basic feature. Autoplaying videos that are not a part of a user’s viewing journey is a Dissatisfaction feature to many users but is also an Indifferent feature to others.
  • Phone battery life is usually a Basic feature because customers are neutral when it works but upset when it doesn’t. If someone were to create a longer lasting battery it could also become a Performance feature for a time.
  • A vehicle’s gas mileage can be a Performance feature because customers are satisfied with high gas mileage but dissatisfied with low gas mileage.
  • TV manufacturers were building and marketing 3D TVs until they found out that, for the most part, customers were Indifferent about the functionality.
  • A video’s playback speed controller is becoming a Basic functionality for video apps as more users expect to be able to watch or listen to videos at faster speeds.

Henry Ford famously said that “If I had asked people what they wanted, they would have said faster horses.” This is a great example of an Excitement feature. Customers did not expect affordable vehicles but when they became available, they were delighted.