The Kano model is a theory that ties product development with user satisfaction. It was developed in Japan in the 1980s by Professor Noriaki Kano. The Kano model classifies product features into five categories based on how developing them impacts user satisfaction:
Once you know which categories your features fall into, you can prioritize the most important ones for development. In theory, features from the Must-be category should be prioritized first, followed by Performance and then Attractive. In practice, there might be good reasons to follow a different order of the categories or to prioritize features individually based on their score for multiple categories.
Using the Kano model can help you to make more informed decisions when prioritizing features from your backlog and to better understand why these features do or don't resonate with your users.
The Kano model is best formed from user data, especially when it is informing the prioritization of features. To collect this data we recommend conducting a research study and use a standardized questionnaire (more details bellow ⬇️) that was developed as a part of the Kano model theory. Designing a survey for a Kano model study is rather simple from the research perspective, however it requires a lot of preparation by the product manager – especially describing the features and current state of the product area. In the following paragraphs we will discuss details of organizing such a study.
Example project: Survey for CI feature prioritization
Project summary: The team was considering 12 new features to build that they thought would benefit our users. Since building new features is costly and time consuming, the team wanted to understand how users felt about each of those features, along with a prioritization. The goal was to end up with a clearer understanding of which 12 the team should build first.
Well-formulated feature descriptions are crucial for the success of your study. Participants must be able to accurately understand the features that you are asking about and the value of those features, so they can provide honest feedback. It makes sense to begin creating the survey only after the features are documented.
We usually develop new features in the context of features that already exist. For that reason, you should first walk the participant through the current experience(s) that contain the features being presented.
Example of category description:
A continuous integration pipeline in GitLab is defined as a version-controlled file in the Git repository of a project. This file is called 'gitlab-ci.yml' and users configure CI pipelines by editing this file and pushing it to the repository. Pipelines consists of jobs and stages. Jobs define what the pipeline should do. Stages consist of one or multiple jobs and define the sequence in which jobs run. All jobs in a stage run in parallel, and if all of them succeed, the pipeline moves on to the next stage. Different types of conditions can be specified for pipelines like prerequisites, exceptions, and so on. You can edit the pipeline YAML file either by cloning the project locally or using an online text editor.
When creating feature descriptions, follow these guidelines:
Example of feature description:
A list of CI job code snippets that will display next to the online pipeline editor. You use these code snippets as the building blocks of your pipeline by copying the jobs YAML from this list and pasting it into your pipeline code. This will speed up creating new pipelines and reduce mistakes.
💡Tip: Preparing for the survey can take a lot of time and might be hard to track. Creating a separate issue (just like this issue) to track this effort will lighten the main research issue and will make it clearer who is the DRI.
💡 Tip: Preparing feature descriptions asynchronously can take a lot of time. If you feel like your team is not moving forward quickly enough, pivot to synchronous communication.
The standardized questionnaire for the Kano model consists of two questions that are asked for each of the features that you are interested in:
|Functional question||Dysfunctional question|
How would you feel if you had this feature?
How would you feel if you did not have this feature?
The benefit of using the standardized questionnaire is that basically all of the research design is already done, and you can reuse it from previous studies. Also, taking a consistent approach to this methodology reduces the risk of introducing errors to the process.
Use Qualtrics to create the questionnaire. Each feature with related questions should be presented on a separate block.
Using the provided questionnaire, you'll be able to collect the data, analyze it, and report out the findings using both quantitative and qualitative approaches.
This approach will provide you with a better understanding of the why behind their prioritization. Also, collecting and analyzing the qualitative data first could help you to spot problems in your feature descriptions that you can fix before sending them out to a lot of people. We recommend conducting 5 to 10 moderated sessions and/or 20 to 30 unmoderated sessions where a participant's task is to go through the questionnaire and explain the reasoning behind their answers.
We recommend collecting responses from 50 to 80 users in your target audience and analyze them using discrete analysis described in the article The Complete Guide to Kano Model by Daniel Zacarias. This approach will provide you with "the numbers" that can back up your prioritization decisions, but you'll still lack the understanding behind the prioritization.
For the analysis use this spreadsheet template: [Kano model: Survey for
Taking the quantitative and qualitative approach will result in a more complete story behind the data. In addition to prioritization, you'll also be able to explain why participants scored the way they did, too. Combine these two approaches to get the most of your Kano model study
💡 Tip: If the questionnaire isn't too long and you have some other questions you would like to ask, feel free to add one more block for these questions in the end.