Not all features of a product or service are of equal value. The Kano model is a concept for categorising and prioritising them. Using them we can distinguish between what we need to even do business, versus what will attract customers, versus what makes a market leader. I also give examples of how I’ve applied it to some of my engineering projects. It’s a good tool for task prioritisation.

🧭 Navigation

Overview

The Kano model is a tool often used in the Lean Six Sigma (LSS) project management methodology to enumerate and categorise customer requriments. LSS projects are divided in to 5 phases:

  1. Define the problem,
  2. Measure the current performance,
  3. Analyse the root cause,
  4. Improve the process, and
  5. Control the process.

In the Define phase, it is necessary to articulate the quality metrics of a product or service with respect to the customer. Often customers have many requirements, needs, and wants. They can often be subjective, and conflicting. A man named Noriaki Kano developed a conceptual model that can help categorise and prioritise quality features.

What Makes a Good (or Bad) Experience?

I travel a lot for work, so I’ve spent a decent amount of time in a variety of hotel rooms. I stayed in a cheap hotel recently (for a leisurely weekend away), and there were a few things that made it a dissatisfying experience:

  • Warm (not hot) water in the shower.
  • Toilet not flushing properly.
  • Faucet in the bathroom sink hard to turn on / off.
  • Hash browns for breakfast were partially cold.
  • Coffee was weak and diluted (I love a potent espresso in the morning).

What bemused me was how nonchalant the owner was about me having to open up the cistern to manually fiddle with it and flush the toilet every time.

Conversely, when I went to Japan in 2022 for a conference, I stayed at an incredible hotel in Kyoto.


A photo I took of the Prince Kyoto Takaragaike from the conference center.

Some of the things that stood out were:

  • An interior courtyard,
  • Western & traditional Japanese breakfast,
  • A bellboy who carried my luggage,
  • A koi pond outside,
  • A traditional Japanese teahouse,
  • Enormous rooms,
  • Beautiful scenery.


The view from my hotel room at the Prince Kyoto Takaragaike.

Clearly, there are minimum expectations we have about a decent hotel room, like functional plumbing. And there are things we would expect to get better the more we pay for it, like breakfast options, and room sizes. But there are also things that amaze us; koi ponds, tea houses, etc.

🔝 Back to top.

The Kano Model

The Kano model categorises features of a product or service in to 3 categories:

  • Minimum requirements: The bare essentials that you need to start a business.
  • Performance requirements: Enable you to compete with rival businesses, and generate profit.
  • Innovative features: Makes you a market leader.

We can plot this on a Cartesian graph with 2 axes:

  1. Customer satisfaction, ranging from dissatisfied to satisfied, and
  2. Level of implementation, from absent to fully implemented.


The Kano model conceptualises customer satisfaction versus level of implementation.

According to Kano’s conceptual model, minimum requirements must be implemented. But, no matter how much effort you put in to them, your customer will not be impressed. If they’re absent, however, or done poorly, your customer will be very unhappy. A hot shower is a hot shower, but a tepid shower on a cold, rainy day in England is awful!

Conversely, customer satisfaction increases proportionally to the level of implementation of the performance requirements. A bigger hotel room, and more breakfast options available? Yes please! And if they can be done for the same price, or cheaper, you will easily put your rivals out of business.

Innovative features (sometimes called delighters, or wow factors) are unexpected, but amaze the customer. A koi pond, and traditional Japanese tea house? Wow! These are features that can transform an industry. Free Wi-Fi at a hotel used to be an exciting feature, and distinguished a quality hotel from its rivals. Now, however, it’s become a minimum expectation. Innovative features often become minimum standards over time, especially if they can be done economically.

To help with determining the different features of a Kano model, I developed my own sorting algorithm.


My sorting algorithm for Kano model categories.

🔝 Back to top.

Examples

Underwater Robot

From about 2015 - 2018, I worked on the submerged pile inspection robot (SPIR) as part of my PhD. This was an underwater robot designed to clean marine growth off underwater bridge colums. In May 2017 I hosted a design worskhop with the team to review problems with the previous 2 prototypes, and what we need to do for the 3rd protoype.


The third prototype of the submerged pile inspection robot (SPIR).

We began by brainstorming all the kind of problems we had when working with previous prototype, and what we needed to improve. This included use-case scenarios like:

  • Assembly & maintenance,
  • Transportation, and
  • Operation.

We then used Affinity Diagrams to group ideas together based on common themes. This made the vast number of ideas easier to manage.


Brainstorming and affinity diagrams for the SPIR prototype development.

We sorted all these ideas using the algorithm above. We also added a few ideas of what would be really cool to implement (if we had the time).



The Kano model developed for the SPIR.

We each received $n = \frac{15}{3} = 5$ (number of ideas divided by 3) votes to place on what we thought was most important to work on. Notice that we did not vote on the basic features / minimum requirements. These must be done.

We can put these votes in to a Pareto chart to see what the team thought was most important.


A pareto chart of votes on the most important features to implement.

Note: This Pareto chart doesn’t follow the 80/20 rule very well, which implies that the features haven’t been adequately categorised or articulated.

At the end, we had a list of engineering specifications, and performance requirements. The basic / minimum requirements become a design checklist of things to be achieved. The weighted performance requirements then became a way to manage time, resources, and priorities.

To recap, the procedure we followed was:

  1. Brainstorm ideas based on each use-case scenario (Assembly & maintenance, transport, operation),
  2. Group with Affinity Diagrams
  3. Sort in to Kano model categories
  4. Prioritise non-critical tasks with voting

🔝 Back to top.

Humanoid Robot

In 2023 I was working for the Italian Institute of Technology (IIT) on the ergoCub robot as part of the Humanoid Sensing & Perception (HSP) team. We had to showcase our human-robot interaction module at the International Conference in Robotics and Automation (ICRA) in London. We had a very tight deadline, and a lot of different features to get up and running (decision trees, control algorithms, object recognition, software interfaces etc.).


The ergoCub robot can recognise a human waving, and respond.

I started by hosting a workshop with my team to review the performance of our previous demo at the start of the year. We brainstormed a bunch of ideas around 3 questions:

  • What did we do well (competitive features),
  • What can we improve (minimum requirements), and
  • What can we do to impress people (innovations).

You can see that I didn’t frame this explicitly as a Kano model, but there was almost a direct mapping. Afterward, we used Affinity Diagrams to group all these ideas in to common categories. This enabled us to assign responsibility based on subject matter expertise.



A brainstorming session for the ergoCub human-robot interaction demo.

After, we explicity categorised each of the tasks based on the Kano model. Like before, all the minimum requirements were things that we had to do. For the performance requirements, we used a Prioritisation Matrix1 to compare them all. This revealed where we should invest most of our efforts with limited time. We used this later as part of our project planning & monitoring.

Group Item Category
Action Recognition Incorrect action recognition when holding object (box, phone) Minimum Requirement
  Additional reactions beyond wave and handshake Extra
  Ability to change actions mid-task Extra
  Idle actions when nothing is happening Extra
Administration Book trip to London Minimum Requirement
  Plan with AMI to work on the robot Minimum Requirement
Behaviour Tree Behaviour tree not responsive (clarification?) Performance Requirement
Code Code works cross-platform (iCub2, ergoCub, Gazebo simulation) Minimum Requirement
  Successful communication over network Minimum Requirement
  Modules from different packages integrate successfully Minimum Requirement
  Code takes a long time to compile (separate .cpp from .h) Performance Requirement
  Load parameters from a configuration file Performance Requirement
  Use thrift communication instead of strings over yarp port Performance Requirement
Control Robot can execute joint control Minimum Requirement
  Robot can avoid singularities Minimum Requirement
  Robot moves quickly Performance Requirement
  Robot moves smoothly, naturally Performance Requirement
  Robot can jump over obstacles Extra
Grasping Robot grasps a box without it slipping Minimum Requirement
  Robot can grasp an object from given hand transforms Performance Requirement
  Robot can grasp box from different poses Performance Requirement
  The robot can grasp different objects Performance Requirement
  Robot can more accurately shake hands Performance Requirement
  Force control on the box Performance Requirement
  Hands can follow box as it moves Extra
  Collaboratively grasp and lift a box in a short time Extra
Hardware Demonstration runs on ergoCub Minimum requirement
  Ambient lighting affecting vision Minimum Requirement
  Hardware fails so we can’t use the robot Minimum Requirement
Head / Gaze Control Reliable human focus detection Minimum Requirement
  We can send commands to move the head Minimum Requirement
  Robot looks at & follows object Performance Requirement, Extra?
  Robot follows human gaze Extra
  Robot changes focus to different things in environment Extra
  Neck moves to stabilize head while walking Unnecessary
Marketing Live demonstration executes as planned Minimum Requirement
  Presentation summarizing research development Minimum Requirement
Navigation Robot can navigate successfully in simulation Minimum Requirement
  Navigation works on real ergoCub Extra
  Robot localizes without artificial landmarks Extra
Robot Communication Robot responds to voice commands Extra
  Robot follows human on command Extra
  Robot talks to people Extra
  Robot changes facial expressions based on actions Extra
  Robot can learn on the fly (clarification for this one?) Extra

To recap, the overall procedure here was:

  1. Brainstorm ideas
  2. Group with Affinity Diagrams
  3. Categorise with Kano model
  4. Rank non-critical tasks using the Prioritisation Matrix.

🔝 Back to top.

Key Takeaway

The Kano model is a conceptual method of categorising features of a product or service. It helps reveal the priorities you need to have a successful business, and can also be a great way to prioritise tasks in a project.

Some key lessons I’ve learned over the years are:

  1. If you’re having trouble thinking of features, try thinking about what makes a bad experience.
  2. Use prioritisation methods to rank the performance requirements by level of importance.
  3. Innovative features don’t have to be realistic; think laterally, be creative, challenge norms. That’s why they’re innovative.
  4. Integrate the Kano model with other tools:
    • Brainstorming & affinity diagrams
    • Voting method
    • Prioritisation matrix, etc.
  5. Innovative features migrate to minimum requirements over time.

🔝 Back to top.

  1. This is one of the Seven Management & Planning Tools. ↩