Introduzione
In questa serie di articoli stiamo parlando di Product Ownership e della misurazione del valore di un prodotto per l’utilizzatore finale. Negli articoli precedenti (vedi box “Articoli nella stessa serie” più in basso a destra in questa pagina) abbiamo parlato di alcune modalità di misurazione e delle metriche che si possono definire per capire se il prodotto sia utile per chi lo usa.
Nella puntata precedente, abbiamo introdotto un esempio reale per provare a vedere concretamente cosa significa misurare il valore di un prodotto dal punto di vista dell’utente, utilizzando un caso vicino a uno degli autori di questa serie: Ilaria è infatti diabetica di tipo 1.
Di recente le è capitato di avere a che fare con un prodotto fisico e digitale molto particolare, al quale ha dedicato alcuni post [1], [2], [3] sul suo blog. Si tratta di un microsensore collegato via Bluetooth al suo smartphone e in grado di mostrarle “live” sull’app il dato glicemico. Lo scopo è quello di aiutarla a tenere sotto controllo in autonomia la sua glicemia e di ridurre gli eventi critici (ipo- e iper-glicemie).
Il prodotto e il suo sistema
Gli attori coinvolti in questo scenario sono
- l’azienda produttrice;
- il suo servizio clienti;
- il bioingegnere dell’azienda produttrice che, in tandem con il servizio sanitario regionale, è incaricato di consegnare i prodotti e insegnare ai pazienti a usarli;
- i medici del servizio sanitario regionale;
- i pazienti (Ilaria in questo caso).
In questo scenario, per prodotto intendiamo tutto l’“ecosistema” composto da applicativi e dispositivi hardware.
Modello di business
Dal punto di vista del modello di business, spesso si parla di Business-to-Business (B2B) o Business-to-Consumer (B2C) in cui si prevede un’interazione — e quindi misurazione del valore — limitatamente a due attori. Nel B2C, in cui C è sia l’utilizzatore finale che cliente diretto del prodotto o servizio, molti KPI ruotano intorno al C e l’esperienza è costruita su di lui/lei.
Il modello di business su cui si basa il prodotto in esame invece è un poco più complesso e può essere riassunto con uno schema Business-to-Business-to-Consumer (B2B2C): in questo caso il secondo B è il cliente diretto — lo staff di medici e, per estensione, il servizio sanitario regionale — mentre il C è il consumatore finale, che può essere cliente indiretto oppure utilizzatore finale (nel nostro caso il paziente, Ilaria). L’ecosistema di un B2B2C è più complesso di quanto possa apparire se lo si valuta dai singoli punti di contatto.
Gli ecosistemi e i loro KPI
Nel caso di studio descritto nell’articolo precedente, migliorare il prodotto sembra molto semplice se si guarda al prodotto di per sé (microsensore + app). Ma non lo è affatto se si guarda all’intero ecosistema in cui quel prodotto vive.
Il bioingegnere che ha spiegato a Ilaria come usare il sensore e l’app [2], alla domanda “Perché i pazienti dovrebbero usarlo, anche se è così costoso?” risponde “Un ricovero in ospedale per ipoglicemia costa circa 3000 €. Dal punto di vista economico, 4 mesi di sensore costano quanto un ricovero.”
La risposta del bioingegnere non descrive il beneficio che il prodotto può portare alla salute di Ilaria — cosa che peraltro il prodotto fa e che viene data per scontata — ma il risparmio che può portare al servizio regionale. È una risposta che apre una finestra sull’ecosistema in cui vivono tutti gli attori tranne Ilaria, beneficiaria finale del prodotto. Il metro viene fatto sul secondo attore B del modello B2B2C…
KPI per la Salute Pubblica
Se volete farvi un’idea di alcuni KPI usati negli ecosistemi di Salute Pubblica, eccovene qualcuno [4] di seguito. Pur tenendo presente che fanno riferimento a un sistema sanitario di stampo statunitense, molti di questi KPI si adattano comunque alla nostra realtà.
- Operazioni (6): tempi di attesa del paziente, pazienti per stanza, staff per pazienti, turnover della stanza o del letto, frequenza delle comunicazioni tra primario, dottori e infermieri e paziente.
- Finanza (3): tempi e costi per le contestazioni e le assicurazioni, tasso di rifiuto delle contestazioni, costo medio del trattamento, costo del personale.
- Comunicazione (3): numero delle menzioni sui media, soddisfazione generale del paziente, percentuale dei pazienti che hanno trovato istruzioni chiare e trasparenti.
- Interni (4): formazione per dipartimento, numero di errori, eventi di violazione della privacy del paziente, numero di partnership con gruppi di supporto.
- Salute Pubblica (3): vaccinazioni infantili, numero di programmi educativi, numero di nascite premature.
- Emergenze (3): tempo di attesa nei vari step, tempi decorsi dal sintomo al ricovero, numero di pazienti che rinunciano alla visita.
- Cura (3): errori di medicazione, staff per pazienti, assistenza del paziente.
Noi ci siamo divertiti a evidenziare in grassetto quelli in cui, secondo noi, il produttore e il decisore responsabile del sistema sanitario avrebbero potuto inserire in qualche modo il contributo del microsensore e della sua app.
Non sappiamo se i servizi sanitari regionali o nazionale usino questi o altri KPI, ma questi descrivono bene il mondo in cui vivono i medici e le aziende produttrici di materiale medico e sanitario.
Il PO e i KPI come leve
In un ecosistema fatto da questi KPI, provate a ipotizzare dove si collochino il microsensore e l’app per diabetici e a rileggere il senso dei dialoghi avvenuti tra la paziente e il dottore o il servizio clienti del produttore [2]. Dal punto di vista della paziente, alcune domande o commenti suonavano piuttosto fuori luogo, mentre per il dottore e il produttore sono la ragione per cui quel prodotto esiste nell’ecosistema.
Per esempio, “Ti ci abituerai, anche con gli occhiali è andata così all’inizio” è quello che ha risposto il servizio clienti dell’azienda produttrice a Ilaria, che era preoccupata di indossare un oggetto medico così visibile. Il servizio clienti ha dato così l’impressione di non saper comprendere il reale disagio, minimizzandolo e perdendo l’opportunità di cogliere un punto debole del prodotto.
Oppure, “Ora sei pronta per il micro-infusore.” (il micro-infusore è un oggetto paragonabile per forma e dimensioni alla “cintura di Batman”) è l’invito della dottoressa del centro antidiabete a Ilaria, che aveva a malapena iniziato ad accogliere il microsensore, dopo oltre un anno di riflessione e due mesi di faticoso periodo di prova e cambio di abitudini.
Questi commenti, anche se involontariamente, hanno il potere di creare disagio e frustrazione nei pazienti, perché più che sentirsi capiti tendono a farli sentire “usati”.
Comprendere il vero cliente finale
il Product Owner, nel suo lavoro di costruzione del backlog, si troverebbe di fronte a un conflitto di interessi, o di visione del prodotto: da un lato scrivere storie che rilascino valore all’utente finale. Dall’altro, i KPI presi in considerazione non sono strettamente legati alla soddisfazione utente, per cui il lavoro del PO verrebbe poi misurato con razionali differenti da quelli della soddisfazione utente.
La soluzione di questo conflitto si potrebbe avere ripensando il modello di business e quindi il modo di collegare il lavoro del PO alla soddisfazione del cliente: o si cambiano i KPI così da prendere in considerazione il paziente, oppure si ammette il vero cliente del prodotto (sensore e piattaforma) è lo staff medico; e il paziente, in questa seconda opzione, diventa un abilitatore o un collaudatore.
Riformulare i KPI
In questo caso di studio, alcuni KPI chiave sarebbero questi:
- numero di ricoveri per eventi critici (iper o ipoglicemie gravi) nelle aree in cui il servizio sanitario offre il microsensore ai suoi pazienti;
- numero di pazienti che rifiutano il microsensore o che lo restituiscono dopo un periodo di prova o di utilizzo;
- Numero di pazienti che utilizzano il microsensore anche durante l’estate oppure numero di sensori scaduti durante il periodo estivo;
- Recensioni sugli store.
Alcuni dati (apparentemente) irrilevanti per i decisori ma importanti per il team di design e sviluppo del prodotto, e quindi per il PO, sono per esempio questi:
- tempi di onboarding e di decisione del paziente;
- funzioni effettivamente usate nell’app;
- utilizzo della piattaforma da parte dei care-partners (cioè i familiari o altro personale che assistono la persona con la patologia);
- qualità del dialogo tra paziente e medico.
Cosa fa il Product Owner con questi KPI
Se noi fossimo i PO, useremmo il primo gruppo di KPI come leva e guida per mettere in priorità il backlog e aggiungere valore al prodotto sia per il B che per il C. E useremmo i secondi KPI come dati e informazioni per migliorare il prodotto per l’utilizzatore finale.
Per migliorare la webapp del microsensore e offrire un’esperienza migliore ai C, il PO ha più chance di ottenere il permesso di rivedere alcune feature. Può per esempio operare sulle notifiche o sulla struttura della piattaforma web che consente ai care partner di monitorare l’andamento glicemico e gli eventi critici di un diabetico — per esempio un figlio piccolo o un genitore anziano — abbinandole ai KPI Recensioni sullo store, Utilizzo durante il periodo estivo o Numero di sensori scaduti.
Il PO, i journey e le stime
Tra i vari insights emergenti dal racconto di Ilaria alle prese con il microsensore e l’app, se ne evidenzia uno molto importante per chi deve progettare e sviluppare il prodotto e fare stime sui tempi di rilascio. L’insight riguarda la supposizione sui tempi di onboarding: 2 ore erano quelli attesi, 2 mesi sono stati quelli percepiti ed effettivi.
Non è nostra intenzione suggerire qui i tanti modi in cui in fase di onboarding un paziente può essere supportato nel cambiare le sue abitudini e decidere di tenere il microsensore. Ci teniamo però a evidenziare che non conoscere gli eventi che accadono durante una fase di utilizzo di un prodotto porta a una progettazione e a uno sviluppo miopi, che potrebbero rendere molto costose eventuali evoluzioni.
I “percorsi” nell’utilizzo del prodotto
Che cosa succede nel periodo di onboarding del microsensore? Che cosa sta valutando il paziente? Con chi? Quanto più il PO ha visione su questo tipo di scenari, tanto maggiore sarà la sua capacità di definire e prioritizzare il backlog, facendo le giuste stime sui tempi di progettazione e sviluppo.
Il modo più efficace di ottenere una visione consapevole e neutrale su questo tipo di scenari è osservando un campione di pazienti con metodi e tecniche propri della ricerca qualitativa: interviste moderate, service safari, diary studies etc. È da questo tipo di indagini che il PO capisce perché i pazienti si comportano in un certo modo e prendono le loro decisioni.
Un paziente che restituisce il microsensore durante il periodo di prova può aver riscontrato problemi a inserire il sensore in modo autonomo, può aver avuto problemi a configurare le impostazioni dell’app in modo adatto alle sue abitudini, o può averlo giudicato troppo antiestetico. Oppure può semplicemente aver trovato fastidiose e imbarazzanti le notifiche in caso di eventi critici.
Questo tipo di informazioni sono anch’esse dati che abilitano il team di prodotto a lavorare più consapevolmente sulle sue funzionalità. Unendo questo tipo di informazioni a un’analisi dei dati statistici, si otterrebbe un framework di lavoro molto chiaro.
Conclusioni
In questi ultimi due articoli abbiamo raccontato un caso di esempio che può insegnarci molte cose. Probabilmente la più importante è che il tipo di metrica deve essere scelta in base al modello di business applicato, e viceversa: un KPI, o più genericamente una metrica, infatti, rappresenta l’indicatore di una performance che può essere influenzata solo dalle azioni — relative al prodotto e al suo miglioramento — che possono impattare su quel dato modello di business.
In questo caso basato sul modello B2B2C, le metriche sono “sbilanciate”. Dalle discussioni intercorse fra il paziente e lo staff medico si può infatti ipotizzare che le metriche sul piatto siano state scelte come misuratori delle performance di B — lo staff medico o più genericamente il processo di ricerca scientifica — mentre non pare tengano in debita considerazione la soddisfazione di C, vale a dire il paziente.
Ne consegue che, in uno scenario come quello raccontato, le decisioni del PO, per quanto possa essere animato da una genuina volontà di creare un prodotto che porti beneficio al paziente, saranno fortemente condizionate dalle metriche che invece sono orientate a misurare il valore rilasciato per lo staff medico.
Non vogliamo qui esprimere un giudizio “morale” su questa scelta. La nostra posizione è di valutazione del lavoro svolto dallo staff nel suo complesso, e per questo vogliamo sempre ritornare ai valori e ai principi dell’Agile Manifesto: principi [5] che ricordano che
Committenti e sviluppatori devono lavorare insieme quotidianamente per tutta la durata del progetto
e quanto sia importante co-creare il prodotto con l’utente finale — correttamente individuato! — raccogliendo il feedback durante un processo di rilascio iterativo e incrementale.
È importante quindi non dimenticare che, anche in un prodotto B2B2C come quello visto in questo esempio, le decisioni del PO dovranno portare un reale beneficio anche per il C (paziente), anche se il cliente finale è B (lo staff dei medici). Se non si fa così, in questo tipo di modello di business, il prodotto sarà sempre subottimo e poco innovativo.
Ilaria Mauric è socia e Head of Design di Tangible, un’azienda specializzata in experience design.
Come Head of Design, si occupa di progettazione di prodotti e servizi digitali. Supporta i team interni e quelli esterni dei clienti nella creazione collaborativa di prodotti e servizi in modo sostenibile e misurabile, individuando le aspettative, verificando i risultati e facendo emergere le opportunità che si presentano lungo il processo.
Giovanni Puliti ha lavorato per oltre 20 anni come consulente nel settore dell’IT e attualmente svolge la professione di Agile Coach. Nel 1996, insieme ad altri collaboratori, crea MokaByte, la prima rivista italiana web dedicata a Java. Autore di numerosi articoli pubblicate sia su MokaByte.it che su riviste del settore, ha partecipato a diversi progetti editoriali e prende parte regolarmente a conference in qualità di speaker. Dopo aver a lungo lavorato all’interno di progetti di web enterprise, come esperto di tecnologie e architetture, è passato a erogare consulenze in ambito di project management. Da diversi anni ha abbracciato le metodologie agili offrendo ad aziende e organizzazioni il suo supporto sia come coach agile che come business coach. È cofondatore di AgileReloaded, l’azienda italiana per il coaching agile.