Born in 1940 in Tokyo, Japan, Noriaki Kano is a professor, lecturer, and writer; but he’s best known as the creator of the customer satisfaction tool, the Kano model.
Thanks to his work developing this tool, Professor Kano is now recognized as a global leader in the field of quality management and customer delight.
Kano spent the majority of his career at the Tokyo University of Science, where he is now a professor emeritus. It was here that Kano and his colleagues developed the Kano model in the 1980s, building the foundations for a methodology that is still used by product teams across the globe to this day.
Professor Noriaki Kano has won numerous awards, including the 1997 Deming Prize for Individuals. He is also an honorary member of three different academic societies: the International Academy for Quality (IAQ), the American Society for Quality (ASQ), and the Japan Society for Quality Control (JSQC).
Much of Professor Kano’s expertise in the field of quality management has been documented in his 1996 book, Guide to TQM in Service Industries. The book outlines the real-world application of Total Quality Management (TQM) using several Japanese companies as examples. Its aim is to streamline and optimize the manufacturing process and align it with the customer experience.
Despite these many accolades and accomplishments, there’s absolutely no question that Professor Kano is best known for creating the Kano model.
After all, he put his name to it!
The Kano model was built on the premise that a product’s roadmap should be organized based on features that are most likely to impress or delight the user. In this way, product teams can ensure that their product is always focused on customer satisfaction.
The Kano model framework helps product teams prioritize their roadmap based on the metric of customer delight. This is in opposition to the more conventional approach, which may focus on maximizing the total number of users, or the amount of revenue the app brings in.
This isn’t to say such goals aren’t relevant (they definitely are). But Kano argued that, especially in the early stages of the development process, ensuring a great customer experience is more important.
Because customer delight is something of a subjective measure, the Kano model is based on a standardized questionnaire. The answers to this questionnaire are then used to sort product features into five different categories of quality:
Must-be quality: This refers to the absolute basic features of a product. The fundamentals. Without the features in this category, the product would not work.
One-dimensional quality: This category refers to features that make customers satisfied when they’re delivered well, but dissatisfied when they’re not. A good example of this could be reasonable loading times in a web app.
Attractive quality: These features are those which make customers happy when they’re available, but won’t necessarily be missed if they’re not. For example, picking up where the user left off last time they used the app. These features are essentially nice-to-haves.
Indifferent quality: This group of features sit right in the middle ground. They create neither satisfaction or dissatisfaction. Examples might include the width of a particular button or the specific shade of gray used for drop-shadows.
Reverse quality: These features are effectively surplus to requirements. They’re features which, when included to excess, might actually cause users to stop using the product or look elsewhere. For example, if you interrupt a user’s workflow frequently with “helpful” tips.
Despite being over thirty years old, the Kano model is still employed in many industries today – especially in software and product development.
One of the biggest reasons that modern product teams find the Kano model so useful is that it can almost immediately prioritize a roadmap and offer a level of reassurance that customers will like the end result.
This can be of particular value in situations when time is tight on a project. In such cases, too much time spent on the wrong features during development can have severe consequences as deadlines approach.
Likewise, if a product team is relatively new to the type of development they’re doing (making a mobile app rather than a native one, for example), the Kano model can help them better understand customer needs. Because the results of the Kano model also focus on rationale, applying this methodology can actually help educate a product team as to exactly why users like certain features and not others.
The result? A product team that just gets better with age.