(Transfer) Kano Model: A Methodology for Product Managers

The Kano model is a tool invented by Professor Noriaki Kano for classifying and prioritizing user needs. It has a very high degree of fit with product managers. Therefore, such a tool invented by a professor from a non-product industry has become the tool of product managers. methodology.

The origin of the Kano model

What is the Kano model In

simple terms, the Kano model is a tool invented by Professor Noriaki Kano for classifying and prioritizing user needs. It fits very well with product managers, so such a non-product industry The tools invented by professors became the methodology of product managers.

The specific introduction will not be repeated due to the limited space. You can enter the complete keywords in Baidu "kano model" by yourself, otherwise the search results of "Kano" will appear.

Noriaki Kano is

an old man born in 1940, a Japanese educator, writer, and consultant. He was a professor at the University of Tokyo in 1982 and retired in 2006. Yes, Noriyuki Kano has nothing to do with the Internet and product managers.

Background of the Birth of the Kano Model

In the late 1970s and early 1980s, Kano Norishowa and his colleagues devised a new methodology for improving corporate services modeled after customer satisfaction, which eventually took his name , In other words, the orthodox name of the Kano model is: Kano model

When was the late 1970s? Around 1979, early 80's or 1981, we'll expand the scope, and the actual birth of the Kano model should be sometime between 1976 and 1985.

Under the background at that time, the Internet was still in the wasteland development stage and had not yet reached the application stage (my country realized a full-featured connection with the internet in 1994). Is this still the "Kano model" that you know and rely on? It is such a Kano model that seems to have no connection with the Internet, and now it has become the "Bible" of Internet product managers.

Definition of the Kano Model

Now that you know, the Kano model is not tailor-made for the Internet, nor is it a methodology tailored for product managers, so why not use it elsewhere?

After all, this will allow us to master this method proficiently, and only when we master it proficiently and have a deeper understanding of the Kano model can we apply it more effectively on the Internet and in our products.

In the Kano model, people's needs for something are defined into five levels, including: basic needs, expected needs, exciting needs, indifference needs, and reverse needs.

The so-called excitement demand is what we talk about "beyond expectations" part of the demand.

Let's take a look at the definition of each level:

basic needs

are also basic needs, natural needs, and functions that users think "must have".

Simply put, if there is "no", the user will be very dissatisfied, and if "there", the user will not be satisfied with it. After all, this type of demand is a "natural" demand.

For example, the requirements document is such a basic requirement for product managers. If not, your leader will probably be extremely dissatisfied with you, and if you do, he will not praise you for it.

Expected Demand

This type of demand is the opposite of basic demand. In simple terms, it means that if there is, the user will be satisfied, and if not, the user will not be disappointed.

For example, demand management, for us, is an expected demand. As a product manager, the better our demand management is, the more satisfied our leader will be. On the contrary, even if you cannot manage demand, he will not It will be dissatisfied with you, probably because of mediocre performance.

Excited demand

Excited demand is an upgraded version of expected demand in a sense. Sometimes we refer to exceeding user expectations and digging the hidden demand behind surface demand, which refers to the relationship between expected demand and exciting demand.

As far as the surface and the back are concerned, the expected demand refers to the user's surface demand, and the exciting demand refers to the real demand behind.

We still use the requirements document as an example.

Managing requirements documents is our surface requirement. Through the management of requirements documents, the team can be more efficient, more requirements can be reused, and the requirements can be changed as little as possible, so that the team's combat effectiveness can always be of effective value. This It is the need to excite the leader.

As a product manager, I believe that everyone is familiar with repeated requirements, changes in requirements, and missing requirements, not only our leaders, but even for ourselves, if we can really reduce repetitions and changes, it will also make We're excited, aren't we?

Undifferentiated

demand Undifferentiated demand refers to this part of the demand that does not matter whether it is provided or not, it has no impact on the user experience, in other words, even if it is not done, it will not make customers dissatisfied.

This part of the demand is often the "superfluous action" we want to avoid. Although it is said so, in work, we are extremely easy to do such a thing.

This case is a very classic, "login" and "login" When we write about "login" in the article, if we have emotions, it means that we will often spend time for undifferentiated things in our work. , after all, such a typo will not affect the user experience.

I need to emphasize that the so-called user refers to the person who uses a certain product. Taking the requirements document as an example, he plays a guiding and troubleshooting role in the development process, rather than reading an article. Therefore, the typo in the document is in the A certain range is allowed and accepted.

The reason for avoiding undifferentiated demand is that it consumes our precious and non-renewable resources.

Reverse

demand refers to minority demand. When we do demand analysis, we need to consider the usable area of ​​the demand, and when making priority division, we also need to consider it according to the impact area, so as to meet the needs of most people as the primary purpose, Contrary to this principle, there are reverse needs, which satisfy only a small part of the needs.

Reverse demand is also an upgraded version of undifferentiated demand. The so-called undifferentiated demand means that it does not matter whether it is done or not. The reverse demand is exactly what it belongs to, and if it is done, it will have a negative impact.

For example, during the requirement review, we discuss the content of a certain copy at the meeting, or the setting of a certain parameter. This is the reverse requirement.

In our team, most of the members don't care about copywriting and don't need to care about copywriting, only a small number of members will care about this issue.

The correct way to deal with it is to discuss issues that most people care about in the review meeting, such as the business logic of the function, or why a certain function is needed.

For some issues that a small number of people care about, similar to copywriting, they can be communicated separately after the meeting.

The above five types of requirements are the five-layer requirements of the Kano model as I understand them.



We take the basic needs as the origin, dig to the front, and demand ourselves with the goal of expected needs or exciting needs, and try to avoid the misunderstanding of reverse needs and undifferentiated needs.

Although the indifference demand does not matter whether it is done or not, in theory, it should be based on the indifference demand, but in fact, if we really do the indifference demand, it means that it will consume our time, and this part is There is no report on the time consumed, so when the indifference demand is raised, it has already had a negative impact.

Kano Model For Product Managers

At the beginning of the article, I have told you that the well-known Kano model is not a methodology unique to the Internet. In fact, the applicable area of ​​the Kano model far exceeds the area of ​​the Internet and mobile Internet.

When we talk about the five-layer requirements, if we use the case of a certain function, it will make it easier for everyone to understand, but this goes against my original intention. After all, the original intention of this article is to guide everyone in the direction of learning and growth. Introspection, that would be awesome.

Use the Kano model to reflect on our work:

Basic requirements: We want to output requirements documents
Expected requirements: We want to manage requirements
Excited requirements: Through requirements documents, improve team development efficiency and reduce inefficient time consumption? (Think about what level the requirements document we are writing now belong to?)
Undifferentiated requirements: After writing the requirements document, check it three times to ensure that there are no typos
Reverse requirements: During the review, we discuss how to write the prompt copy
Think about how much time we spend in indifference and inverse requirements.

It seems that the reasons for the gap have been said many times recently. Even the same start time, the same end time, and the same experience may produce a huge gap.

Same one year product time and doing the same thing. A is constantly doing exciting needs, while B is constantly doing basic needs. Let’s judge, who grows faster and who can seize the next opportunity?

Don't be satisfied with basic needs. This will only delay your time. Anything has basic needs and exciting needs, but exciting needs will be more difficult to dig out and find than basic needs.

This is just like the difficulty challenge in the game, easy, normal, and difficult. Under different difficulty, the experience and rewards obtained are also different.