Data Driven Products: best practices per organizzare e sfruttare i dati – con Alessandro Mozzato, Data Scientist @Meta

Data Driven Products, ne avete mai sentito parlare? Speriamo di sì 🙂
Noi lo abbiamo fatto, un po’ di tempo fa, con Alessandro Mozzato, oggi Senior Data Scientist @Meta, durante una delle nostre prime dirette Live di Product Heroes con la Sara Tortoli.

Alessandro Mozzato è Data Scientist con tanti anni di esperienza nell’ambito della Data Science e del Machine Learning. Ha lavorato in Enel, per Booking.com e adesso si occupa di modelli predittivi , regressione logistica, ETL, strutture dati, spark e Data science in Meta.

Cosa vedremo in questo post:

Data Driven Products

Best practices per organizzare i dati

Una premessa è doverosa: per parlare di dati e di Data Driven Products, dobbiamo sicuramente soffermarci su cosa sia una machine learning, AI e Big Data. Oggi ne sentiamo molto parlare, basti pensare a ChatGPT e OpenAI, tema a cui avevamo anche dedicato un articolo sul nostro blog.

In generale, nel cappello delle machine learning si inseriscono varie sotto-discipline. Come ci suggeriva Alessandro, si tratta dell’insieme di tutte quelle tecniche che vengono utilizzate per estrarre informazioni dai dati, trovare dei pattern ai dati ed essere in grado di trovare degli insight dai dati. L’AI e i Big Data sono tutte sottobranche che rientrano nel grande ombrello delle machine learnings.

Per poterle utilizzare, è necessario avere una basi di dati ben strutturata e organizzata. Se non abbiamo dati o li abbiamo strutturati male, non riusciremo a lavorarci su. Dunque, quali sono le best practices per organizzarli al meglio?

Per Alessandro, può avere senso prevedere la figura di un Data Scientist o di un esperto di machine learning nello sviluppo del prodotto, anche in fase iniziale.Questo non significa applicare le machine learning fin dall’inizio, ma perché, inserendo qualcuno che sia esperto di dati, potrà anche avere un’idea nel futuro di come questi dati potranno essere utilizzati per migliorare il nostro prodotto, intervenendo e dicendoci se avremo bisogno di questo dato, strutturato in questo modo, senza errori senza questo, eccetera”.

Indispensabile, poi, prevedere un periodo di raccolta dati, prima di essere in grado di applicare. 

“Un esempio pratico? Facebook, ma anche tutti gli altri social networks, sono stati creati più o meno nella metà degli anni 2000. Facebook, nel 2006, ha inserito il News Feed, ma fino al 2009 questo newsfeed non conteneva alcun tipo di machine learning. Era semplicemente un ordine cronologico di tutti i vari avvenimenti.

Questo cosa vuol dire? Che loro hanno aspettato di avere sufficiente quantità di dati, hanno aspettato di strutturare il loro prodotto prima di cambiarlo e adesso tutti noi sappiamo che è una delle parti fondamentali in cui viene applicato un machine learning. Sappiamo che l’algoritmo è tarato verso ognuno di noi, personalizzato. E questo vale per tutti i social network, più o meno. Però, nella fase iniziale di sviluppo di questi social network, non c’era nessuna machine learning. E il motivo è proprio questo: c’è tutta una fase iniziale in cui bisogna fare una raccolta, una struttura, uno studio”.

Come sfruttare i dati

Ok, abbiamo raccolto i dati. Ora cosa ne facciamo?

Il dato può essere comunque utilizzato in un primo momento per, ad esempio, generare delle ipotesi da testare, per generare delle regole di base atte a migliorare il nostro prodotto e, piano piano, arrivare a degli algoritmi veri e propri.

Un esempio. Vogliamo fare un prodotto che sia un insieme di raccomandazioni per destinazioni, pensiamo a Booking.com. Vogliamo periodicamente spedire delle mail agli utenti con cui suggeriamo quali possono essere le destinazioni a loro congeniali. Cosa facciamo?

“All’inizio probabilmente inizieremo suggerendo agli utenti delle destinazioni non dico casuali, ma quasi. Seguendo una regola, tipo: le destinazioni più popolari in assoluto o quelle che riguardo un periodo dell’anno specifico, a Natale suggeriamo impianti sciistici e simili, per esempio. Diciamo che abbiamo questo prodotto, quindi vogliamo validarlo. Bisogna validare che il prodotto funzioni. Lo validiamo rapidamente, vediamo che gli utenti sono interessati a ricevere queste raccomandazioni, dopodiché – quando abbiamo raccolto questi dati, sappiamo pure come gli utenti interagiscono con l’email, cosa cliccano, cosa prenotano, eccetera – possiamo cominciare a personalizzare questo tipo di raccomandazioni”.

Ad esempio, se sappiamo che un determinato utente ha una storia di prenotazioni in un determinato tipo di strutture e di destinazioni, possiamo cominciare ad utilizzare questi dati. Possiamo, ad esempio, suggerire le destinazioni più popolari. Il tutto, senza usare nessuna machine learning. In questo modo possiamo già suggerire le destinazioni più popolari per quel tipo di utente: sappiamo che viaggia da solo, in famiglia o in coppia, e allora specificatamente possiamo cominciare a trovare le destinazioni più popolari in quel periodo per l’utente specifico e fare delle raccomandazioni del genere. 

“Questo non è ancora Machine Learning, ma è un utilizzo dei dati per cominciare a migliorare il nostro prodotto. Ogni volta chiaramente iteriamo sul prodotto e sperimentiamo, quindi facciamo A/B test e piano piano miglioriamo. Dopo di che, quando vediamo che il nostro prodotto sta migliorando, allora siamo pronti a usare qualcosa di più complesso. Vediamo che più personalizziamo le nostre raccomandazioni più funzionano, allora possiamo pensare di dire: usiamo un algoritmo che prenda qualsiasi dato sull’utente”.

Può prendere il passato, le ultime ricerche effettuate dall’utente, il periodo dell’anno, il prezzo medio che l’utente ha pagato negli ultimi acquisti su Booking.com, le destinazioni, eccetera.

E chiaramente cresce, cresce sempre di più. “Da questo possiamo effettivamente generare un cosiddetto modello per prevedere quali sono, similmente, delle prossime destinazioni specifiche per questo utente”.

Data Driven Products: la collaborazione tra Data Scientist e Product Manager

Parlando di Big Data, Machine Learning e Data Driven Products non potevamo non chiederci: qual è la versione ottimale del rapporto tra un PM e un Data Scientist? Parliamo di un Development Team. Dunque, come collaborano i data scientists con i product managers, ma anche con i software developers?

“Una versione ottimale della collaborazione è molto difficile da trovare. La mia esperienza parte da un rapporto di collaborazione continuo. Io, data scientist, non sono isolato e c’è un team che vuole utilizzare le mie conoscenze. Lavoriamo tutti insieme.

La cosa principale da tenere in considerazione è il fatto che per machine learning intendiamo sempre un insieme di tecniche abbastanza complesse, ma anche incerte. Per esempio: quando si comincia un progetto e si vuole fare un modello di previsione per qualcosa e non sappiamo esattamente che tipo di risultati avremo, in quanto tempo saremo capaci di ottenere risultati. Oppure, se i risultati che riusciamo a ottenere offline, poi si traducono anche nell’applicare questo modello online, e questo si traduce in una esperienza positiva per l’utente. 

Tutto questo fa sì che il rapporto tra il Data Scientist e il team sia un po’ diverso dal rapporto classico che esiste tra Developer e il team. Il data scientist ha questa sicurezza nelle task, è in grado magari di prevedere con una certa correttezza le tempistiche, i vari step dello sviluppo di un prodotto.

Per cui, una delle cose più importanti è collaborare sempre con un data scientist, soprattutto se abbiamo in mente di utilizzare delle machine learning per lo sviluppo del prodotto. E, dopo di che, in parallelo, tenere presente che queste soluzioni complesse impiegano del tempo ad essere sviluppate. Quindi avere o dei piani B o dei modi per fare interazioni sul prodotto senza aver bisogno del machine learning finito“.

Vuol dire cominciare a raccogliere dei dati, poi lavorare all’algoritmo di machine learning, sfruttando tutta una roadmap di iterazioni che posso fare prima. “E che magari coinvolgono anche un data scientist che collabori, che dia delle idee o che sviluppi dei piccoli prodotti che non sono proprio machine learning, ma sono delle cose più immediate. Quindi questo è un po’ il rapporto di collaborazione che io ho visto”.

Come si inserisce il Data Scientist all’interno del team

Ma quindi, Data Scientist come stand-alone team? Dunque, un data scientist con un data product manager separato, o data scientist all’interno di un normale development team con back-end, front-end, QA, UX, UI?

Possiamo considerarle come entità separate, o come parte integrante di un development team, e quindi anche gestito da un solo backlog, no? Qual è l’approccio migliore?

“Io sono all’interno di un team specifico. Mi occupo di tutto quello che riguarda search, ma col team specifico di search tutti i miei colleghi fanno lo sviluppo, non solo di prodotti di data sciences, ma di tutto quello che ha a che fare con risultati di ricerca.

Questo è un sistema funzionale, proprio perché il data scientist è sempre presente nello sviluppo dei prodotti che non sono di data science, ma in generale è nel loop. Può vedere come si sta svolgendo l’iterazione. Può commentare gli esperimenti col team, ma soprattutto col PM. Un’altra cosa che nella mia esperienza è importantissima è la relazione tra PM e data scientist: è un po’ diversa da quella che c’è tra developer e PM. Sembra più una cosa quasi alla pari. Soprattutto quando si parla di decisioni su come iterare, lo studio degli esperimenti, lo studio delle metriche degli esperimenti da cui prendere delle insights.

In generale, tutto il team partecipa alle decisioni, tutto il team decide come iterare. Però ci sono queste piccole differenze“.

Riascolta l’intera puntata per approfondire l’intervista a Alessandro Mozzato, Senior Data Scientist @Meta e iscriviti alla newsletter di Product Heroes per non perderti neanche un nostro contenuto!

Facci sapere nei commenti tuoi dubbi o richieste, siamo qui per risponderti.

Dicci cosa ne pensi

Le slide sono disponibili per studenti ed ex studenti del Master in Product Management

Accedi a "Agile Starter Kit" Gratis

Iscriviti alla newsletter e accedi ad Agile Starter Kit: la cartella che contiene oltre 70 pagine su Agile, Scrum / Kanban, Organizzazione Team, User Story, Backlog, e tutto ciò che ti serve per partire.

Scarica il post sulle alternative a Scrum

Iscriviti alla newsletter e scarica gratuitamente il post "Agile Scrum: Alternative più flessibili e agili"