You just bought a new software for your work. After considering alternatives, you decided to buy this one. It looked much better than the others. You installed and started working. Everything seems fine. Suddenly the power went out and your desktop is now dead.

When the power came back, you restarted your desktop and opened the application. It was empty as if it was the first time. But you have been working on a document for hours.

How come ? This is 2018 and auto saving documents to protect from such problems is a standard behavior.

Apparently not for this particular one. Now you feel angry, disappointed, cheated.

You are inside the lower left quadrant of the Kano Model

What is Kano Model

Kano Model is a theory created by Professor Noriaki Kano in early 80s, in order to define and categorize customer needs during product development.

Following is the famous graph of the model. We see three main types of features: basic needs, delighters and performance needs. It summarizes how the customers react when those features are absent or implemented.

• Must-Be Quality: Basic needs, features that are taken for granted by the customer. Even a slight problem in this area causes great dissatisfaction about the product. You can never make “too good” in this area because whatever you do is expected.

• One Dimensional Quality: Those are the features whose existence make the customer happy, and absence causes unhappiness.

• Attractive Quality: Delighters. If you do those, your customers will be very satisfied. If you don’t, it will not matter.

Every single feature of every software we use fall in to one of those categories. It is very challenging to have no gap in Must-Be area, while providing other features.

However there is an important catch in the graph.

People will either get used to delightful features, or competitors will start doing the same which would make the feature more common.

This does not happen so fast in traditional industries. It took decades to consider air conditioner as a standard equipment in cars. But software industry changes very fast.

How does it affect startups ?

This is a huge challenge especially for many startups and individuals because the cost of reaching acceptable level for a product keeps increasing as the list of basic feature increase in time.

5 years ago, you could have an API service without OAuth. You could say you support only a single database backend. You did not have to support every major cloud vendor, just AWS was enough. For many, even cloud was non-requirement. Docker and microservices were not a thing compared to today.

Nowadays when you start from scratch, you will have to implement so many features upfront just to be considered OK. The initial requirements will be even higher 5 years from now on.

How can you prevent your best features from becoming basic needs ?

You can not do it unless you are the only player in the market.

You can create a great feature, but once you do it, you can not prevent others from providing same. Eventually, it will become a standard. Accept this fate, and work accordingly.

What if you are not a market leader ?

In that case, you do not have control on the market. Therefore, you can end up closing a gap in Must-Be area even though it is not your fault. A good example is docker support. Even though your product has perfect lifecycle management, your customers may start asking for container support because it has become very common. May be your product is as good as 5 years ago, but now people will have some disappointment because lack of container support, potentially disregarding your past record.

How does product management use Kano Model ?

The voice of reason says, you should correctly assess present and future state of your features. Doing so will allow you to have no gaps in basic needs while still generating features that drive sales. Story would normally end here.

But the reality is often different.

The phrase You get what you measure pops up here again (also in Dangers of Setting Goals Wrong in Software Teams)

In many places, sales are incentivized above others because even though making profit is the only reason businesses exist, most are near sighted and focus only on short term gains. (Or this could be an exit strategy as well)

This naturally results in people focusing on adding features that are either one dimensional or attractive, while neglecting properly implementing the basic stuff.

Why ?

Because, you can not sell something easily when its features are just like everybody else. Your chances increase if you can offer some delighters.

However your capacity for development will be always limited for some reason.

People who are paid based on the contracts that they secure, will have to make a choice. Are they going to prioritize delighters (because it will increase their chances to sell, hence bonus), or are they going to let effort to fulfill basic requirements ?

On this path, product will look great on paper, but it will cause a lot of pain to its users when gaps in basic requirements surface.

How “Agile” becomes an excuse to develop crappy products ?

Some people interpret agile development as we implement something only if a customer explicitly asks. Sometimes you can also hear we will first have a basic implementation and then we will extend, it will be technical debt. We can even discuss whether this is a type of technical debt or not.

For certain features those are valid arguments. But for basic features, they are very dangerous.

Note that, having a shoddy support for a basic feature is almost as bad as, if not worse, not supporting it at all. Because, claiming a feature creates an expectation. If the product does not live up to that, the disappointment it creates may be worse.

Yes, it was “agile”, roadmap is followed, releases are done on time. But is there any measurement on the satisfaction of the customer ? Do you take time to correlate issues opened by customer with features ? (After all, they are unfinished)

But, is this scheme even sustainable ?

Sometimes. If the sales are completed at the upper management level without involving feedback from the people who will actually use the product, it can still work.

This might be your only option if you know that your product can not openly compete when it is exposed to the decision of ultimate users. So, this can really be a strategy.

What are the typically ignored Must-Be features ?

• Security: It is like the unlucky fat person who is killed always first by the serial killer in horror films. Everybody expects what they buy is secure by default, but it is indeed quite expensive to reach a level that gives confidence. Besides, it is usually far from the eyes. A perfect candidate to keep costs low, therefore it is often neglected (Reasons Why We Keep Making Security Flows)

• Operational goodies, monitoring, observability: Those are usually sacrificed because many people, especially decision makers who have limited engineering experience focus on features around the business and those are not business related.

• Documentation: Good, clean, correct documentation is a difficult and costly task and like others in this list, it does not directly translate to sales. Therefore documentation is often undervalued, even though quality issues in documentation have great negative impact on experience.

• User Experience: It is surprising to see people still confusing user experience with user interface, so they believe shiny, modern looking interfaces are always better. Again this is an issue when decision makers do not have understanding of UX.

Why is this a problem ?

Because, negative feedback always emerges. When the actual users are unhappy with those, they will surely report it and they will be even more bitter because they are not consulted for the stuff they will use. This definitely erodes the trust between you and your customer.

What can be done to avoid such problems ?

Well, I am not an expert at all and I just try to understand this model and correlate it to the software industry I belong.

First and foremost,

If the company prioritizes quality and customer satisfaction on paper while spreading bonuses just for the sales, people will follow bonuses, not guidelines.

In the end what you pay for is what you actually prioritize, not what you write in your intranet or twitter.

Second, people in the product development needs to be aware of Kano Model. They need to understand how and why once unique features become basic needs in time. They need to undertand that gaps in basic needs are not “just another technical debt”. They are serious threat to customer satisfaction.

Third, product managers need to be able to correctly identify categories for the features in order to avoid getting red marks in basic features.

Finally, decision makers who will not actually use the product, should always involve technical teams and force the vendors for trials, demos and have detailed internal acceptance tests to verify they will get the quality they expect.