Another great model coming from Japan, developed back in 1980 by Noriaki Kano. I was first introduced to it in a talk by Dr.Ari Zelmanow at the Denver Product Summit, and I was surprised that I had never seen it used in product development.
I find that this model is a great addition to the Stacey Complexity Matrix when it comes to the customer needs axis because it shows how complexity rises as customers become more or less satisfied with the features the product provides. Let’s jump into the model to see how to use it in product development.
The model has two axes: customer satisfaction on the Y axis, and needs fulfillment on X axis.
The general premise is simple: over time new exciting features become expected, and eventually even a minimum requirement for even considering to use the product. Which means that companies need to consider what to focus on with this in mind when developing their products.
EXAMPLE:
I often use an example of a mobile phone to demonstrate it as I explain the Stacey Complexity Matrix and it works perfectly here too. Back in 2001, I had my first mobile phone. It had a tiny screen, it was super heavy, and I could only call or text on it. I was extremely happy to have a phone because it was something brand new and it allowed me to do things I couldn’t do before. Now, I can’t imagine leaving my house without my smartphone connected to the internet, a GPS, and a number of useful apps. If you gave me the same phone I had in 2001, I would not even consider it a product I would ever use.
Using the Kano Model in Product Development #
No matter how good your product is right now, over time it will become less exciting for your customers. If your product has a big competition pool, then when certain features become available elsewhere, these same features will become a necessity just to keep your product in competition.
It means that any Product Owner should consider how market conditions and the overall business environment surrounding the product impact its functionality in the eyes of the customers.
Something that was previously just a nice-to-have suddenly may become a must-have. This means that the priority of the items in your Product Backlog will gradually change.
1. Collect feedback to help make decisions
You can use the following questions for each feature / PBI / user story to identify where it is on the Kano graph (source: Kano Model website):
How would you feel:
- (+) if feature X is implemented in the product or if there was more of feature X?
- (-) if feature X was not available in the product or if there was less of feature X?
For each question, the answer could include:
- Pleasantly surprised
- Expecting it to be that way
- Don’t care either way
- Not happy, but can live with it
- Disappointed & dissatisfied
Based on the answers, you can identify whether a feature is a must-have, nice-to-have, or somewhere in between.
In this case, the prioritization, if we use the MoSCoW model, would be (in the order of importance):
- Must-have features are self-explanatory. If you don’t have them, your product is not fulfilling even the basic customer needs.
- Performance is a must-have at a basic level but also increases as you enhance it. Identify what the basic level of performance is as a must-have. Additional improvements are should-haves as they can differentiate your products from your competitors.
- Attractive are should-haves as they can delight your customers and increase their loyalty. But beware that these features will quickly become expected going forward and if they are no longer available, you’re sure to disappoint your customers.
- Indifferent are could-haves and should be considered as the last thing on the list. Some of these features may be hidden attractive features, but you won’t know what customers really think until they start using them.
- Reverse and Questionable are won’t-haves. Don’t waste your team’s time on implementing these.
