The Kano Model and Prioritisation

15 June, 2020 - 5 min read

In a past assignment, the business stakeholders had previously used a "Version 1, Version 2, Version 3" approach to prioritisation. Budget constraints and a very Project focussed approach to budgeting (as opposed to Product focussed) had driven a rescheduling of versions. Understandably, the stakeholders had grown weary of this approach to planning when "Later" turned into "Never" in their view. It made features prioritisation difficult, since all features were now seen as highest importance.

In order to get the backlog to a healthy, manageable state, a change of perspective was required. The solution came by introducing the Kano Model, and reframing the discussion in terms of the User's perception. This enabled the Business Stakeholder and the Product Owner to get passed their previous experience, and improved clarity as to how priorities should be set.

The Origin

Invented by Dr N. Kano at the Tokyo University of Sciences in 1984, the model refocusses the understanding of the Product from a set of features to ways of generating User satisfaction. Through this, it enables prioritisation of upcoming features and gives insight and clarity into how to bring Users satisfaction. Beyond that, it also shows what features will bring delight and differentiate the product positively from its competition.

Data driven

By measuring User satisfaction through questionnaires and ranking features according to two dimensions (self-explanatory Satisfaction and Investment, or degree of implementation sophistication), the Kano Model defines categories to sort features.

Category Migration

As you might have already noticed, some of the examples I used no longer hold true. This is due to the evolutionary nature of User's perceptions. For example, when the early personal computers appeared, they only supported a text interface.

Commodore 64 homescreen

Above, some nostalgia for those of you old enough to remember ;-) That should give you a ballpark to guess my age.

But a few years later, the first Graphical User Interfaces was introduced, and revolutionised the industry. Nowadays, almost no-one but the geekiest would consider using text input as their main way of interacting with a computer. The GUI has moved from Delighter to Must Be. Similarly, once completely indifferent, the gas consumption of airlines is coming into focus more and more with the rise of traveler's environmental concerns. What was an Indifferent aspect is nowadays migrating to the Reverse category.

Conclusion

In essence, the Kano model gives an approach to identify the features that will offer the best return on investment for the Product, and provide another valuable tool to the Product Management community. I hope you now have a clear(er) idea of what it is, what its categories mean and what value it can provide to the Product Backlog clarity.

There is more to say about the topic, but I feel this already provides a good overview of the Model. I will certainly revisit the topic in a later instalment, for example to dive deeper in some of the practical aspects, such as how data is gathered. If you have additional questions or suggestions, feel free to leave a comment bellow :-)

Thank you for your time, I hope you enjoyed reading this as much as I did writing it :-)

If you are interested in more articles like this and wish to be notified of new publications, please subscribe to my RSS Feed.