Modello Kano: ordina le richieste come le vivono i clienti
6 min di lettura
Il modello Kano è un modo per ordinare le funzionalità in base a come reagiscono i clienti quando ci sono e quando mancano, invece che in base a quante persone le hanno chieste. Lo ha proposto Noriaki Kano nel 1984 e mette ogni funzionalità in uno di cinque gruppi: obbligatorie (must-be), di prestazione, attrattive (di piacere), indifferenti e inverse. Per un team con una pila di richieste di funzionalità, la parte utile è che spiega perché una richiesta con decine di voti può non aggiungere nulla alla soddisfazione, mentre una richiesta che nessuno ha votato può cambiare il modo in cui le persone parlano del prodotto.
| Categoria | Reazione del cliente quando c’è | Reazione del cliente quando manca | Richiesta tipica |
|---|---|---|---|
| Obbligatoria (must-be) | Nulla, è attesa | Forte insoddisfazione | Reset della password, esportazione dei dati |
| Di prestazione | La soddisfazione cresce con il crescere della funzionalità | La soddisfazione cala con il calare della funzionalità | Velocità, spazio, limiti |
| Attrattiva | Piacere | Nulla, nessuno se la aspettava | Un’automazione ben pensata |
| Indifferente | Nulla | Nulla | Un’impostazione che pochi toccano |
| Inversa | Fastidio | Sollievo | Un tour forzato o un passaggio in più |
Quali sono le categorie del modello Kano?
Le funzionalità obbligatorie sono quelle che i clienti danno per scontate. Nessuno le elogia e tutti si accorgono quando si rompono. Le funzionalità di prestazione sono quelle in cui di più è meglio in linea retta, come report più veloci o limiti più alti. Le funzionalità attrattive sono inattese, quindi la loro assenza non costa nulla e la loro presenza genera entusiasmo vero. Le funzionalità indifferenti non spostano nulla in nessuna direzione, e quelle inverse rendono più contenti alcuni clienti quando vengono tolte.
La categoria è una proprietà di una funzionalità per un gruppo di clienti in un dato momento, ed è per questo che la stessa funzionalità può finire in gruppi diversi per segmenti diversi.
Come si conduce un sondaggio Kano?
Fai due domande per ogni funzionalità. La domanda funzionale chiede come si sentirebbe il cliente se il prodotto avesse la funzionalità. La domanda disfunzionale chiede come si sentirebbe se non l’avesse. Entrambe usano le stesse cinque risposte: mi piace, me lo aspetto, sono neutro, posso conviverci, non mi piace.
Combina le due risposte con la griglia di valutazione standard per classificare il giudizio di ogni rispondente su ogni funzionalità:
| Funzionale \ Disfunzionale | Mi piace | Me lo aspetto | Neutro | Ci convivo | Non mi piace |
|---|---|---|---|---|---|
| Mi piace | Q | A | A | A | O |
| Me lo aspetto | R | I | I | I | M |
| Neutro | R | I | I | I | M |
| Ci convivo | R | I | I | I | M |
| Non mi piace | R | R | R | R | Q |
M è obbligatoria (must-be), O è di prestazione (monodimensionale), A è attrattiva, I è indifferente, R è inversa e Q è una risposta dubbia che si contraddice. Conta le lettere tra i rispondenti per ogni funzionalità e prendi la più frequente come sua categoria. Quando due categorie sono vicine, riportale entrambe, perché una divisione 40/38 ti dice che il segmento è diviso, non che una risposta ha vinto.
Quali richieste di funzionalità vanno in un sondaggio Kano?
Solo quelle che prenderesti davvero in considerazione e che non sai ordinare a intuito. Da cinque a quindici funzionalità è una lunghezza di sondaggio gestibile, e ognuna ha bisogno di una descrizione di una frase che un cliente possa immaginare senza un mockup. Prendi i candidati dal backlog tracciato dopo aver raggruppato i duplicati, perché dieci richieste per la stessa cosa devono arrivare al sondaggio come una sola funzionalità. Il passaggio di raggruppamento è trattato in tracciare le richieste di funzionalità.
Lascia fuori le correzioni di bug e tutto ciò che è già promesso in un contratto. Un sondaggio non può dirti se correggere un crash.
Chi dovresti intervistare?
Le persone che usano già il prodotto, divise nei segmenti che contano per te. Un sondaggio inviato a tutta la lista tende a produrre la media di più gruppi diversi, e una media nasconde il risultato. Utenti gratuiti e paganti, account nuovi e di lunga data, team piccoli e grandi spesso mettono la stessa funzionalità in categorie diverse. Tieni separati i risultati di ogni segmento e decidi per quale segmento è la prossima release.
Usa come pubblico iniziale le persone che hanno scritto le richieste e aggiungi un campione casuale di utenti attivi, così il sondaggio non è solo la minoranza più rumorosa. Come formulare e inviare la richiesta è spiegato in come chiedere feedback ai clienti.
Come si trasformano i risultati Kano in un ordine di priorità?
Costruisci in quest’ordine: prima le lacune nelle funzionalità obbligatorie, poi le funzionalità di prestazione in cui sei indietro rispetto alle alternative con cui i clienti ti confrontano, poi una o due funzionalità attrattive per release, e per ultime o mai quelle indifferenti e inverse. L’ordine deriva da ciò che ogni categoria fa alla soddisfazione. Colmare una lacuna obbligatoria toglie un motivo per andarsene, il lavoro sulle prestazioni alza la soddisfazione in modo costante, e una funzionalità attrattiva è il punto da cui nasce la differenziazione.
Kano dice che tipo di valore porta una funzionalità, e non dice quanto costa. Abbina la categoria a una stima dello sforzo prima di metterla in un piano. Un metodo di punteggio come quello del RICE scoring gestisce il lato dei costi, e i due funzionano bene insieme: Kano sceglie la rosa e RICE la ordina. La decisione più ampia è in come dare priorità alle richieste di funzionalità.
Le funzionalità cambiano categoria nel tempo?
Sì, ed è la cosa più utile da ricordare del modello. Le funzionalità attrattive scivolano verso la prestazione e poi verso l’obbligatorietà man mano che i concorrenti le copiano e i clienti si abituano. L’autenticazione a due fattori era una sorpresa piacevole e oggi è un’aspettativa per i software aziendali. Il risultato di un sondaggio è un’istantanea, quindi ripetilo per ogni categoria su cui scommetti dopo un anno, o ogni volta che un concorrente rilascia qualcosa di simile.
Di’ ai clienti quando rilasci una funzionalità di piacere. Una funzionalità attrattiva fa piacere solo a chi la scopre, e questo rende l’annuncio parte della funzionalità. Chiudere questo ciclo è il tema di come scrivere l’annuncio di una nuova funzionalità.
Quali sono i limiti del modello Kano?
Misura sentimenti dichiarati, non comportamenti, quindi può sopravvalutare ciò che le persone dicono di volere. Servono abbastanza rispondenti per segmento per vedere uno schema, e qualche decina è spesso la soglia pratica minima. Valuta inoltre le funzionalità una per una e non dice nulla su come interagiscono. Considera il risultato una prova solida per una discussione sulla roadmap, e affiancalo ai dati d’uso e ai ricavi. Per trasformare l’elenco ordinato in un piano, vedi come costruire una roadmap di prodotto.
FAQ
Cos’è il modello Kano in parole semplici? È un metodo che ordina le funzionalità in gruppi in base a come si sentono i clienti quando la funzionalità esiste e quando manca. I gruppi sono obbligatorie, di prestazione, attrattive, indifferenti e inverse, e ognuno indica una diversa priorità di sviluppo.
Quante persone servono per un sondaggio Kano? Non c’è un numero fisso, ma ogni segmento che vuoi leggere separatamente ha bisogno di abbastanza risposte da mostrare una categoria con una maggioranza chiara. Qualche decina per segmento è un minimo pratico comune, e un risultato diviso con meno risposte va letto come irrisolto.
Il modello Kano è meglio di RICE? Rispondono a domande diverse. Kano classifica il tipo di valore che una funzionalità dà ai clienti, e RICE ordina il lavoro per reach, impact, confidence ed effort. Molti team usano Kano per costruire la rosa e un metodo di punteggio per ordinarla.
Ogni quanto va ripetuta un’analisi Kano? Ogni anno per i prodotti stabili, e prima quando un concorrente rilascia una funzionalità simile. Le funzionalità di piacere diventano aspettative col tempo, quindi un vecchio risultato può indicarti una funzionalità che non differenzia più.
Le affermazioni tecniche di questo articolo non sono state verificate in modo indipendente. Se qualcosa non è corretto, faccelo sapere e lo correggeremo.