Written by Mateusz Jaracz
Department Manager
Published March 25, 2015

Not sure which features really matter? Let’s try to put the things in order.

Among many tools for product managers, designers and UX developers, there is one modeling technique which might turn your product’s scope into a more measured set of features – at the same time providing more value as well as predictable customer feedback.

Kano model

The model – developed by Noriaki Kano in 1987 as result of customer loyalty investigation and crucial factors that contribute to them – classifies product futures and their impact the customer satisfaction.

It’s important to note that while some futures can deliver high rate of satisfaction – the lack of one feature can cause high rate of dissatisfaction which might have damaging impact of the product as a whole – simply because, according to Kano, the features belong to different groups. A phone with configurable alarm clock does not increase the satisfaction a lot – at the same time the lack of configurable alarm ring can put the product into the doom.

Let´s try to analyze the groups selected by the model author:

Basic features

Basic features (or threshold features) – can be seen as the parts of the system customer expect to be there.

They are obvious, implied – at the same time important and must be implemented in the system (the original name was must be requirements). The customer takes them for granted – not always asking directly. Poor implementation can damage the expected satisfaction.

Brilliant execution however does not delight the customer that much and will only lead to not dissatisfied state. Also, if we are competing on the market that’s not the group we should put an afford on. The examples might be:

  • a radio in the car – we all expect the radio to be working and does not provide any problems for the driver – the poor, braking, noisy radio can damage our dissatisfaction.
  • Change password functionality in the application – that’s something we all expect to be working. Lack of this future can frustrate the users while there is not great excitement when the implementation is perfect.

Both futures above that’s not the place in the system where we want to put an effort when competing with others or innovate.

Before we start with the next group let’s try to visualize the groups on x,y axis where:

x represents the level of implementation (not implemented, partly implemented) – let’s call it execution or quality of execution. There are different model representations where we also can use the budget, investment as the variable of customer satisfaction.





Performance features

The group describe the basic needs of a business. Usually, that’s the main features of the system which can be easy define by a customer, describing his expectation when it comes to functionality. In many cases – as a whole they define the system. Poor implementation leads directly to dissatisfaction – good implementation however, can significantly increase satisfaction. The examples can be:

  • Fuel consumption
  • Battery time in the phone
  • Screen size in the phone



Those requirements (in many cases) are critical when considering buying the product. If their implementations vary too much from what was promised – dissatisfaction level will increase. The better the implementation though (lower consumption, longer battery time, better screen brightness and resolution) the more significant boost we can see in customer satisfaction level. This is also the area where innovation and competition should be executed – as there is strong, positive correlation between the execution and satisfaction.

Excitement features

The group of requirements which (very often) customer is not aware of – but – when present – the satisfaction can be increased. They are also called delighters or nice to have features. If they are missing – there is no satisfaction decrease as they can only make the product more attractive (if implemented well). Very often there is no direct request for those types of system functionalities – leaving engineers space to improve, groom and make the product better.


There are also two last groups of product features worth mentioning which are: indifferent requirements and reverse requirements. The first group defines the set of features customers simply don’t care about. We can pretty much assume this feature is not in use and can be the good candidate for removal. The example can be old, rarely used drivers for old school printers in kernel.


The last group are the features which (if present) will directly increase customer dissatisfaction. They are the strongest candidates to remove from the product – an example can be U2 last album in iTunes store. This future, well executed, has disappointed many customers – as a result Apple has provided the way of removing U2 album from the store (which might be consider as new performance feature).


Kano model can be find useful in many areas of product development (especially in the planning phase). Can help – in particular – with requirements understanding and their impact on the customers prioritization and release planning – also on the impact they made on customer positive perception of the solution.

Written by Mateusz Jaracz
Department Manager
Published March 25, 2015