Kano and the Innovator's Dilemma Are the Same Thing
Most people take one thing away from Clayton Christensen's Innovator's Dilemma: big companies can't innovate. That's the headline, not the insight.
The actual insight is structural. It describes a band of customer value: how companies climb into it, what happens when they reach the top, and why someone new always arrives below them on a different trajectory. Christensen was precise about this. He publicly pushed back on Uber being called a disruptor, because Uber didn't fit the model. The enabling technology (mobile, GPS, real-time matching) collapsed the disruption timeline in a way his framework wasn't built to track. That's a meaningful distinction, not a technicality. The Dilemma was written as a handbook for understanding how disruption unfolds stage by stage. Uber skipped stages.
Map Kano's satisfaction model onto the disruption band and you get something neither framework gives you alone. Christensen's model is precise but dense: the 3D diagrams in the book are notoriously hard to interpret. Kano is easy to reason about. Together they give you an operating model for knowing what to build and when.
The band
Christensen's disruption follows a consistent pattern. An innovator enters with a product that performs worse on the metrics the incumbent's customers care about, but better on a different dimension. The incumbent's customers correctly reject it: it doesn't serve their needs yet. The innovator improves along their own trajectory until they're good enough on the old metrics and untouchable on the new ones. By then, the incumbent can't respond.
The reason they can't respond isn't that they're pointed in the wrong direction. It's that optimisation is the only move available to them. Their engineering, sales, culture, and incentive structures are all built to do one thing: make the existing product better on the dimensions that existing customers currently reward. That machine doesn't have a reverse gear.
Source: Disruptive innovation, Wikipedia (CC)
Kano maps onto the band cleanly
Kano's model classifies product attributes into three types: must-haves (absence causes dissatisfaction, presence is neutral), performance attributes (more is better, linearly), and delighters (unexpected features that create disproportionate satisfaction).
Source: Kano model, Wikipedia (CC)
Here's how they map across the disruption lifecycle:
Climbing the band (early stage)
At entry, you need must-haves, table stakes that prevent immediate rejection. But must-haves alone don't drive switching. Nobody migrates to a new product to get the same things they already have from a product they trust. Switching costs are real. You need delighters: something compelling enough that customers tolerate your missing must-haves to get it.
This is where the minimum viable product orthodoxy often breaks down. A product that's all must-haves and no delighters is a product nobody switches for. When the iPhone launched in 2007, it was missing copy-paste, MMS, and a proper file system. Nokia had all three. Customers didn't care, because the touchscreen interface was a delighter so significant it redefined what a phone was supposed to do. The must-have gap got filled in later. The delighter came first.
The early-stage priority: must-haves for credibility, delighters for differentiation. Incremental performance improvements can wait. You don't have enough users for marginal gains to matter, and you don't yet know which dimensions your users will value most.
At the top of the band (mature stage)
Everything has converged. Your original delighters are now must-haves: competitors caught up, expectations rose, and what once felt remarkable now feels baseline. Every release is a slightly better version of what already exists. The Kano curve has flattened: no delighters, just incremental improvements that customers appreciate less each cycle.
This is the incumbent's trap. They didn't stop working. They didn't stop shipping. Optimisation just became the only play available, and they got very good at it.
Disruption from below
Here's what the band model reveals that's easy to miss: the disruptor isn't operating on a separate track. They're solving the next problem the customer doesn't yet know they have. The incumbent is optimising for yesterday's hunger. The disruptor is feeding tomorrow's.
By the time the customer is hungry, the disruptor is already there. The incumbent's roadmap (full of incremental improvements on dimensions that just became secondary) has no answer for it. The roadmap isn't wrong. It's the product of an optimisation machine, and optimisation machines can't explore.
What this means operationally
If you can classify your current work by Kano type, you can tell where you are in the disruption cycle.
- All must-have work: you're building table stakes. Necessary, but not differentiating. You won't win on this alone.
- All incremental work: you're at the top of the band. You're optimising, not innovating. Someone is approaching from below.
- Delighters in the mix: you're climbing. This is where you want to be.
The balance should shift with maturity:
Early: prioritise must-haves for credibility and delighters for differentiation. Skip incremental entirely: you don't have the user base or the data to justify it yet.
Growth: backfill incremental. Your must-haves work, your delighters attracted users. Now retention becomes a factor, and incremental improvements earn their place.
Mature: must-haves are commoditised and incremental is the baseline. New delighters are your only real competitive edge. If you don't have any in the pipeline, the disruption clock has started.
Two frameworks, one structure
Christensen tells you the pattern exists. Kano tells you what to build at each stage of it.
If you know where you sit, you know what to do next. Not approximately, specifically. Look at what your team shipped in the last quarter. Classify each item. The distribution tells you whether you're climbing, flattening, or already past the point of relevance.
That's the kind of thinking that belongs at the front of a product process, not at the back of a retrospective.