Classifying customer expectations, Noriaki Kano created the well-known Kano model more than 40 years ago. I felt this model deserves a more in-depth presentation on stars to road for a couple of reasons: First, it helps to prioritize features over the lifetime of a product. Second, it points to typical issues you encounter during product development and provides hints how to improve. Third, it is not too difficult to assess the categories and they are easy to understand. Fourth and most important: you need good understanding of customers and markets to work with the model, a real indirect benefit! All in all, the Kano model is an important foundation in product development one should know.

A property management company had a homemade software for their core business. The software was relatively cheap to create and maintain and made processes highly efficient. It was a success factor when it started almost two decades ago and became part of the market story, acting even as USP towards customers. Alas, other companies invested into their software as well. The competitive advantage diminished, customers simply expected an efficient software from their property manager. Then the digital transformation reached the state where customers and partner systems needed to be integrated. The core system was not well prepared, effort to maintain increased. Finally, customers wanted to consume specific services rather than a full property management solution – a change in the business model. The monolithic core system could not handle this at all. And thus, the core system, once an exciter, became a liability over time.

Behind it – Kano categories

The Kano model (check wikipedia for more details and good pointers) proposes categories for product and product features. The model captures the desirability of features from a customer viewpoint.

From the original five categories, three (exciters, performance and basics) made it into common practice. One might want to add another: liabilities.

• Basics are expected to be there. If they are missing or done poorly, stakeholders are dissatisfied. If done well, they same persons take it for granted.
• Along the performance features products and services compete. The market story is usually spun around them and customers tend to evaluate against them.
• Exciters are new and unexpected. Stakeholders will not miss them when they are not here but can be delighted when they are present. Exciters are potential game changers.
• Liabilities are (1) things customers perceive as a necessity but in truth are just a relict of old times, or (2) things a product still provides even though customers do not want it and may even be hampered by it. It’s not always easy to distinguish them from performance features nor from basics.

Kano categories align with some typical behavior

The replacement of an end of life core system: The property management company decided to retire the existing core system and replace it with a new solution. The performance factors were about integration of customer system and cloud platforms. Despite the excellent features like creating the perfect sales tax report, or the automatic contract generation, the core system itself consisted of basic factors. These things were a necessity and presumed by customers, users and management. In consequence, money went into everything else but the replacement. Also domain experts were busy improving the current processes and functions. For them, to step down and setup a new system full of basics was a waste of time. To add to the difficulties, the organization was also very well adapted to this custom made core system and change was not welcome. The consequence: replacing the old system took ages and generated many unhappy faces on the way.

The Kano factors go along with typical difficulties and behaviors in product development.

• Pressure to perform: Companies tell their market story along performance factors. Expectations are high and usually do not match what is feasible. Teams are pressed to invest too much time. They neglect basics, exciters and the needed technical renovation.
• Missed basics: It is quite easy to miss out on the basic stuff with the promise of late drama, i.e. once people start using the product. The consequence is a load of noise to fix the basics.
• No change on basics: People expect the basics to work like they’re used to. Change is not welcome. As one consequence, features are kept alive that should have been overhauled and even dropped long ago.
• No exciters: Exciters are the performance factor of tomorrow. Having such things is one promising strategy for companies. They can compete with innovation rather than low cost production.
• Unwelcome exciters: Companies are, generally speaking, too occupied with renewing the basics and competing on the performance factors. There is little room for exciters and for good reasons: “customers never asked for this”, or “this competes with our cash cow”.

It is about the mix

As a rule of thumb, a product must offer a good mix of features: all the necessary basics to be well usable, good performance to have competitive offerings and the one or two exciters to stand out from the mass and to be prepared for the future.

Every now and then, a newcomer makes a splashing market appearance with exciting new proposals. Some even manage to change the game. To generate such an impact, a possible strategy is to cut down from the basics and performance factors for now and by that get rid of things generally believed to be a necessity but turn out to be a liability.

Priorities change over time

Kano categories help you with setting priorities right. What features should you develop and in what order?

A common strategy for developing a new product is to convince with an exciter. The exciter becomes the reason for the product to be. Basics and performance factors are built around the exciter and the team provides just as as little as it dares to keep users and customers happy enough. The one exciter is usually built very early, other exciters are delayed to a later release.

When developing a new software product to automate production with an industrial robot (see the case of a relevant UX problem for more details), the central idea was to generate a first robot program based on a few parameters and a lot of know how about the production process. The UI concept and the software architecture were designed around this feature. It was built very early on and constantly enhanced. It proved to be an exciter: once users started to use the software they were thrilled by the speed and simplicity of creating a robot program.
Still, some of the work pieces where to intricate for the first solution. The important performance indicator “how many of the different work pieces the customers want to produce can be automated” needed improvement. It needed more support for specific hardware extensions and for the one or the other of the life hacks used by technicians. The performance factors took over.

Typically, basic and performance factors follow once launched and when feedback from current and prospective customers tells where to improve. The reason: scaling to more customers is important. Thus, rather than exploiting untapped value propositions (exciters) teams provide more of the known value (performance) and start optimizing costs to keep existing services running efficiently.

As soon as others launch new exciting things, the team needs to choose the strategy: (1) Compete along customer demands (performance) and defend the current customer base; (2) follow the other product, copy their exciter and tap into the new value proposition; (3) Take customers even one more step ahead, bring yet another exciting innovation and open up additional potential.

Whatever way the team chooses, the product has started to age and teams need to act:

• On the technical level: Keep the technology up-to-date and the internal structure clean; manage the interfaces and dependencies to other products. If the backlog does not contain any bigger reworkings the product is probably aging beyond repair.
• On the team level: Keep the active knowledge alive. If you do not touch every component regularly, you will start hearing comments that nobody in the team really understands it and they were afraid to touch it.
• On the value proposal level: Have an excellent understanding of the product’s reason to be. What value does it offer so much better than every other product? If there is little or none, you might need to reinvent the product (providing new exciters) or start the retiring process.

At some point in time – history has shown this over and over again – a wave will transform the market. New technology, social movements, wars, pandemics and more have the potential to flip things within a few years, render products obsolete that have been a big success and provide a stage for new products. The people behind the property management system above simply stuck too long with a system that is in no way prepared for the huge wave of digitalization that hits service companies nowadays. It’s really time to retire the product.

Kano and methodology

Kano categories give hints about the methodology to apply. While stakeholders discuss performance factors at length, they generally have little patience to talk about the basics and have difficulties coming up with real exciters. Thus,

• the best source for basics are current systems and documentation;
• for performance factors workshops and the like are great; and
• for exciters I propose meeting with customers and users, looking at other industries, connecting with others, and applying the one or the other creativity technique.

Keeping track of the Kano categories can also give insights into the challenges of a development team:

• As seen with the property management case, the more basic factors a system offers, the less a team can count on support from the organisation around it when working on it.
• Product managers and stakeholders declare performance factors as “must”. In reality, they are negotiable. The achievable level of performance defines the market position. Thus the team faces a constant discussion around the market positioning and what is possible to develop.
• A software product with many potential exciters has more unknowns. Expect more iterations and changes, and make sure to collect feedback while developing.
• To come up with exciters is not easy. Be aware that (1) some people specify rockets flying over the screen and think this to be exciting and that (2) some teams deliver real exciters without realizing it beforehand.

How to assess kano categories

There are a number of ways to assess the Kano category of a specific feature.

• Questionnaires: Customers rate the presence and absence per feature from I like it to I dislike it. The answers allow you to derive the categories. E.g. many likes for presence and many dislikes for absence point towards a performance feature.
• Analysis of competing products and market story: What features do competitors offer? What do they present as key features and what do they present as their USP? Features not presented are likely to be basic factors, others performance factors or even exciters.
• Analysis of tenders: What features do customer request? The more weight on an item , the more likely it is a performance feature. Something no supplier provides could be an exciter. Things hardly or not at all mentioned are probably basics or even liabilities.
• Colleting feedback: Users and customers react differently depending on the factor. For basics, you get mostly negativ comments if at all. If users really get excited you know what you’ve created there. By the way, comments like “this features could be great for some other person” do not point towards excitement but towards a useless feature.
• Look at the team’s focus: Software products have hundreds of features. When teams start to compile questionnaires, they ask about things they are unsure about. An existing feature put in to understand whether to still provide it: distinguish between basics and liabilities. Putting in a new feature: test whether it is an exciter. Ask details about how to improve a feature: probably performance. By the way, the better connected a team is with users and customers, the more the team’s perception reflects the customer’s evaluation.

A kind of conclusion

Excitement is about a significant change in people’s life or work or how they do business. An effective feedback loop where a team can test and challenge ideas is the way to go. The goal: provide exciters that convince customers of your product.

Performance is about your spot on the market. What do customers evaluate a product against and how is a product positioned against competing options? The goal is to provide the needed performance to be competitive at a specific market position.

Basics is about making things work. Find the right balance between dropping basics (liabilities)and getting harsh critique for doing so. Some of you may still remember the first iPhone and the missing MMS feature. The goal is to provide just the basics needed for the product to work smoothly in every days life.