Increase Customer Satisfaction With the Kano Model

JAN 15TH, 2012

A couple of weeks ago I had a great discussion with one of my colleagues about the Kano
model and how we could use it to make better deliveries. The model itself is a classification of features of a
product based on customer needs and attributes.It was created by Professor Noriaki Kano (on the right) in the
1980s. Professor Kano defined three different feature categories: basic, performance and excitement, which are
represented on the diagram below. The x-axis defines the effort put into the execution/implementation of a
feature, and the y-axis defines the customer’s satisfaction after receiving the feature. In the software industry
poor execution can result in a faulty or unusable product.

The presence of the features belonging to

the basiccategory which presence has no positive effect on the customer’s satisfaction - bottom right corner -,
but they are must have features, so their absence or poor quality causes huge dissatisfaction - bottom left
corner. Let’s say we are about to create a web shop. It is a must have feature to make it possible for a customer
to sign up to the site. Even if it’s the most sophisticated sign up feature, for the users, it is just a sign up feature,
but without it or with a faulty one, they cannot use the site, so they’ll leave. Satisfaction in the features
categorized asperformance is proportional to the quality in which the features are implemented/delivered. Let’s
say we introduce Facebook as an alternative sign up procedure. It isn’t a must have feature, but it will increase
the customers’ satisfaction in the project: the users can use their existing accounts, and we don’t have to store
user data unnecessarily. After Facebook we introduce twitter as the next alternative. It has no effect on the
existing users but may attract more customers. The last category is the excitement which is the complete
opposite of the basic category: the presence of anexcitement feature drastically increases the customers’
satisfaction, but nothing happens when it is not there or doesn’t work as expected. For example, we introduce a
feature which allows customers to use our shop without signing up, just using their email address and PayPal. If
it’s available, the users will be excited to use this great convenience feature, if it’s not, they won’t miss it
 That’s all about definitions, now let’s see how to turn the
Kano model to our advantage. First, always have an excitement and a performance feature in your delivery
and not just basic features, and second, revise the classification after each
delivery and prioritize accordingly. Mixing categories (e.g. basic with excitement) in deliveries actually helps
selling the product. Let’s say we deliver only basic features. Then, according to Kano our customer will never be
satisfied, because we never leave the bottom of the diagram. For example, when we delivered a sprint backlog
which contained only basic features, our customer was somewhat satisfied, but always had improvement
proposals. However, when we added an excitement feature, even if it was prioritized lower, the customer
always said ”this is what I’m talking about!”. Excitement features are expensive, but they attract more
customers and they differentiate you from your competition. Unfortunately, a performance feature is not
enough, because if you execute it poorly, you stay below the “satisfied” axis, although you’ve spent
a noticeable effort on it. I’m aware that taking a less important item is against every possible rule, but when our
customer is satisfied, her customers will be satisfied too, which is actually a good thing, so when you are setting
up a release plan, an iteration backlog or a package, always plan to include an excitement feature, even if it is
a small one.

Another interesting example: I met a product owner who wanted an excitement feature very very soon, even
before the first beta release. Everybody, including her, knew that the feature is useless, but she was pretty sure
that its presence would attract more customers who would never use that feature but would stay on the site
because of the other excitement features we already have, but they don’t know about them yet. Time will tell
whether she was right or not, but nevertheless it is a very interesting idea.

Do not forget to repeat the classification before each iteration or sprint. Nowadays, the business changes fast
and it can happen that a feature which was marked as excitement yesterday becomes aperformance or
a basic today. In the example above I categorized the Facebook login as performance, but before the first web-
shop came out with a Facebook sign in feature it was an excitement. Soon after it appeared it
became performance for everybody else, and nowadays it is a basic. So as it is written in the book, revise your
feature set or product backlog, and set the new categories according to the recent business needs.

In the beginning I mentioned that the effect of a certain feature depends on the execution/implementation of
that feature. I think it is not enough to categorize the features as basic, performance or excitement, but you
need an additional number which limits how much time can be spent on the feature. For example, a team could
spend weeks on a basic feature, because they want it to be perfect, but according to Kano they’ll never step
across the x-axis and make the customer more satisfied.

Fuente: Zsolt Fabok