Product Information Support: KANO Special Practice

The classical approach obliges the project manager, in an accelerated mode, to prioritize tasks using the categorization of requirements based on the Eisenhower classification. The result of all this “prioritization” may be loss of profits, loss of competitive advantage and 100% satisfaction with the project manager’s process. Another thing is when the team implements the requirements that the client is ready to accept with delight!
I want to warn people like "snolligoster" that they can not read this topic, so as not to injure their psyche.
To everyone else: Welcome to the new world!

For me it is absolutely not clear why you need to deal with prioritization, if the client needs to implement the requirements, and not in what order you implement them. Therefore, the “prioritization” in the classical form, and even more so in an accelerated mode, makes the project manager the “weakest link” in the project, while reducing your “bus number” to one.

As a result, such important tasks for the implementation of requirements that are not interesting for the client or meaningless to him can appear as important and urgent:
1) I will like it if these requirements are not implemented, and if the team does implement them, then for me it will be the expected result.
2) I will like it if these requirements are not implemented, and I am indifferent to the fact that the team still implements them.
3) I will like it if these requirements are not implemented, and I accept the fact that the team still implements them.
4) I will like it if these requirements are not implemented, and I don’t like it if the team still implements them.
5) It will be expected for me if these requirements are not implemented, and I will not like it if the team still implements them.
6) I am indifferent to the fact that these requirements will not be implemented, and I will not like it if the team still implements them.
7) I accept the fact that these requirements will not be implemented, and I will not like it if the team still implements them.

It’s another thing if the customer is delighted when the team implements the requirements in the new product:
1) It will be expected for me if these requirements are not implemented, but I will be delighted if the team still implements them!
2) I am indifferent to the fact that these requirements will not be implemented, but I will be delighted if the team still implements them!
3) I will accept that these requirements will not be implemented, but I will be delighted if the team still implements them!

General information

The main ideologue of customer satisfaction analysis is Noriaki KANO Professor Emeritus at Tokyo University of Science. KANO analysis helps the Agile team understand which of the parameters of a product or its qualities will prove to be a significant distinctive advantage in the IT market, and also helps to manage customer satisfaction.
')

Technology description

The greatest effect from the use of KANO-analysis is achieved while providing information support for the flexible development of a commercial product (product).
This technique allows you to identify the key features that will have the greatest impact on customer satisfaction, or those that will be extremely important, and their absence can lead to complete customer dissatisfaction. All this allows the team to identify the most significant functions before the product is released to the market.
KANO-analysis should be done by analysts who can use it to evaluate the parameters of products in two axes:
1) The degree of implementation of the functionality of the product;
2) The level of customer satisfaction on the degree of implementation of a particular function in the product.



Thus, we obtain a 2x2 matrix in which the product profile should fall into one of three categories:
- Typical requirements (key factors);
- Performance requirements;
- WOW-requirements.
The fourth neutral category (Indifferent) is an insufficiently perfect implementation of functional characteristics that cause customers indifference to the product.
KANO analysis allows you to determine the characteristics that give the product a unique position in the market.

Typical requirements (Threshold):

Typical requirements include the functionality that is absolutely necessary for interested parties to consider accepting a product. The absence of standard requirements will cause intense discontent, but since they represent the minimum acceptance criteria, their presence will not allow an increase in customer satisfaction beyond a certain low level.
Usually there is the problem of identifying such requirements, as the client tries not to think about them, and the analyst has to explicitly ask the client about them.

Performance Requirements (Performance):

Performance requirements include those that are characterized by a steady linear growth in customer satisfaction. The bulk presents the features that customers expect to see in the product (speed, ease of use, etc.). These requirements most easily come to mind for most stakeholders.

WOW-requirements (Exciters):

WOW requirements are those that significantly exceed customer expectations or represent what was impossible for a customer. Their presence can significantly increase customer satisfaction over time. Since products with similar requirements are unparalleled in the market, stakeholders are not inclined to think about describing the requirements for them.

The practical part.

In order to determine the category to which a requirement belongs, which describes a particular characteristic or function of a product, it is necessary to clarify the client’s vision in two forms:
1) In the functional form - ask to describe his attitude to the fact that the proposed requirement will be present in the final product.
2) In dysfunctional form - ask him to describe his attitude to the fact that the proposed requirement will be absent in the final product.
The client expresses his vision in functional and dysfunctional form in the form of the following statements:
- I like this way;
“I expect it to be that way;
- I am neutral to such a requirement;
- I accept this path;
- I do not like the chosen path.

The definition of categories is based on the presentation of assertions on both forms in the following grid. The top line represents the answers to the dysfunctional form, and the left column represents the answers to the functional form:

Thus, there are requirements that require clarification (Q - Doubtful answer; R - the answer does not make sense), as well as typical requirements (T), performance requirements (P), as well as WOW requirements (E) and neutral (I).
This approach aims to identify requirements that encourage widespread use or acceptance of a product. The category of the requirement may change over time, as customers expect the growth of expected implementations of new functions in the presented product, rather than a decrease in its functionality from time to time.
Also, WOW-requirements may eventually become standard requirements, the implementation of which the client waits on a mandatory basis. As an example of the evolution of typical requirements, we can cite the presence of a solar panel control system on a spacecraft:


PS: The following information materials were used in writing the article:
1 Agile Extension to the BABOK Guide
2 Here are these pictures to create a collage:
2.1 upload.wikimedia.org/wikipedia/en/f/f0/Kano_mortal_kombat_2013.jpg
2.2 trueimages.ru/img/b4/80/0e7f0f1b48286b6038d84741b05.jpg
2.3 www.federalspace.ru/img/news/resurs_dk.jpg
2.4 upload.wikimedia.org/wikipedia/commons/b/be/Sputnik_asm.jpg