Why prioritize?

Prioritization is the process of ranking/ordering a set of items in order of importance. The Product Backlog, being one of the key artifacts in Agile-based frameworks, such as Scrum, must be constantly prioritized to capture the items with the most value on top.[1] In a scaled environment it is essentially the same – (enabler) features on the program backlog and (business and enabler) epics on a portfolio backlog must regularly be prioritized.

But why do we need to prioritize in the first place? The answer to this question is simple: in many cases, demand is higher than supply or available capacity. From a product management point of view, this means that product managers and product owners must prioritize their backlog items because they do not have unlimited resources and time. In practice, it is not possible to employ unlimited trained and talented people that deliver instantly. That is why prioritization is a key skill for success.

The main challenge with prioritization though is to decide what is most important. As Don Reinertsen put it: “The main problem with any prioritization decision is [the] decision to service one job and delay another”.[2] People should understand that doing one thing means delaying other things.

I remember one conversation with a Project Lead in a high-tech company when we were discussing the priority of the features on a project. When asked to define the priority of his features, he said “I want everything!” While at first glance you may be tempted to label all features with “Priority 1”, “high” or “urgent” priority, you should be cautious. If everything is urgent, then everything loses its urgency. If everything is important, then nothing is really that important.

There is also a recognizable antipattern of trying to please all stakeholders by just starting with one big unprioritized list with all the items you have or are given to you. This indecisive behavior causes several problems:

• Lack of direction and focus: Pleasing everyone means pleasing no one. We need to have a mission to pursue. Once we try to please everyone, we will run in different directions, team members will lose focus, and this will inevitably have disastrous consequences.
• Welcome Frankenstein: a mix of everything which has no shared goal will lead to a product that nobody understands and wants.

So, how can we define the priority of any type of work, no matter if we talk about prioritizing epics, features, stories, tasks, etc.? Of course, there is always the option of simply relying on a gut feeling when deciding the importance of a feature, user story or a task. However, this is far from desirable, as it puts the entire project at risk. A way better approach would be to use a proven prioritization method or technique.

There are many prioritization methods and techniques out there. But based on my experience and what I have used and seen working very well for companies, I will cover the following five methods and models in a series of six articles:

1. Kano model - in the scope of this first article from the series
2. MoSCoW method
3. Eisenhower matrix
4. Value vs Effort matrix
5. Weighted Shortest Job First (WSJF)
6. Comparison of some of the best prioritization methods - comparing the five methods discussed in the previous articles

Let’s now focus on the Kano model, the prioritization method in the scope of this first article of the series.

The Kano model was created by the Japanese researcher Professor Noriaki Kano in 1984.

The Kano model or also known as Kano analysis is a customer-driven prioritization method that is used by many product people to determine priorities. The model describes a qualitative relationship between product attributes or features and the degree of customer satisfaction or dissatisfaction that they engender.[3] The technique is used to classify customer preferences/requirements into five different categories:

Basic: These are “must-be requirements” customers expect and are taken for granted. They must always be present. Having all these basic requirements does very little to increase the customer satisfaction and most often customers are just neutral. But if these requirements are not present, customers are very dissatisfied. As a result, another name sometimes used for this category is “dissatisfiers”.[4] Examples of features that can be classified in this category include the possibility to change your personal account’s password on a website; cleanliness of the carpet in a hotel room; or voice calling functionality in a smartphone.

Performance: Features in this category generate satisfaction the better they perform and respectively generate dissatisfaction when their performance is poor. They are the most visible of the Kano requirements and are the easiest to acquire because customers talk about them all the time. As a result, features in this category are also often called “satisfiers”. Prof. Kano originally called these requirements “one-dimensional” because they are linear in nature. More is better here and will result in a more valuable overall product.[4] Examples of such features include the battery life of a mobile phone (the longer a mobile’s phone battery lasts the better); the resolution of a new TV screen; or the range of electric cars.

Attractive (also called Excitement): Features that are not expected, but when present they cause a pleasant surprise or delight. The lack of these items does not cause user dissatisfaction because they are not expected but can increase the overall satisfaction with a product. Prof. Kano originally called these requirements “attractive” or “delighters” to associate them with their real nature. Some companies call them unique selling propositions (USPs) since these are innovations that make your offering unique.[4] Examples of excitement/attractive requirements include complimentary Belgian chocolate bar in your hotel room that has been left by the hotel staff; or voice-activated parking-assist system when you want to park your car in a tight space.

Indifferent: Features that make us feel indifferent if implemented. Most customers simply don’t care about whether these requirements are present or absent, their satisfaction remains neutral anyway and, in many cases, it is not worth implementing them or developing the functionality further.[4] An example can be some of the advanced functionalities on a smartphone that almost no one would ever use. If these are expensive to include/support, the logical step is to eliminate them.

Reverse: Even though this category is often overlooked, it has its benefits. The absence of the features in this category can cause satisfaction, while their presence will cause dissatisfaction (for most people). These features could frustrate customers, so you should avoid building them (further) or completely exclude them from your offering.[4] An example could be Instagram’s decision to remove 'Following' tab from their app, which allowed people to see their friends’ likes and comments. The reasoning behind this decision is because the functionality caused a lot of controversies, such as claims it was making many users paranoid and depressed.

Figure 1: Dimensions and categories in the Kano model

The horizontal axis represents the degree of execution or fulfillment. On the right extreme items are fully executed (excellent execution and the need is well fulfilled), whereas on the left extreme, items are executed very poorly or not implemented at all and hence the need is not fulfilled. The vertical axis is the satisfaction level for a particular requirement/feature - on the top, customers are very satisfied or delighted and, on the bottom, customers are dissatisfied, or they are even disgusted.

After inputting the dimensions and the categories of requirements in this model, a special survey or questionnaire can be designed and used to determine which Kano category your requirements (or features) fall into. The Kano survey is the most time-consuming part when using this prioritization model, as you need to approach your users (in order to get real customer feedback) and ask the following two questions for each feature you would like to evaluate:

• “How do you feel if you have the feature?” (this is our functional question)
• “How do you feel if you don’t have the feature?” (this is our dysfunctional question)

The questions are not open-ended, and they do require specific answers. The answers were not designed to offer a specific rating, but rather to provide a sense of customer expectation towards each feature. Possible answers include [5]:

• I like it
• I expect it
• I don’t care (i.e. I am neutral)
• I can live with it (i.e. I can tolerate it)
• I dislike it

Based on the answers to the functional and dysfunctional questions (from the Kano survey), the following Kano matrix (see Table 1 below) is used to evaluate the results and assess each feature. Basically, the table shows in which of the five categories each feature belongs to (Basic, Performance, Attractive/Excitement, Indifferent or Reverse). Please note that there are two cells with questionable answers, which contradict each other, and therefore a feature cannot be graded in this case.[5]

Table 1: Kano matrix to evaluate results from the Kano survey

After mapping each feature to the right category, prioritization of the features on the backlog becomes a lot easier. The recommended decision-making process to define the priorities is as follows:

• Basic features – these features are must-be and should always be implemented first (e.g. when launching a new product).
• Attractive/Excitement and Performance features – these are not must-be requirements, but if you want your customers to be satisfied, these features should be implemented as well. We can even argue that “attractive” features are equally important as the “basic” requirements since they differentiate your offering from your competitors and give customers a reason to select your offering when they have so many other choices. “Excitement” features justify higher margins because the customers are willing to pay extra for new features or functionalities that add value. It is, however, very important to note that time has a big influence on the “excitement” features. What is exciting for customers today (“excitement” features), will be asked for tomorrow (will transition into “performance” features) and will be expected as a “basic” requirement the day after. An example is what we see happening today with the smartphone cameras. Take Samsung, for example. In 2020 they launched phones with 64 MP telephoto zoom camera and even a model with 108 MP wide-angle camera. If users are happy with the performance of these cameras, this requirement can quickly become a “performance” feature and can even be transformed into a “basic” requirement in the future.
• Indifferent features – in most cases it is not worth doing these due to no appreciation on the investment (no sufficient return on investment). These features should be moved to the bottom of the backlog.
• Reverse features – don’t implement these features due to customer dissatisfaction if present and negative impact on the product. Therefore, the advice is to remove these features from the backlog (or if they are already implemented, consider getting rid of them).

The truth is that the first three Kano categories - Basic, Performance, and Attractive/Excitement - are all critical to the success and future profits of your offering.

Let’s now look at the advantages and disadvantages of the Kano model.

• Highlighting the potential strengths and weaknesses of a product. One of the most valuable aspects of the Kano model is user feedback. The results from the Kano questionnaire/survey help to identify the future product’s strong and weak points. This allows product people to know the product/market fit early in development. Understanding how the list of requirements fits into the Kano Model can also help an Agile team determine which of the requirements or features to include, which need enhancement, which need cost reduction, which simply leave as are, and which should just be excluded.

• Prioritizing product features based on their real value for customers. The Kano model is a very customer-driven prioritization scheme. It relies on direct communication and feedback from the customers/users. It helps rate the product attributes from the value proposition standpoint and tailor them to perfectly match user needs.
• Envisioning the right product to build. When creating a new product, it is important to have a good product vision. The Kano model allows you to capture the right requirements based on direct user feedback and allows you to establish a clear vision on what product to build based on a good mix of basic, performance and excitement functionality.

• Restricted by customers’ opinion and knowledge. The Kano model is a very customer-centric model which intends to bring customer satisfaction, however, it still has pitfalls. A backlog prioritized using the Kano model may introduce a plain wishlist (even though items are ordered based on the different categories) and be limited to expectations of customers who have no technical background. There is no indication on technical feasibility and implementation. To make Kano really efficient, product people have to discuss the technical concepts with the engineers/developers separately to ensure what customers want is actually feasible.

• Provides no details on required resources (time and cost). Although the Kano model gives a more comprehensive picture on how to establish the priorities from the customer point of view, it does not account for time and costs that are necessary for the implementation of a particular feature.
• Time-consuming practice. Since the Kano survey, which may target a lot of potential customers, is incorporated in the Kano model, the effort to process and evaluate the final results might be quite significant. It could slow down the whole time-to-market process and distract the team from execution of the work.
• Contradictions in translation and number of categories in the model. The language of the original publication of the Kano model was Japanese. From the very beginning some of translation of the key terms in English has been misleading and the names of the categories have been translated in different ways by different parties, which means that they may have different names depending on who you are speaking to and which version of the category names they learned. Moreover, Prof. Kano identified five different categories of product features based on client perception (as described in his original article), however, many publications and discussions on the Kano Model focus on only three or four of those categories. I have tried to solve this problem with the article you are reading, as it describes all five categories of the model and highlights the possible names that can be used interchangeably for each category.

The Kano model is very useful for companies in the early stages of their development, for example, startups striving to generate user feedback for the initial UX design of their product. Submitting their concept in tandem with the results from the Kano survey (prioritizing the features into the different categories) would be efficient and would help distill a lot of value. However, if your product entails technical complexity and various hidden blockers, the Kano model should either be used together with other prioritization techniques or even be completely replaced by other more sophisticated (more suited for backlog priority setting) prioritization schemes.

In my next article I will talk about the MoSCoW method. Meanwhile, if you want to know more about prioritizing using the Kano model, please feel free to contact me.

[1] Schwaber, K., & Sutherland, J. (2017). The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game. Retrieved from 2017-Scrum-Guide-US.pdf

[2] Burns, M., Reinertsen, D., Matts, C., Arnold, J., Grout, T., Magennis, T. (2016) Better Backlog Prioritization (from random to lifetime cost of delay). Everyday Lean. Retrieved from Better-Backlog-Prioritization-v0.2.pdf

[3] Kano, N. (1984). Attractive quality and must-be quality. Hinshitsu (Quality, The Journal of Japanese Society for Quality Control), 14, 39-48.

[4] Verduyn, D. (2014). Discovering the Kano Model. Retrieved from kanomodel.com  

[5] Kano+ (n.d.). The Kano model. Assessing Product Features based on Customer Satisfaction. Retrieved from https://kano.plus/about-kano