Il Kano model è un framework di prioritizzazione delle feature di prodotto sviluppato da Noriaki Kano nel 1984 (Tokyo University of Science). Mappa ogni feature lungo due assi — livello di implementazione sull'asse X e customer satisfaction sull'asse Y — e le classifica in 5 categorie con curve diverse. È uno dei pochi tool che riesce a distinguere quali feature sono obbligatorie da quelle che differenziano, da quelle che delizziano.
In questo articolo: cosa sono le 5 categorie, come si fa un Kano survey con utenti reali, come si applica il risultato alla roadmap, esempi concreti di prodotto e errori comuni nell'applicazione.
Le 5 categorie del Kano model
1. Must-be (Basic)
Feature attese come scontate. La loro presenza non aumenta la soddisfazione (l'utente le dà per ovvie), ma la loro assenza causa insoddisfazione massiva. La curva è una L invertita: piatta in alto a destra, crollo verso il basso quando manca.
Esempi: in un'app banking, "vedere il saldo del conto"; in un sito e-commerce, "poter vedere le foto del prodotto"; in un'app di chat, "ricevere notifiche di nuovi messaggi".
2. Performance (One-dimensional)
Feature dove più ce n'è, più aumenta la soddisfazione, e meno ce n'è, più diminuisce. La curva è una linea diagonale crescente. Sono feature "lineari".
Esempi: velocità di caricamento di un sito (più veloce = più felice); numero di film su Netflix; durata batteria di uno smartphone.
3. Delight (Attractive / Excitement)
Feature che l'utente non si aspetta. La loro assenza non causa insoddisfazione (nessuno le chiede), ma la loro presenza genera entusiasmo sproporzionato. La curva è esponenziale: parte da zero e cresce rapidamente.
Esempi: la prima volta che Slack ha messo gli emoji reactions; quando Spotify ha introdotto il Wrapped annuale; il primo riconoscimento facciale su iPhone.
4. Indifferent
Feature che a nessuno interessa. La loro presenza/assenza non sposta la soddisfazione. Sono feature da NON costruire perché bruciano risorse senza generare valore.
Esempi: opzioni di personalizzazione che gli utenti non scoprono; integrazioni con tool che non usano; impostazioni avanzate che resta nascoste.
5. Reverse
Feature che — sorprendentemente — riducono la soddisfazione quando presenti. Più ce ne sono, peggio è. Spesso emergono in segmenti di utenti diversi.
Esempi: notifiche push troppo frequenti; pop-up di registrazione obbligatoria; menù complessi in un prodotto che dovrebbe essere semplice.
Come fare un Kano survey
Il Kano survey è un questionario standardizzato dove per ogni feature poni 2 domande all'utente:
- Domanda funzionale: "Come ti sentiresti se questa feature fosse presente?"
- Domanda disfunzionale: "Come ti sentiresti se questa feature NON fosse presente?"
L'utente risponde a entrambe con 5 opzioni:
- Mi piacerebbe
- Mi aspetto che ci sia
- Sono indifferente
- Posso conviverci
- Non mi piacerebbe
L'incrocio tra le due risposte mappa la feature in una delle 5 categorie tramite una matrice standard pubblicata da Kano.
Quanti utenti servono
Per un Kano survey statisticamente rilevante: almeno 30 risposte per segmento di utenti, 50+ per risultati robusti. Sotto i 20 i risultati sono indicativi ma non azionabili. Sopra i 100 la classificazione si stabilizza.
Tool consigliati: SurveyMonkey, Typeform, Google Forms con la matrice di scoring incorporata.
Come applicarlo alla roadmap di prodotto
Una volta classificate le feature, la priorità è chiara:
- Build prima tutte le Must-be. Senza queste, il prodotto è inaccettabile.
- Investi in Performance: più ne fai, meglio è. Ottimizza queste fino al budget.
- Aggiungi 1-2 Delight per release: troppe non funziona (l'utente si abitua e diventano performance), troppo poche e perdi differenziazione.
- Cancella le Indifferent: ogni risorsa qui è bruciata.
- Rimuovi le Reverse per i segmenti dove sono problematiche.
Esempio reale — Kano applicato a un'app fitness
Un team di prodotto sta lanciando un'app fitness. Hanno 12 feature candidate. Dopo Kano survey con 80 utenti scoprono:
- Must-be: tracking GPS, contatore calorie, log allenamenti
- Performance: precisione GPS, velocità di sync, qualità grafica
- Delight: badge social condivisibili, integrazione musica
- Indifferent: opzioni di personalizzazione avatar, modalità competitiva
- Reverse (per segmento "casual"): gamification spinta che gli utenti casual percepiscono come pressante
Risultato roadmap: priorità 1 alle 3 must-be (richieste in MVP); priorità 2 a ottimizzare GPS e sync; 1 delight (badge social) nel lancio; rimosse personalizzazione avatar e modalità competitiva (non per il primo segmento target).
I 4 errori comuni
1. Non distinguere segmenti. Una feature è Delight per power user e Indifferent per casual. Senza segmentazione, il risultato è una media inutile.
2. Far evolvere Delight in Performance senza notare. Una Delight (es. emoji reactions) diventa una Must-be quando i competitor la copiano. Il Kano va rifatto periodicamente.
3. Survey troppo lungo. Più di 15 feature in un singolo Kano survey produce drop-off. Suddividi in più survey.
4. Confondere "vorrei" con "userei". Gli utenti dicono di volere feature che poi non usano. Combina sempre Kano con dati di utilizzo reali.
Kano vs altri framework di prioritizzazione
- RICE (Reach × Impact × Confidence ÷ Effort): più quantitativo, basato su business case
- MoSCoW (Must/Should/Could/Won't): più semplice, meno granulare
- Value vs Effort matrix: 2×2 standard, perde la dimensione "delight"
- Kano: meglio per capire il tipo di feature, non solo la priorità
Best practice: combina Kano con un altro framework. Kano dice che tipo di feature è; RICE/MoSCoW dice quale prima costruire.
Domande frequenti
Quanto tempo serve per un Kano survey completo?
Setup del questionario 1-2 giorni, recruitment utenti 3-7 giorni, analisi 1 giorno. Totale 1-2 settimane. Per team che hanno già una community di utenti via email/in-app è più rapido (3-5 giorni totali).
Funziona per prodotti B2B o solo B2C?
Funziona ottimamente per B2B, anzi forse meglio. I decision maker B2B hanno aspettative più definite (must-be più chiare) e segmenti più distinti. Considera 30 utenti per ruolo (admin, end user, finance) invece di un'unica popolazione.
Posso applicarlo da junior PM/designer?
Sì, è uno dei framework più democratici. La matematica è semplice (incroci di una matrice 5×5). Il valore è nella discussione di team che il survey provoca, non nell'esecuzione tecnica.
Quanto spesso rifare il Kano per lo stesso prodotto?
Ogni 12-18 mesi è ragionevole. Le aspettative degli utenti evolvono, le delight diventano performance, le must-be cambiano (es. integrazione AI è passata da delight a performance in 18 mesi).
Cosa fare se non ho utenti reali (pre-lancio)?
Usa proxy: utenti di prodotti simili, beta tester recruited via comunità, utenti dei competitor. I risultati sono meno robusti ma utili per priorità di MVP. Rifai il Kano dopo 6 mesi di lancio con utenti reali.
Prossimi passi
Kano è uno dei framework di prodotto che ogni UX designer dovrebbe conoscere per dialogare con product managers. Per imparare ricerca utente sistematica — interviste, test, analisi, sintesi — il Corso di User Research di CorsoUX copre 9 capitoli con 62 lezioni e mentor 1:1. Per il percorso completo (research + design + writing) il Corso UX Design Completo.
Per altri framework correlati: Jobs to be Done, le metriche UX e la customer journey map.
