Wondering why your customers don’t love your product anymore? Kano knows why!

Do you remember that product feature that customers absolutely loved when you launched it 5 years ago?

So why don’t the same customers rave about that feature anymore? And why did you receive so many complaints when you tried to remove it?

To find the answer to these questions, we need to ask Professor Kano!

Professor Who?

Professor Noriaki Kano is a professor of quality management at the University of Tokyo. In the 1980s he developed a model he called the ‘customer satisfaction model’. This model provides a framework for categorising product features based on the customer’s perception of those features.

In the Kano model, features are broken down into one of five classifications: Threshold, Excitement, Performance, Reverse and Indifferent.

These categories can be plotted on a chart, where the x-axis is the level of functionality and the y-axis, the level of satisfaction.

Let’s take a quick look at each of the categories.

Threshold

These features are the absolute minimum requirements that a customer expects. If they experience these features they are unfazed, but if the feature is not there. look out! A good example of this is a ‘password reset’ feature.

Threshold features predominantly play in the lower quadrants. This means that the level of satisfaction only really has scope to go from poor to medium, even if the level of functionality is high.

Delighter (or Excitement)

These are the opposite to threshold features. They are those that customers don’t expect and when they experience them, it delights them. This might be a gift or an intriguing piece of information.

Delighter features inhabit the top section. This means that even if the level of functionality is quite low, they will still satisfy the user.

Performance

These are the features that sit somewhere between threshold and delighter features. If they are there, customers are satisfied, but if they are missing then customers are dissatisfied. An example of this might be the way that a shopping cart experience works.

Performance features cut a line from bottom left to top right, taking on a more traditional cause and effect trajectory. That is, where more functionality is provided, the level of satisfaction also increases, and vice-versa.

If improving the functionality has an inverse effect on customer satisfaction, it is said to be a Reverse feature. Reverse features would cut a perpendicular line to performance features.

Indifferent

If a customer doesn’t feel satisfaction or dissatisfaction to a feature, it is said to be indifferent. That is, the feature has no effect on the customer, no matter how good or bad it is, or even if it doesn’t exist at all. An example might be the copyright notice that sits at the bottom of a webpage.

Which categories do my features belong in?

It’s worth noting that the same feature could be classified into any one of categories depending on the context of your product and what your users expect. This is the key — knowing your customers well enough to be able to classify the features. If you’re not sure — ask them!

Wait! Don’t ask them, “would you describe this feature as a delighter, performance or threshold feature”. You will need to do observational testing and ask them proxy questions as they use your product. Common questions to ask include:

• How would you feel if you had / did not have this feature?
• Rate your level of satisfaction if this feature was removed
• How much would you pay for this feature?

Back to the original question

Here’s the real kicker with the Kano model. Delighter features generally don’t stay delighters forever. Over time, customers’ expectations change, and they become used to and expectant of the features that used to delight them.

Let’s look at an example. You own a café and decide to extend your opening hours by 30 minutes each day. For the first couple of weeks, this extra half hour might delight a few customers, but take it away from them after that and how do you think they would react? You would have created an extra cost that now delivers you no added business benefit. To make matters worse, if you then chose to reduce the hours again, the change’s negative impact is likely to outweigh the original goodwill — resulting in an overall net negative impact.

After we’ve placed our features into one of the categories, we need to ensure that we later keep revisiting the model and update the categories where necessary. Meanwhile, it’s an interesting exercise to analyse how a feature descends over time and how different features deteriorate at varying speeds.

Which category of features should I prioritise?

A common approach to prioritisation is to start with the threshold features first. When these have all been completed, we then work our way to performance features, before finally delivering some delighters. The problem with this strategy is that a backlog of threshold features can often be never-ending. Development teams can easily spend all their time fixing bugs and never make it to performance features, let alone delighters.

A strategy preferred by man is to prioritise features from each of the categories in parallel. You may have seen this visualised as a pyramid where we can shave of slices for each release.

For example, in one release you may choose to prioritise these three features:

• a critical bug fix (threshold)
• a UX navigation improvement (performance)
• a collection of new slick micro-animations (delighter).

Another consideration when prioritising delighter features is how quickly they will deteriorate to performance or threshold features. In the café example above, the feature deteriorated within a few weeks, whereas in other cases, a feature may remain as a delighter for years. You are going to want to choose delighter features that will have longevity in this category, as well as a low upfront investment and minimal ongoing costs.

• Have you used the Kano model to prioritise your features?
• What other prioritisation techniques do you use?