How to Use the Kano Model for Feature Prioritization
The Kano Model is a valuable tool for product managers and entrepreneurs. Used properly, it can help you identify your product’s unique value proposition and help you prioritize which features to build first.
In this article, I’ll cover:
- What is the Kano Model?
- When should it be used for prioritization?
- How can I put the Kano Model to use?
- Managing stakeholder communication
Let’s jump in!
What is the Kano Model? 🤓
The Kano Model is a framework for prioritizing features that could potentially be built 🔨
I’m not going to go super in-depth about the history of the Kano Model because that’s not super relevant here. However, if you’re interested, Wikipedia has a good page.
The Kano Model rests on the hypothesis that there are different classes of features that impact the end user’s happiness in varying ways. Those classes are must-haves, performance benefits, delighters, indifferents, and displeasers. (Other terms have been used to describe these classes, go with whatever floats your boat ⛵)
The classes are represented by this graph:
Must-haves are the things your users simply cannot do without. They are baseline requirements and your product absolutely must include them. They also don’t make users particularly happy because they are simply baseline expectations 😐
Must-have features oftentimes seem boring and not fun. They aren’t things you can market and sell, so they’re the things that stakeholders like to gloss over because they’re not super interesting.
⚠️ Do not be fooled by the lack of “interestingness” in these features. They’re not interesting because they’ve been built to death. Because everyone does them. Because they are absolutely required to be considered viable. They’re the things that, once people discover you don’t have them, leave them thinking, “Are you kidding? How does it not do that?”
Imagine going to stay at a hotel. No one advertises that you’ll have toilet paper 🧻 in the bathroom. This is a baseline expectation that, upon arrival, you’d be quite disappointed to find was missing – particularly if it couldn’t be easily remedied.
Performance benefits are the things that are on the proverbial playing field ⚽. They’re not quite must-haves, but users generally want them. There can be a number of different ways these features are implemented, which allows companies to compete against each other based on the variety and level of implementation of these features.
These are the features that you actually market and sell.
Back to our hotel analogy, consider the wifi situation 📶. You expect that a hotel is going to have wifi available. The question is what flavor of wifi you want – do you want free wifi? Fast wifi? Both? You might consider this when selecting your hotel room.
These features are typically interesting and fun. From a user satisfaction standpoint, you get out of them what you put into them.
Delighters are the features that no one expects you to have, but that make your users unexpectedly happy 🤩. This is typically because it solves a problem that they didn’t even know they had 🤔
Delighters aren’t typically the things that make the sale. They are things, however, that make your customers talk about your product with their friends and colleagues. And we all know how important referrals are 💬
Imagine walking into your hotel room and finding free beer 🍺 in the mini fridge. Free beer! Even just one! When someone asks how your hotel was, you’d probably mention that there was free beer in the mini fridge. It made you unexpectedly happy. You probably got more than $5 of happiness out of the hotel’s $5 investment in that bottle of beer.
Indifferents and Displeasers
These are features that your users either don’t care about, or that actually degrade the experience 😬. They can be tied together, though – imagine an app full of features that you didn’t care about that got in the way of you doing what you need to do. Those indifferents have added up to be a displeasure.
For simplicity, these aren’t represented in the graph above. In short, don’t waste your time adding these features to your product. They’re a road to nowhere.
The Kano categories are a spectrum
I see this trip people up very frequently. They see the graph and think – each feature can only be one of the above. It has to sit nicely on one of the lines.
The reality is that the Kano categories are a spectrum. Sometimes a feature is somewhere in between a must-have and a performance benefit.
When you think of these categories, think about placing your features on this chart (as shown), not the one above that is most commonly associated with the Kano Model.
I’ll explain the numbering in a bit, but just remember that it’s a spectrum, not a rigid system. The primary graph with the three lines describes how each prototypical feature would impact customer happiness, but this chart describes how each feature sits in the model.
When should I use the Kano Model?
The Kano Model is best used when you already have a defined product category 🎯 and validated need ✅. The Kano Model isn’t great for finding a target market or product category, or for coming up with why someone should want your solution.
Once you have a defined product category and validated need, the Kano Model helps you identify which features to build first 🥇
It can also be useful to products that feel like they are struggling to gain traction in their product category. Retroactively doing a Kano Model analysis can help identify why your product isn’t getting the traction that you feel it deserves and helps you create a plan for getting there.
In either situation, the Kano Model helps you identify your product’s value proposition. We’ll get to that in a bit. First, you have to figure out which features go in which bucket.
How do I use the Kano Model?
Making good use of the Kano Model has a few steps:
- Identify features that could potentially be included in your product
- Assign a Kano class to each feature
- Use the class assignments to analyze the competition
- Create your unique value proposition
Identify features and attributes 👓
The first step is knowing what the possibilities are. Visit all your competitor websites and write down the features that you see available. We’re looking for medium-sized umbrellas, not the minutiae of their WYSIWYG editor.
Additionally, you should consider attributes of the site as a whole. Modern UI ✨ is not really a “feature,” but it can be a strong differentiating factor. Same with “ease of use.” Many older software products are terrible to use, and ease of use is a very valuable attribute.
You should come up with 20ish features and attributes to analyze. You’re going to be surveying (potential) customers about these features, so you don’t want to overwhelm them with too many questions.
If possible, get access to each competitor’s product. Sign up for a free trial if you can, or grill their salespeople if the product is gated. Marketing websites don’t always have all the right info, especially when it comes to the level of implementation.
Consider your target user(s)
When you’re doing a Kano Model analysis, the user you are targeting is very important. The end user will likely have different needs, wants, and desires than the person writing the checks (in a B2B situation).
Your company’s contact-initiation strategy (eg. how potential customers first come into contact with your product) matters here. If you’re a sales- or marketing-led company, then you need to be considering both the person who will be championing the use of your product in the organization as well as the end-users of your product.
Product-led companies have it easier (in this situation) and primarily need to consider the end-user’s needs and wants.
As you move forward with your analysis, consider whose wants and needs are being reflected in the analysis. If there are multiple groups of people whose needs should be considered, make sure to look at their responses independently before looking at them collectively. Knowing what matters to each user type is incredibly important as you form your value proposition.
Assign a Kano Class to each feature
This is one of the more difficult and important things to do because an incorrect assumption here can really throw off your value proposition.
There are a number of ways you can attempt this, and I’ve tried a number of them as described below. If you just want to get to the goods, jump to my recommended method.
Method 1: Rank the features yourself 🧑
Synopsis: Good only if you actually are your own customer.
With this method, you’d take your list of potential medium-size features and select the most appropriate bucket.
When I did this, I quickly ran into the problem that I am not my customer and I couldn’t really say with certainty what they needed.
This could work if you, in fact, are your customer. Entrepreneurs who build their businesses based on solving problems they face themselves on the daily can possibly succeed with method 1.
PMs whose teams heavily dogfood their own products can get close with method 1. But beware of thinking that just because you use your own software that you can completely know what your customers need.
Once it was quickly apparent that this method wouldn’t work, I moved on ➡️ to Method 2.
Method 2: Ask customers how they feel with and without the feature.
Synopsis: Good on theory, light on actual usefulness.
This is a commonly suggested technique, and the theory 📚 is good. It gets to the root of the need by asking (potential) customers themselves. Your (potential) customers are the best source of information about their own needs.
The method is described in depth elsewhere, and because I don’t particularly recommend it I’m not going to go super deep into it here. In essence, you ask two questions about a feature:
- How would you feel if this feature existed?
- How would you feel if this feature did not exist?
Each question has these options, or some similar variant:
- I like it
- I expect it
- I am neutral
- I can tolerate it
- I dislike it
In practice, it’s very difficult to craft a survey with this method that is concise yet thorough and leads to good results.
By “good results” I mean results that make sense. With this method I ended up with a lot of confusion – both from people taking the survey and from the results. I’d get results like “This is absolutely necessary but I’d be okay without it.” That does not make sense at all 🤨
It’s probably possible to make Method 2 work well. I mean, there are so many tutorials about how to use the Kano model in that way. For example, the #1 Kano reference online talks all about it.
For me it felt like this method was too heavy on theory and too light on usefulness.
Again, it was time to go back to the drawing board.
Method 3: Ask how a feature impacts the purchase decision 💵
Synopsis: Recommended! Not quite as detailed as method 2, but easier and more reliable for everyone involved.
With this method, you ask (potential) customers how they would view a certain feature in relation to the product category, and how that feature would impact their purchase decision.
To come up with the survey, I took all the possible logical answer combinations from method 2 and came up with a few statements that summarized that emotions of those choices. The survey takes the following form:
For Feature X that aims to do Y, select one:
- I can’t function without this
- I’m unlikely to consider a product without this
- This is exciting, but we can function without it
- I am indifferent about this
- I dislike this
Your Kano categories map as follows:
Method 3 made the most sense to both me and the people taking the survey. There’s probably some granularity 🔍 there that’s missing from method 2, but rough data is better than wrong data nearly all the time.
Once you have your survey results, it’s time to analyze them.
To do this, I numbered the possible response values from 1 through 5. So, any response that said a feature was a baseline requirement / must-have got a value of 1. Any responses that said a feature was a performance benefit got a value of 2. Responses that said the feature would be considered a delighter got a value of 3, and so on.
Here’s an example of how some responses would map using this system:
Then I averaged the responses to get an idea of where the feature landed.
If we’re rounding, that puts Feature X in Performance Benefit territory. You can see this when we place it on our Kano Model category spectrum:
The nice thing about this is that you can see which features are headed into Must-Have territory, and which Delighters are slated to become Performance Benefits in the future. Note: Features inevitably move “down the graph” from Delighter to Performance Benefit to Must-Have over time.
It’s also important to look at the distribution of the answers. If they’re really all over the board there was possibly some confusion about what the feature entailed, or you didn’t do a good enough job of considering your target users. If they’re pretty consistent that’s a great sign.
After your analysis is done, you’ll have a ranked list of features, quite honestly with the most important ones at the top and the least important at the bottom. No, this is not magic; it’s the Kano Model. 🔮
Next up, identifying your value proposition.
Analyze the Competition
Now that you know what features fall into which Kano bucket, it’s time to see how your competitors stack up with those features.
No need to get too fancy with this. A simple spreadsheet will do mighty fine!
Note: This analysis of competitors based on the Kano Model is based on a model in Dan Olsen’s book, The Lean Product Playbook. Highly recommended!
Each company should have every must-have. It’s a must-have, after all. Performance benefits should be ranked based on their implementation – high for an incredibly complete implementation, low for just barely checking the box. Delighters should just indicate whether or not it exists in the product.
|Competitor||Feature A |
|Feature B |
|Feature C |
Form your value proposition
Now the fun part begins: creating your unique value proposition. I really love Dan Olsen’s definition of your value proposition based on the Kano Model.
Your value prop is:
🏎 The performance benefits on which you decide to compete
💖 And the delighters you choose to offer
Must-haves aren’t included in the value prop because they are expected to be there. The must-haves aren’t exciting and aren’t what your sales and marketing talk about but nonetheless must be included.
This value proposition defines what your product will offer to customers over other options. It outlines why your product is special – at least at the MVP stage.
Of course, development is never done. You likely can’t include every single performance benefit and delighter in your MVP. You can use the information you’ve gathered in your Kano Model survey to determine what should be built next – it’s likely a combination of improving or adding performance benefits, and surprising your customers and prospects with new delighters.
That begs the question, though – how many performance benefits and delighters should you offer? What is considered enough?
This isn’t a question that can be easily answered with a blanket statement. It’s going to depend on the results of your survey, feedback from potential customers, and your timeline. You don’t really want to launch too early, but general consensus is that launching too early is far, far better than launching too late. Err on the side of less, not more.
Based on your competitive analysis you can determine what your competitors’ value propositions are, too. What’s key here is that, for your product, you’re aiming for a unique value proposition. You want to find that little niche that potential customers think is helpful and valuable, and you want to fill it. Otherwise you’re just playing catch-up.
Now it’s time to build. With the Kano Model you’re oftentimes starting out with a new product, and you don’t want to release it until it’s viable, at minimum. That means you’re going to build out your entire value proposition – plus the must-haves – before release.
In this situation, you can build in whatever order you want. However, it’s generally good advice to build the must-haves first. They are typically more of the ground-level features that the rest of your app will likely depend on or interact heavily with. As is the way with must-haves, these aren’t always the most fun things to build. But they are necessary.
After that, build in the order you prefer or that is logical for how the product will interact with itself.
The situation is a bit different for existing products. If your Kano analysis has determined that there are some must-haves missing, absolutely build those first. Then tackle some of the more important performance benefits and throw in a delighter to make your current customers (if you have any) really happy. Alternate between improving/adding performance benefits and delighters to keep the needle moving forward.
If any features you currently have are pretty far down the list (low delighter or indifferent category) then don’t give them any attention at all. Additionally, if there are performance benefits that you’ve decided to not really compete on for now, put off work on those while you focus on the things that are going to make your product competitive – the things that make up your product’s value proposition.
Managing stakeholder communication
In my experience, the jargon involved with the Kano Model doesn’t sit super well with some stakeholders, particularly if they are strong proponents of certain features.
Specifically, some will consider the “sellable” things as “must-haves” because they see those things as absolutely necessary to make a sale. However, in Kano Model language, the performance benefits and delighters are the things that make the sale. No one talks about the must-haves because they’re not exciting.
Telling these people – who consider the sellable features as a “must” – that those features are simply “performance benefits” is frustrating to them because, in their view, you’re saying that the things that will sell aren’t really necessary.
This kind of misunderstanding is more of an issue with the terminology than with the strategy.
When discussing these items with your team, consider using some other terms to describe the feature classes but that get the general idea across. A couple options could be:
- Must-have ➡ Basic requirement, baseline need, etc
- Performance benefit ➡ Competitive advantage, power features, etc
- Delighter – this one tends to be okay left as-is 🙂
The Kano Model is a valuable tool for identifying your product’s value proposition and planning out your product’s minimum viable product – and beyond.
Putting the Kano Model to use can seem tricky, but with the right survey method you can get actionable results in a very short time.
If you’ve used the Kano Model – either successfully or unsuccessfully, I’d love to hear about your experience in the comments!
If you found this post helpful, come follow me on Twitter where I share product insights and my journey toward building a new business in technology.
Your email address will not be published. Required fields are marked *
6 Comments on "How to Use the Kano Model for Feature Prioritization"
July 14, 2020
Wanted to let you know this was was very well done, great job explaining the model in a friendly way and overall good refresher on the concept. I think the last section on explaining this to stakeholders could be an entire post in its own right 🙂
September 25, 2020
So glad you found it helpful!
July 13, 2020
“It’s also important to look at the distribution of the answers.”
Non-uniform answers can sometimes be because there are sub-groups to the participant population. One study I did asked users of an online banking service, and we noticed certain features were split between being must-be and attractive. Which is really odd. Then we looked at the feature in question, and how those they answered for other features, and we quickly realised we had two distinct sub-groups: everyday consumer users of online banking (using the service occasionally), and people that do a lot more online banking because they use it to run their business.
September 25, 2020
Definitely! I mentioned that in the “Consider your target users” section higher up, but also just added it to the paragraph you referenced. Thanks for mentioning it!
July 10, 2020
Thanks for putting this together. It’s the first helpful resource I’ve seen on the Kano Model because it provides some insight into how to use the model in different situations.
I’ll be sure to pass this along.
September 25, 2020
Glad you found it helpful, Kent!