Not on the Foundation Level exam
The Kano model is not Foundation Level content. The CPRE Foundation Level syllabus (English v3.2.0, 26 February 2024) does not treat Kano categories, and the glossary (v2.2.0) does not define them. If you use Kano on a project, label it as an external convention. Do not imply that IREB examines it.
It is still one of the few pictures that explains a thing quality requirements keep tripping over: last year’s delight is this year’s unspoken expectation. That temporal decay is an interpretation, not a syllabus statement. Treat it as practice.
This page is an explainer. The diagram on the right (or above, on a narrow screen) advances as you move through the beats. If you prefer reduced motion, the same steps are stacked and labelled; nothing is hidden.
How a delighter becomes an expectation
1. 1. Launch
1. Launch
flowchart LR
A[Unexpected capability] --> B[Noticed]
B --> C[Some delight]A new capability is unexpected. People notice it. Some are pleased.
2. 2. Spread
2. Spread
flowchart LR
A[Copied capability] --> B[Talking point]
B --> C[Thinner surprise]The capability becomes a talking point. Competitors copy it. The surprise thins out.
3. 3. Habit
3. Habit
flowchart LR
A[Assumed capability] --> B[Habit]
B --> C[Absence feels broken]People plan their work as if it were always there. Removing it now feels like a defect.
4. 4. Baseline
4. Baseline
flowchart LR
A[Unspoken expectation] --> B[Quality requirement]
B --> C[Or a silent fight at go-live]It is no longer a delighter. It is an unspoken quality expectation. Write it down as such, or it will still bind you.
1. Launch
flowchart LR
A[Unexpected capability] --> B[Noticed]
B --> C[Some delight]A new capability is unexpected. People notice it. Some are pleased.
1. 1. Launch
A new capability is unexpected. People notice it. Some are pleased.
2. 2. Spread
The capability becomes a talking point. Competitors copy it. The surprise thins out.
3. 3. Habit
People plan their work as if it were always there. Removing it now feels like a defect.
4. 4. Baseline
It is no longer a delighter. It is an unspoken quality expectation. Write it down as such, or it will still bind you.
Three curves, not a personality test
Noriaki Kano’s original work (1980s) classified features by how their presence or absence relates to satisfaction. Popular retellings use three curves: must-be (basic), one-dimensional (performance), and attractive (delight). Those labels are the convention you will hear in product meetings. They are not IREB terms.
- Must-be / basic
- One-dimensional
- Attractive / delight
Read the sketch as a warning, not as physics. The important practical claim is cheaper than the curves: delight is perishable. A capability that pleased people because it was unexpected will, after a year of use and a year of competitors, be treated as the floor. If you never wrote the quality requirement, you still own the floor.
What decays
1
Season to notice a copy
2
Seasons to plan work around it
n
Releases before absence feels broken
Those numbers are not measurements. They are reminders to put a date next to any "wow" you are tempted to leave unspecified.
What to write down instead of a Kano sticker
If a capability is currently a delighter, you still need the Foundation Level split:
- Is it a functional requirement (something the system shall do)?
- Is it a quality requirement (a characteristic you can check)?
- Is it a constraint (a limit already imposed)?
Kano does not replace that split. It tells you that a quality characteristic which today feels optional may be non-negotiable next year in the stakeholders' heads even if you never agreed a target. The remedy is boring: write the quality requirement with a scale before the delight finishes decaying, or explicitly accept that you will be surprised.
A year in the life of a delighter
Release · Month 0
The capability ships. Support hears compliments. Nobody writes a quality target. It feels too early to be pedantic.
Copy appears · Month 4
A competitor ships a similar thing. The compliments stop being about you. They become about the category.
Habit · Month 8
Clerks schedule their Friday around the export. An outage now generates tickets that sound like defects, not like missing delights.
Roadmap fight · Month 12
Someone proposes removing the capability to fund a new surprise. The room discovers it had become a baseline quality expectation with no owner and no measure.
Prioritisation is a different job
MoSCoW, Kano stickers, and "value versus effort" scatter plots are all external conventions. The Foundation Level will not examine you on them. What it will examine is whether you can specify a quality requirement so it can be validated and verified, and whether you can tell a constraint from a wish.
If you use a scatter plot, keep it honest: it is a conversation aid, not a measurement.
- Candidate quality work
Export time sitting high-left is not a law of nature. It is a claim you can take to a stakeholder. The decaying delighter sitting high-right is a claim that the surprise will cost more than the baseline you already failed to write down.
What to take into the next meeting
Say out loud: Kano is not the syllabus. Then ask which of last year’s surprises are now silently required. Write those as quality requirements with a scale, or accept the fight. Do not store them as "delight" in a backlog column and hope the column is a specification.
The explainer steps at the top are the whole article in four pictures. If you only remember the fourth, that is enough: absence of a former delighter will be reported as a defect. Specify it, or plan for the tickets.
What to tell a steering group without teaching Kano
Steering groups do not need the curves. They need a sentence they can fund. Try this: "Some capabilities that were optional last year are now treated as defects if they are missing. We will either write them as quality requirements with a scale, or we will formally drop them. We will not leave them in a delight column." That sentence uses Foundation Level kinds. It does not require anyone to remember must-be, one-dimensional, or attractive.
If they ask for a model name, you can say Kano is an external convention used here only as a warning about time. If they ask for a number, do not invent a decay rate. Date the last observation and say when you will classify again. If they ask whether this is in the syllabus, say no, and then say the action still uses syllabus tools: quality requirements, constraints, validation of the specified system as stakeholders now understand it.
The cost of the wrong speech is a roadmap that funds surprises and a test team that is blamed for basics. The cost of the right speech is a few quality requirements that look unglamorous. Unglamorous quality requirements are how you stop being surprised. The charts on this page are a picture of that warning, not a measurement of your product. Do not put them in a board pack as if they were data.
Why roadmaps keep being surprised
Product language loves the word delight because it sounds like extra, and extra sounds optional. Quality requirements language is ruder: if stakeholders will treat the absence as a failure, you have a quality expectation whether or not you wrote it down. Decay is the mechanism that turns extra into expected without a change request. Competitors copy. Users adapt their week. Support starts classifying the outage as a defect because that is how it feels.
A programme that tracks "delight items" in a separate column is often trying to protect them from being specified. The protection works until month twelve. Then the column is used as evidence that the thing was never a requirement, and the tickets are used as evidence that it was. Both sides will be able to quote the board. Neither side will have a measure.
The Foundation Level way out is not to adopt Kano as a process. It is to keep using the three kinds of requirement and to notice when a former surprise has become a quality characteristic of the system as stakeholders now understand it. At that moment, write the quality requirement or formally drop the capability. Informal delight is not a third kind. It is an unrecorded quality requirement with a time bomb.
There is a related trap on the basic curve. Must-be characteristics are easy to under-specify because nobody thanks you for them. Search returning at all, export files that open, audit trails that exist — these do not feel like innovation. They are often the actual quality requirements the organisation will defend under pressure. If your roadmap is all delighters and your specification is silent on the basics, you are specifying the brochure.
Scatter plots of value against effort do not save you unless the "value" axis is named. Value to whom, on what evidence, decaying on what timescale? A delighter scored high-value in month zero and left unscored in month twelve is not a prioritisation. It is nostalgia. If you must use a plot, date the scores and say they expire.
Finally: do not import Kano into an IREB training context as if it were hidden syllabus. It is a useful warning about time. The syllabus already gave you the tools to act on the warning — quality requirements with scales, constraints with sources, validation as a different question from review. Use those. Leave the curves in the explainer, where they cannot pretend to be a measurement.
If you are asked to "do a Kano" in a workshop, you can still keep the Foundation Level honest. Collect statements. Classify each as function, quality, or constraint. Then, separately, notice which quality statements stakeholders currently treat as surprises. Date that observation. Do not treat the observation as a score. When you return in six months, classify again. If a former surprise is now spoken as a defect, write the quality requirement. That is decay, recorded as work, not as a curve. The timeline on this page is the same idea without pretending the vertical axis was measured.