Product backlogs are constantly refined, groomed, added, corrected. While every Product Owner/Product Manager has his own vision and his own way to maximize the backlog value, the Kano Model supports a quantitative process for evaluating and prioritising the features to be included into the backlog. I’ll show you how to use the model, and how to write an R script to classify the product features accordingly to the model. (next post)
The Kano Model
The model classifies any product feature into five categories:
- Performance. That’s the customer top of mind option when evaluating the feature. These features generate customer satisfaction in a linear way. The more you’ve got, the better. Conversely, the worse they are executed the worse the customer satisfaction, i.e. a PC processor speed.
- Required. These features are taken for granted and create dissatisfaction when missing or when execution is poor. They are basic, must have features, so they do not provide differentiation and do not create great satisfaction even when properly executed, i.e. ABS system in a car.
- Delighters. These are exciting, attractive unexpected and innovative features that bring excitement when there, but do not create dissatisfaction when absent because, well, they are by definition unexpected, i.e. the for free flute of champagne at your arrival in hotel.
- Indifferent. Customers don’t care about these features, and neither should you, i.e. the visualization of “editing time” in Microsoft Word.
- Reverse. You don’t want any of these features in your product: they create dissatisfaction when there, and satisfaction when not in there, i.e. the infamous Clippit assistant in older versions of Microsoft Office.
There’s another category, originally not included in the Kano article: Questionable features. Items in this category have contradictory feedback from customers and are probably the result of incorrect phrasing or presentation during the survey. More on the survey in the next paragraph.
Finally, it has to be noted that features will drift, changing places on the model over time. That’s because once unexpected features tend to become expected and taken for granted over time.
Also worthy of note that feature categories are not black&white in/out spots. Every customer will judge the same feature in a slightly different manner. You have to search for trends.
Kano Analysis – the Survey
But how do you get your product features classified? You survey your customers with a pair of questions for any product feature you want to inspect. Questions are in the Functional/Dysfunctional form.
So, imagine you’ve got to evaluate three features for your soon-go-to-market car-sharing service:
A) GPS on the car
B) Freeride on drivers birthday
C) Trivia Contest before starting the ride (free ride if you win)
You should survey your (potential) customers about the three features with a pair of questions for each feature:
A) Functional
How would you feel if THERE WAS a GPS navigator in your car sharing vehicle?
[ ] I would like
[x] I expect it
[ ] Neutral
[ ] I can live with it
[ ] I dislike it
B) Dysfunctional
How would you feel if THERE WASN’T a GPS navigator in your car sharing vehicle?
[ ] I would like
[ ] I expect it
[ ] Neutral
[ ] I can live with it
[x] I dislike it
and so on. You rank each answer as follows: Like=1; Expect =2; Neutral=3; Can live with it=4;Dislike it=5
After surveying a wide, well-constructed sample of your target segments, the outcome of the survey could be a txt file with the following structure:
- Feature;Functional Rank; Dysfunctional Rank
- A;1;5
- …
- …
You are now ready for building the category table, a matrix summing up all the answers for each feature and each Functional/Dysfunctional pair outcome. You then compute the total count of the answers received at any Functional/Dysfunctional intersection point.
Classifying the product feature in the right category
From this point on, you have different choices to weight the answers.
For instance, you could take the highest count, i.e. Functional Like and Dysfunctional Like and use it to classify the feature. In the example above the feature is classified as a Performance one, because that’s where you’ve got the highest count (45).
In a second approach, you could further aggregate the calculated count, grouping it by category, i.e. you will aggregate all the count (intersection of line and columns) for the Delighters, Indifferent, Must-Have, Reverse categories.
In the example:
- Delighter= 23+32+15=70
- Must Have = 15+18+23 = 56
- Reverse = 2+5+5+2+3+1+0=18
- Indifferent = 9+4+2+7+11+7+4+5+13=62
- Performance = 45
- Questionable = 1
With this approach the feature is classified as Delighter.
As already mentioned, there are not black and white borders and we have to look for tendencies. It’s important that we focus on the three categories to be included in the product, knowing that the success of the product depends on the right implementation of those features.