Modello Kano: quando e come utilizzarlo (guida)

Sviluppato negli anni ’80 da Noriaki Kano, il modello Kano è una delle metodologie più note in product management, anche se non necessariamente tra le più utilizzate. È utile per determinare l’ordine e la priorità da attribuire alle nuove funzionalità di un prodotto: permette di compiere scelte basate su dati ed è focalizzato sui bisogni e desideri dei clienti.

In questa guida partiremo dalla spiegazione della teoria alla base del modello, per poi scendere nei dettagli dell’implementazione.

Introduzione e teoria
Creazione del questionario
Analizzare i risultati
Conclusioni

Quando utilizzarlo e quali sono i prerequisiti

Come altri metodi di prioritizzazione, il metodo Kano non è una soluzione universale a tutti i problemi bensì un supporto utile per un problema complesso. Essendovi altri framework pensati per lo stesso scopo, occorre riflettere su quale sia il migliore per il contesto in cui ci troviamo.

Innanzitutto, il modello Kano ha senso se applicato a funzionalità facenti parte di un solo prodotto. Se il vostro team lavora su un portfolio e dovete stabilire la priorità tra funzionalità disomogenee e appartenenti a prodotti diversi, allora vorrete affidarvi ad altri metodi. Similmente, non è il modello giusto se state comparando iniziative di ampio respiro che non sono traducibili in funzionalità ben definite. Altrettanto vale se lo stadio a cui vi trovate è la valutazione di opportunità.

Se avete deciso che l’ambito di applicazione è rilevante, nel confrontare il modello con altri metodi tenetene presente le specificità. Oltre a supportarci nel stabilire le priorità, è infatti particolarmente utile per rispondere a due domande:

Come collegare le funzionalità che vogliamo costruire alla soddisfazione del cliente?
Come andare oltre alla soddisfazione? Quali sono le funzionalità che eccedono le aspettative dei clienti?

Vi sono poi due ultimi prerequisiti da considerare prima di buttarsi nell’applicazione del modello:

La preparazione ed esecuzione del modello Kano sono dispendiose: mediamente, richiedono più tempo rispetto ad altri metodi di prioritizzazione. Sicuramente è utile e può fornire insight di alta qualità, ma dovrete decidere se l’investimento è giustificato.
È necessario avere la disponibilità di un buon numero di clienti disposti a rispondere a un questionario relativamente lungo. Tenete in considerazione l’impatto sulla fattibilità (GDPR, mailing list, reattività dei clienti, disponibilità di incentivi, …).

Cos’è il modello Kano

Il modello Kano è pensato per creare un’associazione tra le funzionalità del nostro prodotto e la soddisfazione dei clienti (attuali o potenziali). Lo fa combinando due idee.

La prima idea alla base del modello è che la soddisfazione generata da una funzionalità sia legata a quanto quest’ultima adempie al proprio scopo. Occorre dunque disambiguare due concetti: quello di soddisfazione e quello che abbiamo deciso di tradurre come implementazione (in inglese solitamente si usano satisfaction e functionality).

La soddisfazione del cliente è l’obiettivo ultimo e in questo modello può venire misurata su una scala che va da frustrazione – là dove manchiamo completamente la soddisfazione dei bisogni del cliente – ad adorazione – là dove invece eccediamo in maniera inaspettata le aspettative.

La seconda dimensione è l’implementazione e, in parole povere, è una misura di quanto bene (o male) una funzionalità “faccia quel che deve fare”. Anche l’implementazione viene misurata su una scala che va da assente – là dove la funzionalità manchi del tutto nel nostro prodotto – a eccellente – là dove il livello di implementazione sia ragionevolmente massimizzato. Naturalmente, migliorare l’implementazione di una funzionalità ha un costo.

La seconda idea è che le funzionalità possano essere suddivise in quattro categorie: queste categorie dipendono da come la soddisfazione cambia in funzione dell’implementazione. Tendenzialmente (ma non sempre!), la soddisfazione tenderà a migliorare con il migliorare dell’implementazione: tuttavia la velocità di tale cambiamento è variabile. Vediamo dunque quali sono queste categorie.

Le categorie del modello Kano

La visualizzazione della funzione implementazione / soddisfazione è nota:

Modello Kano: le quattro categorie di funzionalità

Consideriamo ciascuna categoria con l’aiuto di qualche esempio:

Funzionalità di prestazione: sono funzionalità la cui implementazione ha un rapporto (tendenzialmente) lineare con la soddisfazione del cliente. Se mancano, l’esperienza è frustrante. Più le miglioriamo, più la soddisfazione cresce. Alcuni esempi sono la velocità di un processore, o la banda offerta da un provider, o lo spazio di archiviazione in un servizio di cloud storage.
Funzionalità necessarie: sono quelle che i clienti si aspettano. La loro assenza è garanzia di insoddisfazione o frustrazione; la loro presenza, tuttavia, non implica soddisfazione. Al massimo, significa che i clienti non saranno insoddisfatti. Alcuni esempi sono l’opzione di pagamento con carta di credito su un sito e-commerce, o la possibilità di rispondere a un’email su un email client, o la possibilità di collegarsi con altri utenti su un social network.
Funzionalità attraenti: sono funzionalità inaspettate e che, se presenti, hanno un effetto positivo sulla soddisfazione. La loro assenza, tuttavia, non implica insoddisfazione (in quanto sono inaspettate). Ciascuno ne ha avuto esperienza nella propria vita. Alcuni esempi dalla mia esperienza personale sono la prima volta che ho usato un gestore di password, o i primi utilizzii di Google Doc, o le prime volte che ho cercato vini su Vivino scansionandone l’etichetta.
Funzionalità indifferenti: sono quelle il cui livello di implementazione non ha effetti sulla nostra soddisfazione. Quelle, dunque, su cui non ha nessun senso investire tempo e risorse.

Il ciclo di vita delle funzionalità

Le funzionalità che abbiamo definito attraenti sono naturalmente il Sacro Graal di ogni prodotto, ma occorre precisare un paio di cose.

Innanzitutto, non appartengono a questa categoria solo quelle feature che generano stupore e ci fanno innamorare istantaneamente del prodotto: si può trattare di qualsiasi funzionalità inaspettata e che generi un effetto positivo, per quanto minore.

In secondo luogo, è importante sottolineare che le funzionalità attraenti col tempo perdono il loro status e diventano funzionalità di prestazione, per poi – probabilmente – diventare funzionalità necessarie. Per questa ragione, nel cercare degli esempi ho dovuto ricorrere ai ricordi. Pensate alla sensazione provata la prima volta che avete usato un telefono con touch-screen: quella che è stata, presumibilmente, un’esperienza inusuale e positiva è oggi niente più che un aspettativa di base.

Ogni volta che eseguiamo un’analisi con il modello Kano non facciamo altro che immortalare le funzionalità del prodotto al loro stato attuale, sapendo che il loro status è destinato a cambiare con l’evolvere del prodotto, del mercato, dei clienti e del contesto.

Come associare soddisfazione e implementazione

Il primo passo per analizzare il nostro prodotto è realizzare, per ciascuna funzionalità (esistente o potenziale), un’associazione tra soddisfazione e implementazione. Lo strumento che utilizzeremo è un questionario consistente di due domande per ciascuna funzionalità – una domanda positiva e una negativa:

La domanda positiva chiede al cliente come si sentirebbe se avesse a disposizione la funzionalità in questione.
La domanda negativa chiede al cliente come si sentirebbe in assenza della funzionalità.

La risposta è da selezionarsi tra alcune opzioni predeterminate: (1) Mi piacerebbe; (2) Me lo aspetto; (3) Indifferente; (4) Lo potrei tollerare; (5) Non mi piacerebbe.

Più avanti discuteremo come scrivere adeguatamente le domande e le possibili risposte.

Ottenute le risposte, possiamo categorizzare ciascuna funzione utilizzando una tabella di valutazione:

La combinazione della risposta alla domanda positiva e alla domanda negativa corrisponde a una cella nella tabella, dunque a una categoria del modello.

Come avrete visto dalla tabella, abbiamo introdotto due categorie extra:

(D) sta per discutibile: corrisponde a risposte in conflitto (ad esempio, il cliente dice che gli piacerebbe la presenza della funzionalità ma anche l’assenza della medesima). Se riceviamo un alto numero di risposte discutibili, possiamo presupporre che vi sia qualcosa di confuso nel modo in cui abbiamo espresso le relative domande.
(C) sta per contraria: sono le funzionalità per cui la domanda positiva viene accolta con una risposta negativa, e la domanda negativa viene accolta con una risposta positiva.

Se la maggior parte delle risposte per una funzionalità rientrano nella categoria contraria, possiamo invertire le domande per categorizzare la funzionalità correttamente.

Veniamo alla preparazione pratica del questionario.

Selezionare le funzionalità

Come anticipato, il modello è utile per comparare funzionalità di uno stesso prodotto. Alcuni accorgimenti:

Non includete troppe funzionalità o sarà difficile ottenere un’alta partecipazione. La compilazione del questionario può richiedere tempo.
Focalizzatevi su quelle funzionalità che producono un beneficio diretto per il cliente. La risoluzione di debito tecnico o il miglioramento di API interne sono esempi di iniziative che non si prestano a essere valutate tramite il modello Kano.
Selezionate funzionalità tangibili. Più alto è il livello di astrazione, più difficile sarà ottenere risposte valide.

Selezionare i clienti

Un tipico prodotto ha una base clienti eterogenea. Se non volete trovarvi davanti a risultati altrettanto eterogenei, decidete in anticipo chi è il target su cui volete focalizzarvi.

Naturalmente potete includere più di un segmento, ma siate sicuri di aver modo di riprodurre la segmentazione in fase di analisi.

Un buon modo per valutare il target è analizzare i tipi di persona che compongono la vostra base clienti.

Scrivere le domande e le risposte in modo chiaro

Tenete presente i seguenti accorgimenti nello scrivere le domande:

Ciascuna coppia di domande deve riferirsi a una sola funzionalità.
Focalizzate le domande sui benefici per il cliente. Invece di “Che effetto ti farebbe l’aggiunta di una lista dei desideri?” chiedete “Che effetto ti farebbe poter salvare i prodotti a cui sei interessato per poterli riconsiderare in futuro?”.
Se possibile, corredate la domanda con prototipi, mock-up o altri supporti visivi.

Siate inoltre attenti al senso della domanda negativa: non deve necessariamente essere l’opposto della domanda positiva. La domanda negativa rappresenta semplicemente l’assenza della funzionalità. Supponete avere un sito di e-commerce dove volete estendere il reso gratuito su tutti i prodotti (supponiamo dunque che al momento il reso gratuito si applichi ma solo su alcuni articoli). La domanda positiva potrebbe essere:

Che effetto ti farebbe avere l'opzione di reso gratuito su tutti i prodotti?

La domanda negativa non è “Che effetto ti farebbe non avere l’opzione di reso gratuito su alcun prodotto”. Non siamo interessati a capire la reazione all’opposto della funzionalità, quanto la reazione all’assenza. In questo caso la domanda negativa corretta sarebbe:

Che effetto ti farebbe avere l'opzione di reso gratuito su un numero limitato di prodotti?

Anche le risposte vanno preparate con alcuni accorgimenti. Prima ci siamo limitati a dire che le cinque possibilità possono essere (1) Mi piacerebbe; (2) Me lo aspetto; (3) Indifferente; (4) Lo potrei tollerare; (5) Non mi piacerebbe. Se pensate che queste risposte siano troppo ambigue, potete rivederle e adattarle alle vostre necessità. Questo che segue è un esempio di come si possano rendere più esplicite le cinque opzioni:

1. Mi sarebbe particolarmente d'aiuto
2. Per me si tratta di un requisito di base.
3. Non avrebbe nessun impatto su di me.
4. Sarebbe un lieve disturbo, potrei conviverci.
5. Costituirebbe un problema e non lo potrei accettare.

Chiedere riscontro sull’importanza di una funzionalità

Oltre alla coppia di domande positiva / negativa, è possibile chiedere ai clienti quanto importante la funzionalità sia dal loro punto di vista. In questo modo è possibile distinguere le funzioni che potrebbero avere un impatto maggiore da quelle con minore incidenza (a prescindere dal possibile effetto positivo sulla soddisfazione).

La risposta può essere semplicemente un numero da 1 a 10, in una scala dove 1 corrisponde a “non importante” e 10 a “estremamente importante”.

Per riassumere quanto detto fin’ora sul questionario vediamo un esempio di domande associabili a una funzionalità. Questa volta immaginiamo di gestire un sito che vende e-book: una delle funzionalità che stiamo considerando è la possibilità di scaricare le anteprime degli e-book prima di acquistarli (le anteprime sono già disponibili sul sito). La relativa sezione del questionario potrebbe essere la seguente:

Che effetto ti farebbe se fosse possibile scaricare le anteprime dei libri sul tuo e-reader prima dell'acquisto?

1. Mi sarebbe particolarmente d'aiuto
2. Per me si tratta di un requisito di base.
3. Non avrebbe nessun impatto su di me.
4. Sarebbe un lieve disturbo, potrei conviverci.
5. Costituirebbe un problema e non lo potrei accettare.

Che effetto ti farebbe se le anteprime dei libri fossero disponibili sul sito ma non scaricabili?

1. Mi sarebbe particolarmente d'aiuto
2. Per me si tratta di un requisito di base.
3. Non avrebbe nessun impatto su di me.
4. Sarebbe un lieve disturbo, potrei conviverci.
5. Costituirebbe un problema e non lo potrei accettare.

Quanto è importante (o sarebbe importante) avere la possibilità di scaricare le anteprime dei libri sul tuo e-reader? (1: non importante; 6: importante; 10: estremamente importante)

1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10

Testare il questionario

Un ultimo consiglio pragmatico è di sottoporre il questionario ad alcuni colleghi prima di distribuirlo ai clienti.

L’obiettivo principale è verificare che non vi siano ambiguità. Per questa ragione sarebbe ideale avvalersi del supporto di colleghi che non hanno troppa familiarità con il vostro prodotto o con i piani delineati nel questionario.

Modalità di analisi del modello Kano

Il questionario è pronto, è stato spedito, e le risposte sono finalmente disponibili. Siamo dunque pronti per passare all’analisi. L’obiettivo – ricordiamolo – è arrivare a degli insight utili per decidere quali funzionalità devono avere la priorità all’interno della nostra roadmap.

Nel proporre i metodi per l’analisi dei risultati mi sono rifatto alla fantastica guida di Daniel Zacarias (link in inglese), da cui ho preso spunto anche per le altre sezioni. Zacarias suggerisce di distinguere tra due principali modalità – l’analisi discreta e l’analisi continua. Come spiega, entrambe sono utili e la scelta di una o dell’altra dipende dal tipo di insight che vi occorrono.

Analisi discreta

Come abbiamo visto precedentemente, è fondamentale decidere a quali segmenti di clientela ci vogliamo rivolgere. Supponendo che abbiate incluso più di un gruppo, dovrete in seguito assegnare ogni rispondente a uno di questi in modo da poter segmentare i risultati dell’analisi.

Per semplicità, a seguire supporremo che il questionario è stato inviato a un solo gruppo o demografica, e dunque non richieda ulteriori segmentazioni. In un primo passo vogliamo categorizzare le risposte ottenute in una tabella riassuntiva:

Ciascuna risposta di ciascun rispondente viene valutata tramite la tabella di valutazione.
Per ciascuna funzionalità, sommiamo le risposte associate a ciascuna categoria.

Dovreste avere una tabella simile a questa:

Modello Kano: esempio di tabella riassuntiva

Ora vogliamo aggiungere la categorizzazione di ciascuna funzionalità e l’importanza:

La categoria corrisponde a quella con la maggiore frequenza di risposte.
In caso di due categorie con risultati identici o vicini (come per la funzionalità 1 nell’esempio), assegnate la categoria più a sinistra: N (necessarie) prevale su P (di prestazione), che prevale su A (attraenti), che prevale su I (indifferenti).
Quanto all’importanza, è la semplice media aritmetica delle risposte ottenute per la relativa domanda.

La tabella finale sarà simile a questa:

A questo punto avete le informazioni che vi occorrono per passare alla prioritizzazione.

Come per qualsiasi altro metodo quantitativo, non affidatevi ciecamente ai numeri per avere delle risposte. I risultati devono informare le vostre decisioni, non dettarle. In generale, queste sono i fattori da tenere in considerazione quando discuterete le priorità:

Le funzionalità con un punteggio più alto in quanto a importanza sono buone candidate per andare in cima alla lista delle priorità.
Le funzionalità necessarie (N) dovrebbero precedere quelle di prestazione (P). A seguire vengono le funzionalità attraenti (A). Le funzionalità indifferenti (I) dovrebbero essere escluse.

Se avete incluso delle funzionalità che sono già parzialmente implementate nel prodotto, considerate lo stadio di implementazione e la categoria a cui appartengono. Ad esempio, investire ulteriormente in una funzionalità con un buono stato di implementazione potrebbe non avere un buon ritorno se si tratta di una funzionalità necessaria, ma potrebbe rivelarsi vincente se si tratta di una funzionalità attraente.

Analisi continua

L’analisi continua consiste permette di preservare molta più informazione rispetto all’analisi discreta. Invece di ridurre ciascuna risposta a una singola categoria, vengono assegnati dei punteggi che utilizzeremo per una categorizzazione più sfumata.

Innanzitutto, a ogni risposta viene attribuito un punteggio utilizzando le seguenti scale:

Positiva: -2 (non mi piacerebbe), -1 (lo potrei tollerare), 0 (indifferente), 2 (me lo aspetto), 4 (mi piacerebbe)

Negativa: -2 (mi piacerebbe), -1 (me lo aspetto), 0 (indifferente), 2 (lo potrei tollerare), 4 (non mi piacerebbe)

Importanza: da 1 (non importante) a 10 (estremamente importante)

Come potete vedere, i punteggi attribuiti alle domande positive e negative sono invertiti. Inoltre la scala non è perfettamente lineare.

Il prossimo passo consiste nel calcolare un totale di 6 punteggi per ciascuna funzionalità:

La media delle risposte alla domanda positiva, alla domanda negativa e alla domanda sull’importanza.
La deviazione standard dei tre punteggi così ottenuti.

A questo punto considereremo solo le funzionalità aventi un punteggio positivo sia per la domanda positiva sia per la domanda negativa. La categorizzazione dipende dai punteggi ed è visualizzabile in un plot simile a questo:

La posizione sull’asse orizzontale corrisponde al punteggio ottenuto per le domande negative, mentre la posizione sull’asse verticale corrisponde al punteggio ottenuto per le domande positive. La categorizzazione delle funzionalità corrisponde al quadrante in cui si trovano. Tuttavia, è immediatamente possibile osservare i casi ambigui (ad esempio la funzionalità 3, in giallo) e trattarli di conseguenza.

La dimensione delle bolle può essere utilizzata per rappresentare l’importanza della funzionalità. Volendo è possibile rappresentare la deviazione standard per i punteggi relativi alle domande positive e negative, così da visualizzare la variabilità nelle risposte: potete semplicemente aggiungere delle barre di errore alle rispettive bolle.

Naturalmente è possibile anche rappresentare i risultati con una tabella di questo tipo:

Ancora una volta valgono i principi generali descritti sopra (considerare l’importanza e prioritizzare in ordine N > P > A). Tuttavia, ora possiamo guardare ai dati con maggiore attenzione per le funzionalità che sfuggono una categorizzazione definita (di nuovo, l’esempio della funzionalità 3) e possiamo utilizzare la deviazione standard per valutare se un’alta variabilità nelle risposte richieda un’analisi più approfondita (ad esempio: un’ulteriore segmentazione dei rispondenti).

Conclusioni

Come premesso, il metodo Kano richiede una discreta quantità di tempo per la preparazione e per l’analisi. E come tutti i metodi quantitativi, potrebbe dare un falso senso di sicurezza (“lo dicono i numeri!”): occorre dunque utilizzare extra cautela nel valutare e presentare gli insight che se ne derivano.

In certe situazioni potreste trovarvi a corto di strade praticabili per validare certe ipotesi (ad esempio, non vi sono le condizioni per organizzare dei concept test). Oppure potreste avere un opportunity backlog molto affollato, che richiede una sfoltita prima di poter essere ulteriormente analizzato. In questi casi, il metodo Kano può essere il primo passo di un processo iterativo.

Non abbiate paura di adattarlo alle vostre esigenze e, soprattutto, ricordatevi quel che può e non può fare. Sicuramente può aiutarvi a raccogliere in maniera sensata e metodica il feedback dei vostri clienti. Può indiscutibilmente fornire ottimi insight intorno ai quali intavolare discussioni sulle priorità future. Ma non potrà mai prendere decisioni al vostro posto. Prioritizzare è difficile, ma l’uso di un buon framework può semplificarvi la vita e rendere il processo più solido.