
This article is derived from [the complete guide to the kano model - folding burritos] (the complete guide to the kano model - folding burritos), based on the original text of the translation, escaped, this article intercepts the more core content for readers to quickly read, understand kano.
As a product manager and project manager, you must have encountered such problems:
No matter how fast you make, the list of requirements keeps increasing
Users seem to want everything, but it is impossible to develop and go live with all the features
You make a product roadmap so that everyone knows the order in which the requirements are implemented, but there's no way to start
Faced with these problems, you need a method of requirements sorting to help you, and kano is exactly one method you can refer to.
Satisfaction vs Functionality
When it comes to kano, the first thing to understand is kano's "satisfaction" measure. "Satisfaction" is used to measure the user's satisfaction level after a certain requirement is realized. Specifically, it can be divided into the following levels:
Another important measure dimension is Functional Well-being. "Functional perfection" is a measure of how well a feature is implemented. It can be specifically divided into the following levels:
Kano core classification
Once we understand these two measure dimensions, we can introduce the core concepts of kano. Based on the above two measure dimensions, we can form a quadrant. Through this quadrant we can understand how users perceive the functionality of the product.
Through the combination of the two dimensions of "user satisfaction" and "functional perfection", we can divide four different types of requirements:
Essential: If there is no such function, the user will think that this is an unfinished product and cannot be used. This kind of functional requirement belongs to the basic needs of users, and no matter how well this kind of function is done, the user's satisfaction will not increase. However, if this has this feature, the product is not available. For example: a car needs to have brakes; a phone must be able to make calls. For this kind of demand, when it reaches a certain level, you don't need to invest too much.
Expectation type: This kind of demand is very compatible with the user's expectations, and the higher the degree of realization of this type of demand, the higher the user's satisfaction. For example, the farther the car travels, the higher the user's satisfaction; the more storage capacity the mobile phone, the higher the user's satisfaction. For this type of demand, every time the function is improved, the user's satisfaction can be improved, and the investment should be concentrated.
Excitement: Have you ever tried using a product and exclaiming that the design of the product is so clever and how they did it? Functional requirements that trigger such exclamations are excitatory needs. For example: the first time you use an iPhone, Google, Baidu Maps. For this kind of demand, it will become the highlight of your product and the point of differentiation, which can greatly improve user satisfaction, but at the same time pay a lot of research and development costs.
Indiscriminate: The presence or absence of such needs is inconsequential to the user. For example: Have you ever worked hard to implement a feature that no user uses at all? This is an indiscriminate requirement. For such needs, avoid investing and shift your energy to other categories of needs.
Once we understand the requirements classification of kano, the classification of these requirements can guide us to sort the requirements based on different requirements categories:
How does it work?
After understanding the basic recitation of coming to Kano, we can perform the practical operation of sorting kano requirements according to the following steps.
As a first step, select the requirements and users you want to sort
There are often different categories of demand in our demand lists, some of which are related to the end user, some of which are operational, management-related (e.g., sales reports), and some of which are technical debt.
The kano method is more suitable for the needs directly related to the end user, that is to say, these needs should be directly perceived and operated by the end user (rather than for the operation personnel and management of the product), because the requirements directly related to the end user can bring the greatest impetus to the development of the product.
The second step is to ask the user a question and get an answer
This is a crucial step for Kano. How to ask questions to users and how to collect user responses will directly affect the results of the requirements sorting.
Kano defines a pair of simple, clear questions. For each requirement, we ask the user a question:
What would you think if this feature was added to our products?
What do you think if our products don't have this feature?
As you may have noticed, the above two problems are one of "functional" situations and the other is "lack of functionality". For the above two questions, we let users choose from the following answers:
Very good
Not bad
Doesn't matter
Not so good
dislike
In addition, for each function, we also ask the user a question:
How important is this feature to you?
You need to guide the user to choose between 1-9 (1 is unimportant and 9 is extremely important).
The third step is to analyze the answer results and complete the ordering of requirements
Based on the user's response, we can quantify the results to facilitate the subsequent sorting process. The specific quantification process is:
Based on the results quantified above, we will get the following table. In this table, we'll focus on the positive answer (i.e. the part of >0), which helps us focus on the most important needs.
Based on the table above, we calculate the following scores for each requirement:
Score for a "Featured" question: Calculates the average score for the question for all users
Score for "Missing feature" issue: Calculates the average score for the question for all users
Score for Feature Importance question: Calculates the average score for the question for all users
Based on the scores for the "Featured" questions above and the "Missing Features" questions, we can aggregate our requirements for requirements ranking analysis in the following graph:
In the image above, we overlay the score for "Functional Importance". For better visualization, we will adjust the size of the midpoint in the above figure according to the importance of the requirements.
Based on the above results, we can sort the requirements according to the order of necessity> expectation> excitatory > indiscriminate:
If there are multiple requirements under the same category, we will sort them additionally according to their importance. At this point, we have a sorted list of requirements according to the kano method.
Write at the end
Kano provides you with a requirement sorting method that can be used as a reference and executed. But the kano method also has its limitations:
Feedback from different categories of users (end users, internal users) cannot simply be sorted together, and stakeholders need to judge
The priority level of "expectation" requirements may be higher than that of "essential" in some products
The division of demand types will change over time, for example, the iPhone was an "exciting" demand in 2007, but it has become a "necessary" demand today
In short, how to use the tool, or according to the specific situation of the project and product to adjust. there are no silver bullets。