Prioritisation Framework · 8 min read
Teams tend to add features that sound exciting in planning sessions but don't meaningfully improve user satisfaction — while neglecting features that feel boring but whose absence would cause users to leave. The Kano Model, developed by Professor Noriaki Kano, provides a structured way to categorise features by their actual impact on satisfaction — not their theoretical value. It forces teams to think about features as user experiences, not as engineering tasks.
These are features users take for granted. When absent, users are extremely dissatisfied and will switch. When present, they feel neutral — no delight, no extra satisfaction. Think of the "table stakes" of your category. In fintech, KYC completion, transaction confirmation, and password reset are Basic Needs. In e-commerce, order tracking is a Basic Need. Users never say "wow, I love how this app lets me reset my password!" — but they'll leave the first time they can't.
Performance features have a linear relationship with satisfaction — the better you execute them, the more satisfied users are. Faster page load → more satisfaction. More investment options → more satisfaction. More detailed analytics → more satisfaction. These are the features users talk about when comparing products, and where competitive differentiation happens. Most product roadmaps are dominated by Performance features because they're easy to reason about (more = better).
Delighters are features users never asked for but react to with disproportionate enthusiasm when they discover them. Their absence causes zero dissatisfaction (users didn't know to expect them), but their presence creates delight — which drives word-of-mouth, NPS scores, and app store reviews. These are the features that get mentioned in "I love this app because..." conversations. Critically: Delighters have a shelf life. Today's delighter becomes tomorrow's Basic Need as the category catches up.
Features users genuinely don't care about. Present or absent — satisfaction doesn't change. Every backlog has these. The Kano survey surfaces them by asking users how they'd feel in both states. Teams are often surprised how many planned features land in Indifferent territory. The correct action is to deprioritise them entirely — not to reframe the pitch or improve the UX. If users are truly indifferent, there is no UX refinement that will change that. Cut them and reallocate the engineering time to Basic Needs or Performance features.
The Kano survey is how you determine which category a feature belongs in. For each candidate feature, ask users two questions — the functional form (how do you feel if this feature IS present?) and the dysfunctional form (how do you feel if this feature is NOT present?). Users respond from a 5-option scale for both questions.
"How would you feel if you could pay for transactions under ₹500 with a single tap — no PIN required?"
"How would you feel if you had to enter your PIN for every UPI transaction, regardless of amount?"
Map functional and dysfunctional responses to categories using this lookup grid:
| Functional → Dysfunctional ↓ |
I like it | I expect it | I'm neutral | I can tolerate it | I dislike it |
|---|---|---|---|---|---|
| I like it | Questionable | Delighter | Delighter | Delighter | Performance |
| I expect it | Delighter | Indifferent | Indifferent | Indifferent | Basic Need |
| I'm neutral | Delighter | Indifferent | Indifferent | Indifferent | Basic Need |
| I can tolerate it | Delighter | Indifferent | Indifferent | Indifferent | Basic Need |
| I dislike it | Performance | Basic Need | Basic Need | Basic Need | Questionable |
| Feature | Category | Prioritisation call |
|---|---|---|
| Loan disbursement within 24 hours | Basic Need | Fix immediately if failing — this is table stakes for the category |
| Real-time loan status tracker | Basic Need | Users expect to know where their application is at all times |
| Competitive interest rate display | Performance | Lower rates → more satisfaction, linearly. Competitive priority. |
| Loan tenure flexibility (3–36 months) | Performance | More options = more satisfaction. Under-deliver here and users comparison shop. |
| One-tap EMI payment from any bank | Delighter | Users didn't ask for it — but reaction is strongly positive. Build in R3. |
| Credit score improvement tips post-loan | Delighter | Unexpected value-add. Drives NPS and referrals. Build when Performance is solid. |
| In-app financial advisor chat | Indifferent | Low response either way. Cut from roadmap — not worth the support cost. |
| EMI calendar with Google Calendar sync | Indifferent | Nice to have in planning but users don't miss it. Deprioritise. |
| Dark mode | Indifferent | Consistently Indifferent across financial apps. Defer indefinitely. |
| Loan pre-closure with no penalty | Basic Need | Absence causes strong dissatisfaction. Must have before acquisition scales. |
The Kano Model has a time dimension that most teams ignore: every Delighter eventually becomes a Basic Need as the market matures. WhatsApp payments were a Delighter in 2018 — users didn't expect it and were delighted. Today, absence of UPI payment in a financial app is a Basic Need — a hard blocker. One-day delivery was a Delighter on Flipkart in 2015; now it's table stakes for fast-moving categories.
This means you need to re-run your Kano survey every 12–18 months. Features that were Delighters 18 months ago may now be Basic Needs that are quietly causing churn if you haven't maintained quality on them while investing in new Delighters.
We design and run Kano surveys for Indian product teams — identifying which roadmap items are Basic Needs vs Delighters vs Indifferent features you're wasting engineering on. Book a session.
Book Free Session