Customers do not value every feature in the same way

Ledger Lane’s dashboard themes look impressive in the planning demo. Meanwhile, bookkeepers need invoice files for another system and keep encountering export problems. Calling both “requested features” hides an important difference: one may be a pleasant addition while the other’s absence stops necessary work.

Ledger Lane is hypothetical invoicing software. Its bookkeeper group, interview insights, response patterns, and roadmap discussion are fictional, not findings from a real study.

The Kano Model examines how meeting a requirement relates to customer satisfaction. Some requirements are expected basics, some reward improved performance, and others can be welcome surprises. More implementation does not always produce proportionally more satisfaction.

Kano and his coauthors published the original attractive-quality and must-be distinction in 1984. The paired-question method below investigates reactions rather than assigning labels from the team’s enthusiasm.

Define the requirement before asking how it feels

Ledger first specifies the export behavior a bookkeeper needs. It then asks separately about having that behavior and not having it. The paired answers—not the team’s excitement—will determine the response category using a published evaluation table.

The first graphic shows that research path. It does not contain survey results. Vague questions about “better export” would leave people reacting to different imagined capabilities and make the later classification difficult to interpret.

REQUIREMENT: Export invoices for another system; PRESENT: How would you feel if available?; ABSENT: How would you feel if unavailable?; CLASSIFY: Use both answers and a published table.
A proposed paired-question path for hypothetical Ledger. Both answers must be evaluated together using a published classification table; no results are shown here.View larger diagram (opens in a new tab)

What the response categories mean

Must-be

Absent: dissatisfied

Present: expected basic

Performance

Less: less satisfied

More: more satisfied

Attractive

Absent: acceptable

Present: pleasantly surprised

Indifferent

Absent: little effect

Present: little effect

Reverse

Absent: preferred

Present: unwanted

Compare reactions to absence and presence. Performance compares levels of fulfillment. These are conceptual categories, not measured outcomes; questionable response pairs need investigation.

Read each category as a comparison between a feature being absent and present. Must-be requirements avoid dissatisfaction. Performance requirements reward improvement. Attractive requirements can add satisfaction without being expected. Indifferent and reverse responses warn against assuming that every addition helps.

These are conceptual relationships, not measured curves or fixed labels for all customers.

Must-be requirements

Customers expect these basics. Absence disappoints; adequate provision may earn little praise. Meeting a basic expectation is different from creating a reason to choose you.

Performance requirements

Also called one-dimensional requirements, these connect better performance with greater satisfaction. There is a meaningful tradeoff in how much to provide.

Attractive requirements

These can please customers when present without causing a comparable complaint when absent. Calling an idea a “delighter” in a planning meeting does not establish this response.

Indifferent and reverse responses

An indifferent response means presence or absence has little effect on satisfaction. A reverse response favors absence over presence. Different customer groups can respond differently to the same requirement.

Questionable response pairs are an analysis flag, rather than a useful feature category. Check for misunderstanding or contradictory answers before treating them as product direction.

Ask about presence and absence

A practical Kano questionnaire pairs two questions for each requirement: how someone feels if it is provided, and how they feel if it is absent. The questions are often called functional and dysfunctional. “Dysfunctional” means the absence condition, not a faulty customer answer.

Use a published Kano response scale and evaluation table consistently. Common response choices distinguish liking something, expecting it, feeling neutral, tolerating it, and disliking it. Map each person’s pair using that table before aggregating results. Do not classify a feature from its average importance rating or invent a scoring rule halfway through analysis.

Frame presence and absence at comparable detail. Asking about “instant export in every format” versus “no useful reporting” bundles several changes and leads the respondent. Test the wording with a few people before sending the full survey.

Write a pair that tests one requirement

The presence question and absence question should describe the same attribute at comparable detail. For Ledger Lane, a pair could ask about downloading a selected invoice in a stated file format and about not having that capability. Keep export speed, every possible format, and automatic delivery out of the wording unless those are the actual attributes being tested.

Use the published response options and classification table chosen for the study. A familiar five-choice version distinguishes liking the condition, expecting it, being neutral, tolerating it, and disliking it. The classification comes from each person’s pair of responses, not from a general popularity score.

Pilot the wording aloud. Ask participants what they think the capability would do and what they understand the absence condition to mean. If two people imagine different products, the main survey will collect answers to different questions.

Do not assume customers can evaluate a vague future concept. A short neutral description or prototype may help establish a shared meaning, but keep the presentation consistent across respondents. Promotional language can change the reaction you are trying to study.

These are research-design checks, not a new evaluation table. They help you apply an established Kano method without quietly replacing it with an improvised feature poll.

Interpret Ledger’s pattern without overclaiming

Its team initially calls themes the exciting differentiator. Interviews reveal that bookkeepers regularly need to transfer invoices to another system. The team follows up with paired questions about one clearly defined export behavior and one theme option.

In this invented scenario, bookkeepers treat export as a basic expectation and respond indifferently to themes. The team therefore investigates export failures before funding customization. It does not claim that themes are universally unimportant. It has learned that the chosen customer group does not see them as a useful answer to its current work.

The next decision still needs cost information. A complicated export rebuild may justify a smaller interim fix. Kano locates the satisfaction risk; it does not choose the engineering approach.

Keep the distribution behind the label

In the hypothetical Ledger Lane example, “export is a basic” summarizes the dominant reaction in the chosen bookkeeper group. The team still needs to see how many responses fell into each category and whether a subgroup reacted differently.

A table of category counts can reveal disagreement that a single winning label hides. Some users may not need export at all, while specialists depend on it daily. Pooling them without examining that difference could lead to a misleading product decision.

The same caution applies to “delighters.” An attractive response does not tell you how frequently the capability will be used or whether customers would pay enough to cover it. Follow up with evidence appropriate to the actual decision.

For Ledger Lane, the next investigation is a concrete export task. Can a bookkeeper obtain the file needed by the receiving system? Does the proposed smaller fix solve the present failure? A large rebuild might remain unnecessary even if export matters a great deal.

The team can then compare feasible options with effort, risk, and other obligations visible. Kano has identified a satisfaction pattern worth taking seriously; it has not selected the technical solution or created a delivery schedule.

Revisit the pattern when the audience or baseline changes. A feature that once surprised users can become an expectation. Preserve the study date and requirement wording so a later team can tell what the original finding actually covered.

Use the pattern to choose the next investigation

In this fictional case, the chosen group treats export as a basic and themes with indifference. Ledger still needs the category distribution, differences between groups, and evidence about the actual export failure. A winning label alone compresses too much.

The next task is to test whether a smaller fix lets a bookkeeper obtain the required file. Kano has exposed the satisfaction risk of ignoring export. Cost, feasibility, commitments, and behavior still matter when choosing how to respond.

PATTERN: Export basic; themes indifferent; CHECK: Inspect segments and category counts; NEXT: Test a smaller export fix; CAUTION: Satisfaction category is not a priority score.
The response pattern is fictional. Inspect category counts and segments before choosing a technical response; Kano is not a priority score.View larger diagram (opens in a new tab)

How to apply it to a roadmap decision

FrameworkWorld recommends this sequence for a small product team:

  1. Name the customer group and decision. Avoid pooling occasional users with specialist operators unless you can inspect both groups separately.
  2. Select a short list of concrete requirements. Describe behavior a customer can understand without seeing the implementation.
  3. Pilot paired questions, then collect responses from people who match the intended group.
  4. Classify each response pair. Retain category counts and inspect mixed results instead of reporting only a winning label.
  5. Discuss the evidence alongside delivery effort, existing failures, and business constraints. Investigate reverse and questionable responses.
  6. Choose a small next action and a later review point. Recheck assumptions when the audience or competitive baseline changes.

If the pilot shows that people do not understand a requirement, stop and rewrite it. More answers to an unclear question will not make the classification useful.

Limitations and common mistakes

Do not classify requirements by intuition and present the result as customer research. If the team is making an initial hypothesis, label it as one.

Survey answers describe stated reactions, not observed buying or retention. Follow promising results with a prototype, usability session, or behavioral test appropriate to the decision. A small or biased sample cannot establish a market-wide category.

Expectations can change, and a single label can conceal disagreement between groups. Preserve the response distribution. Kano also leaves out delivery cost, dependencies, commercial return, and obligations that must be met regardless of customer enthusiasm.

Jobs to Be Done helps investigate why a customer needs progress in a particular circumstance. Use interviews when you do not yet understand the problem well enough to write a meaningful requirement.

RICE Prioritization compares reach, impact, confidence, and effort. Kano evidence can inform an impact discussion, but an attractive category is not a numeric RICE impact score. Use both only when the extra research would change the decision.

Sources and further reading