A roadmap built entirely from must-haves is not a safe roadmap — it is a roadmap that guarantees satisfaction plateaus at "acceptable" and never rises. The Kano model groups features into basic, performance, and delight categories, each with a different satisfaction curve, and the fix is to deliberately reserve capacity for at least one delighter per planning horizon rather than let basics crowd it out by default.
Quick Answer: Kano prioritization sorts features by how satisfaction responds to investment — basics prevent dissatisfaction but never create it, performance features scale linearly, and delighters create disproportionate satisfaction cheaply, but decay into expected basics over time. Budget roadmap capacity across all three, not just the first.
What the Kano Model Actually Categorizes
The Kano model, developed by Noriaki Kano in the 1980s, sorts features by the shape of the relationship between how much you invest and how satisfied customers become — not by how important they feel in a meeting. Three categories dominate most roadmaps, and a fourth explains why some features are simply wasted effort.
- Basic (must-be) features: their absence causes severe dissatisfaction, but their presence barely registers as satisfaction. A banking app that doesn't load your balance correctly is unusable; loading it correctly earns no credit.
- Performance (one-dimensional) features: satisfaction scales roughly linearly with investment. Faster checkout, more storage, higher accuracy — more is better, and customers notice the difference in either direction.
- Delight (attractive) features: their absence isn't noticed, but their presence creates disproportionate satisfaction relative to the investment. These are the features nobody demanded but everyone remembers.
- Indifferent features: customers don't care either way, regardless of investment — often the quiet home of "nice sounding" backlog items that never move a metric.
The categorization comes from Kano's original survey methodology — pairing a "functional" question (how do you feel if this feature is present?) with a "dysfunctional" question (how do you feel if it's absent?) — not from internal debate about what feels important. That distinction matters because teams routinely mistake a basic feature for a delighter simply because it's hard to build.
Why the Categories Aren't Static
A feature's category is a snapshot, not a permanent label. Delighters decay into performance features, and performance features decay into basics, as an entire market adopts them and customers recalibrate what "normal" means. GPS navigation in a car was a delighter in the early 2000s; today its absence would be a basic-level failure.
This decay is the single most under-planned dynamic in roadmap prioritization. Teams that shipped one great delighter three years ago and stopped investing in new ones are often confused why customer satisfaction has quietly slid back down — the old delighter simply became table stakes, and nothing replaced it.
Why an All-Basics Roadmap Yields Diminishing Returns
A roadmap that only fixes must-haves and only ships performance improvements will, at best, move customers from dissatisfied to neutral — it structurally cannot generate the satisfaction gains that come from disproportionate, unexpected value. Satisfaction is non-linear across categories, and ignoring that non-linearity is why "we shipped 40 things this quarter" so often fails to move NPS.
The trap is psychologically understandable: basics feel urgent because their absence is loud (support tickets, churn interviews, sales objections), while delighters feel optional because their absence is silent. This asymmetry means basics will always win a reactive prioritization process, even when the marginal basic fix returns far less satisfaction per unit of effort than a modest delighter would.
| Category | Effect of absence | Effect of presence | Marginal ROI as you invest more |
|---|---|---|---|
| Basic | Severe dissatisfaction | Little to no satisfaction gain | Flattens fast — diminishing returns past "adequate" |
| Performance | Moderate dissatisfaction | Proportional satisfaction | Roughly linear — steady, predictable returns |
| Delight | Unnoticed | Disproportionate satisfaction | High per unit of effort, until it decays into a basic |
Read plainly: past a certain point, pouring more effort into basics is like re-painting a wall that was already an acceptable color — customers won't notice, but the resources are gone. That's the diminishing-returns mechanism, and it's why an outcome-based roadmap vs. a features list matters here — a features list happily counts fixed basics as "progress" long after the satisfaction curve has flattened, as explored in outcome-based roadmap vs. features shipped.
The Compounding Cost of Under-Investing in Delight
Skipping delight isn't neutral — it's a slow bleed. Competitors' delighters become your customers' expectations even if you never build them yourself, because customers benchmark against the best experience they've had anywhere, not just in your category. A roadmap frozen on basics eventually looks stale even while every ticket gets closed.
The Shift: Allocate Across Categories on Purpose
The fix isn't complicated in concept, only in discipline: treat category allocation as a deliberate roadmap decision, the same way you'd allocate budget across paid channels, rather than letting whichever category screams loudest each sprint win by default. Most teams need an explicit rule, because reactive prioritization always drifts toward basics.
A workable rule of thumb: reserve at least one delighter slot per planning horizon — one per quarter, or one per major release, whichever cadence your organization uses — and protect it the way you'd protect a security fix, not treat it as the first thing cut when basics pile up. Alongside that:
- Audit your current roadmap by category first. Before adding anything new, tag every item already in flight as basic, performance, delight, or indifferent — most teams discover indifferent features quietly consuming a third of their capacity.
- Cap basics at "meets the bar," not "perfect." Basics have a ceiling; investing past adequate is often better spent elsewhere.
- Protect one delight slot per horizon, sized modestly — delight is about disproportion relative to effort, not about scale.
- Re-survey categories periodically. What was a delighter last year may have decayed into a basic; skipping this step is how roadmaps end up stale without anyone noticing.
- Communicate the mix, not just the list. Stakeholders accept a smaller basics list more easily when they see the delight slot was a deliberate trade, not a shortfall — this is where communicating roadmap uncertainty honestly pays off.
How This Plays Out on a Now-Next-Later Roadmap
Category allocation maps cleanly onto a horizon-based roadmap. "Now" is dominated by basics and any performance work already committed; "Next" is where a protected delight slot should live before it gets crowded out; "Later" is where you place bets on delighters for a category you expect to matter once current delighters decay. Structuring it this way keeps the now-next-later roadmap honest about what's a commitment versus a bet, rather than implying every horizon carries equal certainty.
Where the Data for Kano Categorization Actually Comes From
Guessing categories from a product meeting is the most common failure mode — the fix is to source categorization from the same evidence you'd use for any prioritization decision, not from internal conviction about what feels exciting. Three real, established sources are worth naming.
- Kano's own paired-question survey methodology remains the most direct way to categorize a specific feature, asking customers both the functional and dysfunctional versions of the question and cross-referencing the answers in Kano's evaluation table.
- Jobs-to-be-Done research (Clayton Christensen's framing, extended by Tony Ulwick's outcome-driven innovation) surfaces which underlying jobs are under-served, which is often a faster route to spotting a genuine delight opportunity than surveying features directly — see the full Jobs-to-be-Done guide for how outcome statements translate into opportunity scores.
- Customer journey mapping highlights emotional low points where a small delight investment disproportionately changes the overall experience, versus emotional dips so severe they're actually basic-level failures in disguise — the customer journey guide covers how to read those curves accurately.
Directionally, product research bodies like the Product Development and Management Association have long observed that customer-perceived differentiation clusters around a small number of features per release — reinforcing that spreading effort thin across many "nice" ideas produces less satisfaction lift than concentrating it on one well-chosen delighter.
Bringing Kano Prioritization Into Your Prioritization Process
That visibility matters most at the moment basics are piling up and it's tempting to quietly cut the one delighter in the plan — having the category mix in front of you, next to the roadmap itself, makes that trade-off a conscious decision instead of a default. For teams building out a fuller roadmapping practice, this pairs naturally with the broader frameworks covered in the complete guide to roadmapping.
Key Takeaways
- Kano categories describe a satisfaction curve, not an importance ranking — basics prevent dissatisfaction, performance scales linearly, delighters create disproportionate satisfaction cheaply.
- An all-basics roadmap plateaus because basics have a satisfaction ceiling; effort past "adequate" returns little.
- Delighters decay into basics as markets adopt them, so a roadmap needs continuous delight investment, not a one-time win.
- Reserve at least one delight slot per planning horizon and protect it the way you'd protect a critical fix, rather than treating it as discretionary.
- Source categorization from evidence — Kano's paired-question surveys, Jobs-to-be-Done research, or customer journey mapping — not from which feature feels most exciting in a meeting.
- Visibility drives discipline: seeing the category mix next to the roadmap, as in Prodinja's Kano Prioritization view, makes trading away delight a conscious choice instead of a quiet default.
Frequently Asked Questions
What is the Kano model in product management?
The Kano model is a framework, developed by Noriaki Kano, that classifies features by how satisfaction responds to investment: basic features prevent dissatisfaction, performance features scale satisfaction linearly, and delight features create disproportionate satisfaction from modest effort.
How do you prioritize between must-have and delight features?
Prioritize must-haves up to the point where they meet the acceptable bar, then stop — further investment there yields diminishing returns. Reserve dedicated, protected capacity for at least one delight feature per planning horizon so it isn't crowded out by basics.
Why do delight features eventually stop delighting?
Delight features decay into expected basics as the broader market adopts similar functionality and customers recalibrate what "normal" looks like — a delighter from a few years ago (like GPS navigation) can become a baseline expectation today.
How is a Kano performance feature different from a basic feature?
A basic feature's absence causes severe dissatisfaction, but its presence adds little beyond meeting expectations. A performance feature's satisfaction scales roughly linearly with how much you invest — more speed, more accuracy, or more capacity keeps registering as better.
How much roadmap capacity should go toward delight features?
There's no universal percentage, but a practical rule of thumb is at least one meaningfully protected delighter per planning horizon — enough to be noticed, sized modestly enough that it doesn't crowd out committed basics and performance work.