Gestire le priorità nel backlog di prodotto col modello di Kano

I backlog di prodotto vengono continuamente affinati, corretti, incrementati. Ogni Product Manager ne massimizza il valore con la propria visione , ma il modello Kano può supportare la valutazione  delle funzionalità e le relative priorità.  Vediamo in seguito come utilizzare il modello e come scrivere uno script R per implementarlo in concreto

Il Modello di Kano

Le caratteristiche del prodotto sono classificate in cinque categorie:

  1. 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.
  2. Required. Queste sono caratteristiche date per scontate, non generano soddisfazione se presenti ma  generano  scontento se mancano. Es. l’ABS nelle automobili.
  3. 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.
  4. 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)
  5. 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:

  1. Caratteristica;Punti Funzionale; Punteggio Disfunzionale
  2. 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.