Rifare da 0 una piattaforma legacy

Un’esperienza sul campo

Eccolo qui, l’ultima “creazione” del mese di Novembre.
E’ stato un periodo intensissimo sul fronte professionale e familiare ma nonostante questo sono stata particolarmente contenta di aver preso parte come speaker al Product Management Day.
Si tratta della prima conferenza italiana dedicata al Product Management organizzata da 20tab e che si è tenuta online venerdì 26 Novembre.

E’ stata una giornata intera di talk partita la mattina con l’intervento di Kate Leto su quali aspetti valutare quando si assume un Product Manager e conclusasi alle 18:30 dopo un panel dedicato al Product Growth e alla validazione.

In questa occasione ho parlato di un’esperienza sul campo di product management: rifare da 0 una piattaforma legacy. Qui sotto trovate le mie slide e una sintesi dei punti salienti del talk.

“Rifare da 0 una piattaforma legacy” – Le slide del mio intervento al Product Management Day

Quando parlo di design di prodotto io distinguo sempre due situazioni differenti:

  • quando si lavora su un prodotto completamente nuovo che non esiste sul mercato
  • quando si mette mano a un prodotto esistente che deve essere rifatto. 

Faccio questa distinzione perché nel primo caso il punto centrale è validare innanzitutto l’idea di business mentre nel secondo il prodotto o servizio esiste già ma deve essere ottimizzato. Qui solitamente non c’è un’idea di business da validare perché abbiamo già dei ricavi; il focus non è capire se il prodotto è realmente appetibile quanto valutare se la soluzione di prodotto che è stata scelta è ancora valida.

Le sfide del Legacy

Proviamo a guardare più da vicino quali sono i problemi che pone una piattaforma Legacy.
Ci troviamo spesso di fronte a prodotti o piattaforme che si basano su una tecnologia datata, che non è più stata manutenuta o aggiornata, per cui magari è sempre più difficile trovare persone che siano in grado di metterci mano.
Un altro tema ricorrente in queste situazioni è che il know-how tecnico di questi prodotti non è documentato, è una conoscenza che risiede nella testa di alcuni sviluppatori, non strutturata, non replicabile e non scalabile

Il problema non è solo tecnologico o “dietro le quinte”, tipicamente diventa un problema nel momento in cui ha una ricaduta visibile sul business: non si è più in grado di cogliere alcune opportunità di mercato.
Inoltre si vedono gli effetti nell’adozione di vecchi pattern UX o nell’approccio “feature factory” che ha reso nel tempo il prodotto non più fruibile.
Nonostante tutti questi problemi la piattaforma produce ricavi (a volte tanti!) e il business non è disposto a mettere a rischio queste revenue.
E’ la tipica situazione in cui si vuole la botte piena e la moglie ubriaca…

Il progetto di cui ho parlato è il rifacimento di una piattaforma di servizio B2B attraverso la quale si fanno assessment di tipo clinico, di tipo organizzativo o educativo.
E’ utilizzata prevalentemente da psicologi e non è accessibile a tutti perché l’utilizzo dei prodotti è consentito a persone con determinate qualifiche professionali.
La piattaforma è multilingue, presente in 16 paesi di cui il principale è l’Italia e vengono somministrati poco meno di 200.000 test l’anno attraverso di essa.

Gli obiettivi dell’azienda erano – in ordine di priorità – abbattere il rischio di business, passare a tecnologie più moderne, flessibili e scalabili e migliorare l’esperienza utente rendendo il prodotto più fruibile.

I principi del redesign

Quali sono i principi che abbiamo seguito in questo rifacimento?
Ci siamo ispirati al framework del design thinking.
Alla base di questa metodologia c’è l’idea che un prodotto o un servizio per essere innovativo ha sempre tre caratteristiche che convivono: è appetibile per l’utente finale (produce un vero valore), è tecnicamente fattibile ed è “viable” da un punto di vista business, ovvero scalabile.

Sempre in riferimento al design thinking esistono 5 fasi principali nella parte di progettazione del prodotto di cui la prima è l’empatia seguita dalla definizione, la progettazione, la creazione di prototipi e alla fine la validazione tramite test.

Nel corso del mio intervento ho mostrato cosa è stato fatto nelle prime quattro fasi poi quando è partito lo sviluppo vero e proprio è stato adottato l’approccio Lean Start-Up con un ciclo iterativo di sviluppo, raccolta dati, misurazione, acquisizione degli insight e ulteriore ottimizzazione.

Gli strumenti del redesign

Partiamo dallo strumento per eccellenza del Product Management e non solo: le domande.
Sono le domande che vi potete e dovete porre rispetto al prodotto o al servizio: chi è l’utilizzatore della piattaforma? E’ chiaro e definito? Qual è il valore che la piattaforma produce per questi attori? È davvero un prodotto appetibile?
E’ sempre bene ricordarsi che non creiamo prodotti in astratto; ciò che facciamo entra in un sistema, deve fare scopa con la più ampia strategia di business.
Nella mia esperienza le risposte a queste domande non sono così scontate come appaiono… 

In questa iniziativa siamo partiti da un assessment del prodotto.
Abbiamo preso in mano la piattaforma esistente e analizzato lo stato dell’arte. L’abbiamo indagata utilizzando vari tipi di strumenti, come ad esempio gli analytics, le interviste, il product canvas poi abbiamo spostato il focus sulle personas per meglio comprendere la voce del cliente.

Abbiamo fatto un gran lavoro sugli utilizzatori principali: gli psicologi. Siamo andati a esplorare in dettaglio la main persona; sapevamo qual era l’ambito di lavoro ma volevamo indagare meglio bisogni, convinzioni, valori, comportamenti e attività da compiere

In questa fase si esercita l’empatia ovvero stiamo cercando di metterci dal punto di vista degli utilizzatori e guardare il mondo con i loro occhi per capire quali sono gli aspetti a cui sono più attenti e i principali problemi da risolvere.

Il lavoro su chi è l’attore principale è alla base di qualsiasi attività di Product Management, richiede tempo e anche un discreto livello di approfondimento ma questa comprensione fa la differenza nel momento in cui si va a ridefinire il prodotto e a dargli nuova vita.

La progressiva definizione del prodotto

Siamo arrivati attraverso step successivi e incrementali a definire quale sarebbe stata l’experience della nuova piattaforma, un lavoro che si fa tornando ciclicamente sugli stessi aspetti prima abbozzati a un livello molto alto e poi mano a mano entrando sempre più in dettaglio. 

Siamo partiti dopo le analisi e la definizione delle personas riformulando il prodotto a partire da un concept, una presentazione di alto livello che racconta quali sono le principali novità della piattaforma per dare un quadro complessivo della proposta.

Poi si entra un po’ più in dettaglio in quella che è l’esperienza utente: abbiamo ridefinito la customer journey indicando le azioni principali dell’utente da una parte e dall’altra i touchpoint, le criticità, i bisogni nei vari step e i gap che si potevano andare a colmare. 

A partire dalla customer Journey è possibile cominciare a disegnare il flusso di interazione descrivendo come si sposta l’utente tra le varie schermate della piattaforma o tra le varie pagine se fosse un sito web. Questo è un livello di dettaglio che da già informazioni preziose al team di sviluppo, in particolar modo sugli aspetti di back-end. 

Il passo successivo è stato la creazione di un wireframe, una struttura nuda di che cosa è presente nelle varie schermate della piattaforma, quali sono i pesi relativi degli elementi all’interno di una schermata, quali sono le azioni principali e secondarie e le informazioni a disposizione dell’utente.

Infine da questo artefatto siamo passati ai template visuali e – nel nostro caso – alla creazione di un vero e proprio design system perché questo ci ha consentito di procedere molto speditamente anche nel momento in cui la piattaforma dopo il rilascio iniziale ha cominciato ad evolvere. 

Pensare e testare il prodotto – intervento all’Agile Experience Conference

Recentemente ho preso parte all’Agile Experience Conference organizzata dagli amici di Agile for Italy. Si tratta di incontri live caratterizzati da un taglio pratico e dalla formula intervento iniziale più intervista da parte dei peer.
Giovedì 18 febbraio ho parlato di come “Pensare e testare il prodotto” in compagnia di Roberto Lunazzi, Lorenzo Cassulo e Deborah Ghisolfi.
Abbiamo approfondito quali tecniche usare per creare un prodotto amato dai nostri clienti, quali metriche e quali difficoltà si incontrano.

Qui trovate la registrazione:

Ed ecco a voi una traccia del mio intervento.

Le precondizioni di un buon progetto

Dobbiamo fare una premessa prima di affrontare il momento della discovery di prodotto.
E’ necessario fare un setting quando affrontate progetti di questo tipo per comprendere:

  • chi saranno gli interlocutori (il cliente finale, l’acquirente, lo sponsor in azienda, il responsabile della decisioni finale e chi può influenzare il progetto).
    E’ fondamentale riuscire a mappare tutti questi attori per partire con il piede giusto;
  • qual è esattamente l’obiettivo.
    Quando si fanno attività di questo tipo c’è sempre un’aspettativa da parte dell’azienda, che siano obiettivi di ricavi, quote di mercato piuttosto o volumi di vendita.
    È opportuno fare tante domande prima di iniziare e capire bene quali sono le regole del gioco perché gli obiettivi si possono portare a casa in molti modi e noi dobbiamo capire quali sono i trade-off percorribili.

Prima di tutto vi voglio proporre una distinzione tra prodotti totalmente nuovi e prodotti esistenti che devono essere fatti evolvere, ottimizzati, ecc.
Perché questo? Perché nei due casi abbiamo a disposizione strumenti diversi.

Creare prodotti, ma di che tipo?

Nuovi prodotti

Stiamo parlando di una situazione in cui non abbiamo dati a disposizione di prima mano.
Il prodotto non è presente in azienda; stiamo creando qualcosa di nuovo con cui non ci siamo ancora confrontati.

Cosa faccio di solito io?

Analisi

Faccio un’analisi: cerco gli stessi prodotti o soluzioni simili sul mercato e li studio (se posso li utilizzo direttamente, altrimenti cerco qualcuno che ne abbia esperienza, cerco materiale online, help o video, commenti, ratings).
Queste sono tutte informazioni utili per cominciare a farmi un’idea di questa tipologia di prodotti:
– come sono fatti
– che caratteristiche hanno
– quali sono i loro punti di forza
– eventuali punti deboli.

Personas

L’altro passo che faccio immediatamente è andare a capire chi sarà il mio pubblico.
Dedico tempo alla costruzione delle personas primarie che coincidono con i miei utilizzatori.
Si dice che i PO sono la voce del cliente in azienda ma se questa voce non la ascoltiamo mai dal vivo non stiamo facendo il nostro lavoro, ci stiamo perdendo una grande opportunità.

Con le personas voglio capire quale sarà il mio segmento di pubblico, non solo da un punto di vista socio-demografico.
Qui ho bisogno di scavare in profondità:
– che tipo di bisogni ha?
– quali preoccupazioni?
– cosa vuole ottenere?
– cosa è importante per queste persone?
– che cosa li motiva e li ispira?

Devo riuscire a costruire un profilo a tutto tondo per potermi mettere nei loro panni e verificare che il nuovo prodotto risponda alle sue necessità.

Impact Mapping

Negli anni uno strumento che mi è venuto molto in aiuto nella creazione di nuovi prodotti è l’impact mapping.
E’ una tecnica di pianificazione strategica che ci aiuta a costruire la mappa mentale del progetto:
– qual è esattamente l’obiettivo che vogliamo ottenere
– quali sono gli attori in gioco (e qui tornano in gioco le personas ma non solo)
– quali sono gli impatti che vogliamo produrre ovvero i cambiamenti nel comportamento degli attori
– quali attività (ovvero funzionalità o caratteristiche del prodotto potrebbero aiutarci ad ottenerli).

Per costruire questa mappa si fanno sessioni collaborative, più persone con diversi ruoli e competenze. Maggiore è la varietà e meglio è.

Sessioni collaborative di discovery

Come dico sempre il prodotto è un gioco di squadra, non è qualcosa che fate chiusi da soli dentro il vostro ufficio. Avete bisogno di un confronto continuo nella fase di discovery.

Ecco perché consiglio di sfruttare il più possibile per la creazione di nuovi prodotti le sessioni collaborative di co-creazione: facciamo brainstorming, ad esempio lift-off di progetto o – se ne avete la possibilità – potete proporre degli innovation days o degli hackathon dove diversi team cross-funzionali elaborano idee, le migliori vengono votate e si può arrivare a generare un prototipo dell’idea.

Tutti questi eventi hanno un enorme vantaggio perché portano le persone a bordo, fanno comprendere la sfida e consentono di generare tantissime idee così da selezionare le migliori.

Migliorare prodotti esistenti

Dati ed esperienze di prima mano

Qui possiamo utilizzare tutto quello che abbiamo detto prima ma abbiamo altre frecce al nostro arco. Esistono già degli utenti del nostro prodotto, abbiamo dati di acquisto e di utilizzo.
Sfruttiamo al massimo questi mezzi!
Andiamo a parlare con acquirenti e utilizzatori, intervistiamoli (i dati quantitativi non vi bastano per capire i fenomeni, dovete capire il perché), guardiamo gli analytics, dati di vendita e utilizzo, le registrazioni di sessioni utente, le domande che arrivano all’assistenza clienti o vengono fatte ai commerciali, sondaggi, analisi della customer journey.

Io di solito parto da interviste interne all’azienda per farmi un’idea dei problemi principali, monitoro l’utilizzo e poi vado a fare interviste qualitative.

Interviste JBTD

Potete utilizzare il framework JBTD con cui cercate di capire a quale scopo serve il prodotto o il servizio, sia da un punto di vista più funzionale (è il cosiddetto lavoro primario), sia da un punto di vista emotivo e sociale (come il prodotto fa sentire il cliente, come viene percepito dagli altri).
Perché sono importanti? Perché se non capiamo sulla base di che cosa un utente sceglie il nostro prodotto, quali sono i suoi parametri principali o creiamo una soluzione che non vuole nessuno (e magari questo problema non l’avete con un restyling o un replatforming) o riempiamo il prodotto di funzionalità inutili che non ne aumentano il valore, bensì lo diminuiscono.

Utilizzando anche solo alcuni di questi strumenti avrete raccolto una marea di informazioni su cosa funziona e cosa no, avrete moltissimi spunti su cosa aggredire per primo e avrete generato un backlog di attività.

Pronti per lo sviluppo? No, testiamo l’idea di business

A me piace l’idea di testare l’idea di business (non stiamo parlando di testare il prodotto finito); stiamo parlando di compiere un giro completo prima ancora di partire con un singola riga di codice.
E’ un approccio che è diventato sempre più mainstream negli ultimi anni. Da Lean Startup in avanti è conosciutissimo.

Experiment Map

Qui ci vengono in aiuto una serie di strumenti: ad esempio potete utilizzare un semplicissimo canvas, quello della experiment map. Identificate quali sono le assunzioni più rischiose che stanno dietro alla vostra soluzione, chiarite il risultato che vorreste ottenere e poi costruite un esperimento (il più semplice e meno costoso possibile) per verificare la vostra idea.
Non serve avere il prodotto finito, basta abbozzarlo!

Minimum Viable Product

Ci rifacciamo al concetto di MVP, Minimum Viable Product, una delle idee più bistrattate e meno comprese.
Quando parlo di MVP mi viene sempre in mente l’esempio di Zappos che nel 1999 ha testato l’assunzione più rischiosa che stava dietro alla sua idea di business con un concierge MVP.
Tenete conto che l’e-commerce non era il fenomeno che è adesso. Il founder doveva capire se le persone sarebbero state disposte a comprare qualcosa online – le scarpe – senza poterlo provare.
Ha costruito un negozio finto, un front-end vetrina senza che ci fossero tutti i processi dietro. Ogni volta che qualcuno cliccava sul pulsante “Compra” andava fisicamente a comprare il paio di scarpe in negozio.

Design Sprint

Negli anni gli strumenti sono diventati sempre più sofisticati: pensate al design sprint inventato da Google Venture. In 5 giorni riducete i rischi del lancio sul mercato di un nuovo prodotto o servizio. Partite dalla definizione del problema, fate brainstorming delle possibili soluzioni, scegliete la più promettente, costruite un prototipo e lo validate con potenziali utenti.
Questo non vi fa solo risparmiare tempo e denaro, vi fa risparmiare la creazione di waste.

Conclusioni

In sintesi abbiamo tanti strumenti a disposizione.
Non esiste lo strumento perfetto o un unico strumento per un problema.
Provateli, testateli e cercate quello che più vi risuona, con cui vi trovate bene.

Ma la cosa importante non sono gli strumenti in sé.
Quando penso alla creazione di un nuovo prodotto per me è determinante l’approccio che è fatto di questi ingredienti principali: ascolto, lavoro di squadra, confronto con la realtà (uscite dagli uffici!), utilizzo di dati e sapere di non sapere.
Tutto è ancora da imparare!

Minimum Viable Product o del valore in una fetta di torta

MVP e Release di prodotto

Nella pianificazione di una release ci si trova spesso a valutare a che punto sarà disponibile il prodotto per l’utente finale. Ma se adottate l’idea del Minimum Viable Product potreste decidere di rilasciare una “early beta” del prodotto per testare le vostre assunzioni in termini di ipotesi di valore e ricevere feedback dagli utenti quando lo sviluppo è ancora in corso.

La strategia dell’MVP presenta indubbiamente molti vantaggi: rilasciamo un prodotto (o una funzionalità) ad uno stato essenziale, totalmente “no frills”, perché desideriamo capire ciò che i clienti vogliono veramente, non ciò che dicono di volere o ciò che pensiamo vorrebbero.

Per anticipare il più possibile questo tipo di apprendimento potreste decidere di dare in mano ad una cerchia ristretta di utenti poco più che una presentazione o un wireframe.
Se non è questo il vostro caso, come spesso non lo è per me, rilascerete software funzionante ma dovrete identificare il set minimo di funzionalità in grado di comunicare il valore del vostro prodotto.

Cosa inserire in un MVP

Non è un’operazione così banale come può sembrare a prima vista…
Dovrete far comprendere a chi sviluppa qual è il valore del prodotto dal punto di vista dell’utente finale, un valore che sta nella soluzione di un problema, nella “slice” – la più piccola fetta compiuta – e non in un layer.

Questo approccio dal punto di vista di chi sviluppa è solitamente molto più oneroso perché significa aggredire più sistemi contemporaneamente invece che lavorare “a strati”.
Comporta molto più effort ma, allo stesso tempo, abbatte decisamente il rischio. Insomma, avrete la vostra bella negoziazione da fare con il tech team ma ne vale la pena.

Per rilasciare un MVP dovete concentrarvi sul COSA, su un piccolo pezzo, una singola funzionalità purché finita e funzionante. Fatela funzionare, fatela testare sul campo anche solo da un’unica tipologia dei vostri utenti e – intanto che analizzate i primi feedback – valuterete quali parti mancanti vale la pena di integrare e come.

Cos’è valore per il cliente?

Tenete presente che ciò che interessa all’utente è il servizio nel suo complesso, ma dovendo “fare a fette un elefante” nella mia esperienza ho trovato più utile un approccio verticale piuttosto che orizzontale.
In un servizio e-commerce, ad esempio, l’utente valuterà le diverse funzionalità: la navigazione nel catalogo dei prodotti, la ricerca, il carrello per l’acquisto, l’archivio degli ordini. Quale beneficio trarrebbe se il layer dei dati e quello applicativo fossero perfettamente compiuti ma non fosse possibile neanche consultare il catalogo dei prodotti?

E’ esattamente la differenza che passa tra una fetta di Sacher – per quanto piccola – ed uno strato di torta al cioccolato. Qual è più appetitosa in un uggioso pomeriggio di pioggia invernale? Cosa preferireste mangiare per merenda?
Io non ho dubbi!

P.S.: e non ditemi che non avete mai assaggiato la Sacher Torte perché se no avete ben altri problemi che individuare il vostro Minimum Viable Product …

Continuiamo così, facciamoci del male!  (… grazie Moretti!)