The Kano model has been around for decades, and on paper it looks elegant: features get sorted into categories like basic, performance, and delighters. Teams then use that categorisation to decide what to build.
But here’s the problem: as a prioritisation model for MVPs, Kano is deeply flawed.
Kano is rooted in one dimension—satisfaction. But satisfaction is not a reliable leading indicator. What delights one user might feel irrelevant to another. What’s seen as “basic” today may become a “delighter” tomorrow, or vice versa. It’s slippery, interpretive, and highly dependent on who you ask and when you ask them.
If your MVP scope is built on subjective feelings, you’re essentially gambling.
Kano works better as a heuristic lens for existing features—to look back at what you’ve built and see how it resonates. It can tell you which areas might feel stale, which features still drive excitement, and which have sunk into the “must-have” baseline.
But when it comes to new development, Kano doesn’t tell you what actually matters for your business, your product strategy, or your customers’ outcomes. It doesn’t tell you whether you’re solving the right problem, learning the right thing, or driving the right metric.
To be clear, Kano does have value. It helps us understand how features land with customers by categorising them into:
Must-be (Basics): Fundamental features customers expect. Their absence creates dissatisfaction, but their presence doesn’t create delight.
Performance: Features where better quality directly improves satisfaction (e.g., faster load times, higher efficiency).
Attractive (Delighters): Unexpected features that spark delight without being essential.
Indifferent: Features that don’t meaningfully change satisfaction.
Reverse: Features that frustrate if present, but please if absent.
This lens is useful when you already have a product in market—it highlights what’s become table stakes, what still creates value, and where you might sprinkle in moments of delight.
But that’s exactly the point: Kano looks backward, not forward. It’s better suited to product evolution than product inception.
This aligns with what I call the Product Hierarchy of Needs:
At the bottom, you have Fundamentals (fixing what’s broken, meeting basic expectations). This is where Kano’s must-be category fits neatly.
As you move up, you hit Seamless Experience and Strategic Enablement—this is where performance features matter most.
And only once you’ve nailed the foundations can you realistically pursue Delight and Advocacy—exactly where Kano’s attractive/delighter category lives.
The risk is when teams try to use Kano too early—basing MVP decisions on delight or satisfaction curves, when they should be focused on proving fundamentals and measurable outcomes first.
Every MVP—whether it’s solving a known problem or exploring a new opportunity—should be rooted in measurable goals.
Adoption → Did anyone actually use it?
Activation → Did they reach the intended outcome?
Retention → Did it create repeat value?
Revenue → Did it generate willingness to pay?
Those are signals you can track, test, and learn from. They give you clarity on whether you’re moving forward—or just creating motion.
Satisfaction, on the other hand, is a byproduct. It’s something you earn when you deliver on real goals.
At the root, most MVPs are built for one of two reasons:
Problem-Solving → You’ve identified a clear pain point and want to validate whether your solution actually works in practice.
Traction-Seeking → You’re testing the waters, gauging interest, or proving that there’s demand before you scale further.
Both are valid—but both must be anchored in measurable outcomes.
A problem-solving MVP might measure activation or retention.
A traction-seeking MVP might focus on adoption or early willingness to pay.
What they can’t be measured on is subjective “satisfaction.” A Kano-style CSAT score doesn’t tell you if the problem is worth solving or the opportunity worth chasing.
If not Kano, then what? Here are more robust ways to prioritise MVPs:
Outcome-Driven Roadmaps
Anchor your backlog to measurable business and customer outcomes, not feature buckets. Ask: What outcome do we want to see in the next 90 days? Which experiment has the highest chance of proving/disproving that?
North Star Metrics
Tie every MVP back to your product’s north star (e.g., “active teams creating boards” for Miro, “songs played per user per day” for Spotify). If it doesn’t move the needle, it doesn’t ship.
Assumption Testing
Break your big risky bet into its riskiest assumptions. Prioritise MVPs that directly test those assumptions fastest. This keeps you honest and reduces wasted cycles.
Impact vs Effort Mapping
A classic, but still more reliable than satisfaction curves. Plot ideas against impact on key metrics vs effort to deliver, and you’ll often spot clearer MVP candidates.
Instead of asking:
Will this feature delight people?
Start asking:
What measurable outcome will this MVP drive, and how will it help us learn faster?
Because at the end of the day, MVPs aren’t about delight. They’re about reducing risk, accelerating learning, and proving whether your product has a reason to exist.
If this resonates, I dive deeper in my eBook Broken by Design—a guide to the myths, traps, and misuses of MVPs, and how to avoid them by anchoring your product work in clarity, measurable outcomes, and intent.
🎁 To celebrate the launch, I’m offering 50% off the first 50 copies of Broken by Design—exclusively for early readers.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.