I backlog di prodotto vengono continuamente affinati, corretti, incrementati. Il modello di Kano può dare concretezza alla visione del Product owner, con una valutazione quantitativa della desiderabilità delle singole funzionalità del prodotto. Di seguito una overview del modello e in un post a parte i dettagli per creare uno script per la sua implementazione concreta.
Il Modello di Kano
Le caratteristiche del prodotto sono classificate in cinque categorie:
- Performance. E’ la caratteristica fondamentale, la prima nella valutazione del cliente. Queste caratteristiche generano un incremento di soddisfazione in maniera lineare: più ce n’è, meglio è, e migliore la qualità dell’implementazione, maggiore la soddisfazione del cliente. Es. la velocità del processore in un PC.
- Required. Queste sono caratteristiche date per scontate, non generano soddisfazione se presenti ma generano scontento se mancano. Es. l’ABS nelle automobili.
- Delighters. Sono caratteristiche innovative e inaspettate, che aumentano la soddisfazione, ma che, proprio perchè inaspettate, non creano scontento se mancanti. Ad es. la coppa di champagne offerta all’arrivo in albergo.
- Indifferent. Sono caratteristiche che non interessano ai clienti, e quindi non dovrebbero interessare neanche a noi, salvo requisiti legali, obbligatori o per qualche ragione strategici. Ad es. tutte le caratteristiche software inutilizzate come ad esempio la visualizzazione dell’editing time in Microsoft Word (probabilmente non sapevi nemmeno che esistesse)
- Reverse. Sono caratteristiche che infastidiscono, e vanno quindi eliminate. Ad es. il vecchio Clippit di Microsoft Office
C’è una ulteriore categoria, non inclusa nell’articolo originale: le caratteristiche “questionabili” . In questa categoria rientrano tutte le feature che ricevono feedback contradditori, probabilmente a causa di una presentazione poco chiara o comprensibile nelle domande fatte ai clienti.
Bisogna infine notare che i Delighters tendono, con il tempo, a scivolare nella categoria Required. Es. l’ABS era un tempo montato solo sulle automobili di lusso, oggi è diventato una caratteristica scontata e indispensabile.
Infine, segnalo che la categorizzazione, che come vedremo origina da un sondaggio, non va vista come “assoluta” ma come una indicazione di tendenza, legata alle preferenza espresse dai clienti/consumatori.
Kano Analysis – il sondaggio
Nel modello di Kano la categorizzazione dei prodotti e delle loro caratteristiche non è fatta a sensazione dal product manager ma viene generata da un sondaggio strutturato con una coppia di domande per ogni caratteritica da valutare. La coppia di domande è nella forma Funzionale/Disfunzionale.
Immaginiamo ad esempio di voler valutare tre diverse caratteristiche per il lancio di un servizio di car sharing:
A) Navigatore GPS sul veicolo
B) Corse gratuite offerte al cliente nel giorno del suo compleanno
C) Quiz a premi (opzionale) all’avvio della corsa e corsa gratuita per i vincitori
Le tre caratteristiche vengono proposte ai clienti attuali e potenziali con un due domande per ogni feature:
A) Funzionale
Come valuti la presenza di un navigatore GPS nel tuo veicolo car sharing?
[ ] Ne sono felice
[x] Mi aspetto che ci sia
[ ] Non mi interessa
[ ] Accettabile
[ ] Inaccettabile
B) Disfunzionale
Come valuti l’assenza di un navigatore GPS nel tuo veicolo car sharing??
[ ] Ne sono felice
[ ] Mi aspetto che ci sia
[ ] Non mi interessa
[ ] Accettabile
[x] Inaccettabile
e così via per ogni prodotto/caratteristica. Le risposte sono poi valutate come: Felice=1; Me l’aspetto=2; Indifferente=3; Accettabile=4; Inaccettabile=5
Al termine del sondaggio avremo un file con la seguente struttura:
- Caratteristica;Punti Funzionale; Punteggio Disfunzionale
- A;1;5
- …
- …
E’ ora possibile costruire la matrice delle categorie, con i punteggi aggregati per ogni risultato Funzionale/Disfunzionale e la conoseguente matrice che correla le coppie funzionale/disfunzionale a una specifica categoria:
Dal punteggio alla categoria di Kano
Ci sono diversi modi per valutare i punteggio così ottenuti.
Possiamo ad esempio prendere la combinazione funzionale/disfunzionale con il punteggio più alto ed utilizzarla per classificare la caratteristica nella categoria corrispondente. Nell’esempio si vede che la feature in corrispondenza del punteggio più alto (Functional 5/Dysfunctional 5) pari a 45 è classificata come Performance.
Un altro approccio possibile conisiste nell’aggregare ulteriormente i conteggi ( intersezioni riga/colonna) per categoria, sommando quindi insieme tutte le intersezioni “Delighters”, tutt le intersezioni “Indifferent”, etc.
Nell’esempio sopra riportato:
- Delighter= 23+32+15=70
- Must Have = 15+18+23 = 56
- Reverse = 2+5+5+2+3+1+0=18
- Indifferent = 9+4+2+7+11+7+4+5+13=62
- Performance = 45
- Questionable = 1
Adottando quest’approccio la feature è classificata come Delighter.
Come già accennato non è tutto bianco/nero. E’ importante concentrarsi sulle tendenze di fondo e sul fatto che il successo del prodotto dipende dalla giusta implementazione delle caratteristiche più vicine alle categorie delighter, must have, performance.