The Feature Nobody Used, and What the Kano Model Says About It

Here is a hypothetical example. A team spends a quarter building a dashboard that lets regional managers compare branches side by side. It passes every acceptance test. There is a demo, a launch announcement and a cake. Six weeks later the usage numbers arrive: a handful of managers opened it once, and almost nobody came back.

Nobody did anything wrong in the usual sense. The requirements were delivered, the tickets were closed and the sprint reports were green. The business is where it was before, minus three months of a team's time.

Delivered is not the same as used

Most teams measure what they control: tickets closed, story points, releases. Those numbers describe the work. The customer pays for something else, a change in what they can do or how easily they can do it. That was the point of Show Me the Money!: ask what job the code is being hired to do. A feature that changes nobody's behaviour has not done a job, whatever the burn-down chart says.

Acceptance criteria do not rescue you here either. I have argued for turning vague words into examples and acceptance criteria, and I still would, but a criterion tells you the feature works as agreed. It cannot tell you whether anyone needed it.

What the Kano model says

In April 1984, Noriaki Kano, Nobuhiko Seraku, Fumio Takahashi and Shin-ichi Tsuji published "Attractive Quality and Must-Be Quality" in the journal of the Japanese Society for Quality Control. They proposed replacing the usual one-dimensional view of quality with a two-dimensional one, relating its objective side, how fully a product provides something, to its subjective side, how satisfied the customer is. That relationship differs from one quality element to the next, and the differences are what their categories describe. They tested the idea with a consumer questionnaire about a television set and a table clock.

The clearest English explanation I know is a 1993 special issue of the Center for Quality of Management Journal, compiled by David Walden, which uses a car:

• Must-be: brakes. Poor brakes make a customer dissatisfied, but good brakes do not raise satisfaction, because good brakes are expected.
• One-dimensional: fuel economy. Better economy brings more satisfaction, and worse brings more dissatisfaction.
• Attractive: a radio aerial that retracts by itself when the radio is turned off. Customers are not dissatisfied without it, but may be more satisfied with it.
• Indifferent: a cigarette lighter. Customers are neither satisfied nor dissatisfied either way.
• Reverse: the team's assumption about which version is the good one turns out to be the opposite of what the customer feels.

Two questions instead of one

The method behind the categories is a questionnaire, and its trick is to ask about each feature twice. The functional question asks how the customer would feel if the product had the feature. The dysfunctional question asks how they would feel if it did not. Both offer the same five answers, which in the 1993 issue's wording run from "I like it that way", through "I am neutral", to "I dislike it that way".

The two answers are read together. Liking the feature and disliking its absence marks it one-dimensional. Liking it but being able to live without it marks it attractive. Expecting it and disliking its absence marks it must-be. Neutral on both sides is indifferent, and answers that contradict each other are classed as questionable. Across many respondents, the simplest rule the authors give is to take the most frequent category.

"Nobody uses it" is not "nobody needs it"

Back to the dashboard. My guess is that it was indifferent: the managers had no feelings about it either way, so they ignored it. A few dozen answers to the two questions would probably have said so before the first line of code.

Usage data alone could not have told you that, because a must-be feature looks the same on a usage chart. Password reset, data export and the audit log are used rarely, and nobody praises them. Remove one and the complaints start, and an enterprise buyer may refuse to sign without it. Low use and silence describe both an indifferent feature and a healthy must-be one. Only the second question, how would you feel without it, tells them apart.

The 1993 authors make a related point that saves effort: improving a must-be feature that is already satisfactory is not productive compared with improving a one-dimensional or attractive one. Once the brakes are good, better brakes do not sell the car. When two categories tie for a feature, one option they give is to pick the one with the greater impact, in the order must-be, one-dimensional, attractive, indifferent.

I would also treat any classification as a snapshot rather than a permanent label. Users get used to things. A feature that surprised them two years ago may be one they simply expect once every competitor has it, so ask the two questions again before trusting an old answer.

Source: the first three columns follow the 1993 Center for Quality of Management Journal issue; the last column is my own reading.

Before you build, write down the behaviour

The person who asked for the dashboard described a solution. The behaviour they hoped to change was the need behind it, the distinction I wrote about in Beyond the Obvious. Write that behaviour down before the feature enters a sprint, and agree it with whoever asked:

1. Who will behave differently, and how many of them are there?
2. What will they start doing, or stop doing, that they do not do today?
3. How will you see it? Name the event you will log, and record its baseline before launch.
4. By when should the change show, and what result would make you remove the feature?
5. Which Kano category do you expect, and have you asked real users the two questions?

The third point is the technical one, and the one teams skip. If the event is not instrumented before launch, the review six weeks later is a debate between anecdotes. A feature flag helps as well: release to a share of users, compare them with the rest, and keep the option of switching the feature off without a deployment.

A feature that nobody uses is rarely an engineering failure. It is usually a question nobody asked, answered at the price of a quarter. The two questions cost an afternoon.

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on enterprise software delivery, from pre-sale to handoff.