Vorresti avviare una transizione al Product Operating Model nella tua azienda, ma non sai da dove iniziare? Allora potrebbe interessarti questo caso di successo in Pirelli.
- Introduzione
- Step#1: scoprire e capire il Product Management
- Step#2: analisi del contesto
- Step#3: definizione collaborativa di missione e strategia di prodotto
- Step#4: ideazione Lean di un MVP da cui ripartire
- Step#5: redazione Business Case per finanziamento dell’iniziativa
- Step#6: nuova discovery e testing dei prototipi
- Step#7: formalizzazione e monitoraggio obiettivi tramite OKRs
- Step#8: delivery dell’MLP
- Step#9: da roadmap “date-bound | output-driven” a “period-bound | outcome-driven”
- Step#10: Continuous Discovery e continuous evangelization
- Conclusioni
Introduzione
TRANSFORMED – Moving to the Product Operating Model — il nuovo libro di Marty Cagan — è da poco disponibile nelle principali librerie online e non. Chiunque segua le dinamiche del Product Management e dintorni, non può non aver appreso di questa sua nuova opera di divulgazione, o essersi imbattuto su almeno un commento o un’opinione al riguardo.
Ciò non stupisce, perché Marty Cagan può essere considerato il padre fondatore della corrente di product-pensiero, o quantomeno, il primo ad aver capito quanto bisogno ci fosse di evangelizzare i princìpi cardine con cui le società di maggior successo costruiscono prodotti e servizi digitali amati da miliardi di utenti.
Parliamo di aziende come Microsoft, Apple, Google, Amazon o Meta, stabilmente ai primi posti della classifica di quelle a maggior capitalizzazione al mondo:
e che, sebbene abbiano ciascuna la propria identità e cultura aziendale, condividono un modello operativo di gestione prodotti — definito talvolta Product-centric, altre volte Product-led, ed in ultimo Product (Operating) Model — a cui Marty ha dedicato gli ultimi venti anni della sua carriera divulgativa.
Nonostante ciò, la domanda che più spesso gli è stata rivolta fino ad oggi è:
“La nostra azienda opera in modo così diverso dal modello evangelizzato. È possibile per un’azienda come la nostra passare al Product Model, e come potremmo riuscirci?”
Col suo ultimo libro, l’obiettivo che si è dato è proprio quello di rispondere in maniera esaustiva a questa domanda.
“While the new book [TRANSFORMED, n.d.r.] does discuss strong product management, along with several other critical key competencies, the book – and the product model it describes – is about much more than just product managers, it is about transforming companies.”
—Marty Cagan
“Transforming” e “moving”… ma da cosa?
Da una serie di modelli operativi ormai inefficienti rispetto alle dinamiche di un mercato di prodotti e servizi digitali, sempre più competitivo e caratterizzato da standard qualitativi che crescono alla velocità della luce — ancor più dopo l’avvento dirompente della AI generativa.
Esempi di modelli di partenza che Marty annovera come potenzialmente inefficienti:
- IT model, dove solitamente ci si riferisce “al Business” come origine delle richieste avanzate “all’IT”, presente in azienda proprio allo scopo di servire il core business
- Project model, in cui finanziamento e staffing avvengono sulla base di un progetto da portare a termine
- Feature-team model, in cui diversi stakeholder guidano ciascuno la propria roadmap di funzionalità
- Sales/Marketing-driven model, se a guidare la roadmap evolutiva di prodotto sono i team Sales e/o Marketing.
Comunque li si definisca, ciascuno di questi modelli rappresenta il punto di partenza della trasformazione, in cui i team di progetto/prodotto esistono principalmente per servire i bisogni del business, o meglio, dei business leaders.
E in cosa differisce il Product model?
Nel Product model, che rappresenta lo stadio finale della trasformazione, i team di prodotto esistono per risolvere sistematicamente i problemi dei clienti e del business, ma in una modalità che i nostri clienti amino e che sia al contempo sostenibile per il business.
In estrema sintesi, questo modello ambisce a massimizzare il ritorno d’investimento tecnologico ottimizzando:
- come costruiamo i prodotti → implementando micro-rilasci frequenti (almeno ogni 2 settimane) e rigorosamente misurabili → per accorciare il Time To Market
- come risolviamo i problemi → responsabilizzando i team di prodotto, a cui assegnare problemi da risolvere attraverso soluzioni tecnologiche che, dopo opportuna Product Discovery, abbiano dimostrato di essere di valore, usabili, fattibili e sostenibili per il business → per accorciare il Time To Money
- come decidiamo quali problemi risolvere → definendo top-down una chiara visione di prodotto che ispiri, e un’unica strategia che determini inequivocabilmente quali opportunità perseguire → per minimizzare il Cost of Opportunity
E quindi, come potremmo riuscirci?
Marty identifica nella sua guida una serie di concetti e nuove competenze — che si basano sui princìpi cardine menzionati poc’anzi — da sviluppare ad ogni livello dell’organizzazione affinché questa implementi con successo il Product model. In sostanza, è necessario che chiunque — dal CEO alla risorsa entry-level — acquisisca, metta in pratica e diffonda questi princìpi del successo.
E a chi spetta il primo passo?
Abbiamo menzionato più volte i termini “partenza” e “destinazione”. Ciò suggerisce come la trasformazione sia un percorso — evoluzionario e mai rivoluzionario — in cui il primo passo possa esser compiuto sia “dall’alto” (verso il basso, approccio top-down) che “dal basso” (verso l’alto, approccio bottom-up).
Sebbene sia indiscutibilmente più efficace un’iniziativa top-down, in cui la leadership per prima prenda consapevolezza ed iniziativa di un cambiamento necessario, è lo stesso Marty Cagan in un episodio del Lenny’s Podcast a sottolineare come una trasformazione di successo possa partire anche “from the ground up”:
“There is a lot an individual contributor could do. […] They can literally do a self-assessment and raise the skills from a product owner or a feature team product manager to a real product manager. […] At a minimum, our company will appreciate it and probably promote you because you will be one of the few that actually understands these things. Hopefully even more than that, they’ll say: “hey, why don’t we try running a set of teams this way and see how we do? So it can happen from the ground up too.””
— Marty Cagan
Concetto ribadito anche da Sabrina Mach col suo intervento “Working with a split head” alla scorsa Product Heroes Conference, in cui confermava come si possa partire “dal basso” — ad esempio da un progetto con poca visibilità — sviluppato da un team che faccia da “faro”:
“Teams are really comfortable within their comfort zone – how do we motivate them to embrace change towards product mode? And how to convince stakeholders that the experiment is worth? We start from a self-assessment of the current state, collecting data across the organisation. Then we think of what the current future state might look like. Instead of boiling the ocean and do it all, we could create a lighthouse team to proof how this transformation could work and bring value.”
— Sabrina Mach
La storia di oggi
Ebbene, con questo articolo, voglio condividere step-by-step la storia super-pratica di un (ancor piccolo) caso di successo di trasformazione bottom-up in Pirelli, e di come un team “faro” veramente empowered possa raggiungere non solo il cuore degli utenti, ma anche quello degli stakeholder in azienda.
Step#1: scoprire e capire il Product Management
Era il 2017 quando approdai in Pirelli per ricoprire un ruolo da IT Project Manager. Questo titolo lavorativo suggerisce il modello operativo da cui parte questo racconto di trasformazione: un mix tra i sopracitati IT model e Project model.
Dopo aver portato a termine alcuni progetti di redesign tecnologico, in cui gli obiettivi erano tipicamente definiti sotto forma di output:
- “migrare l’applicativo X sul Cloud”
- “trasformare in web app il tool standalone Y”
- “riprogettare i servizi web Z con architettura a microservizi”
colsi l’opportunità di ricoprire un ruolo da SCRUM Product Owner in una fase di sperimentazione dei potenziali benefici dello sviluppo Agile. L’enfasi su sviluppo non è casuale; difatti, si stava partendo con l’applicarne i sani princìpi a questa sola fase.
A tal proposito, ci trovavamo agli arbori di un’ambiziosa Digital Transformation che mirava a trasformare non solo processi e tecnologie a supporto, ma anche la stessa identità “dell’IT”: da supporter a vero e proprio partner dei team Business, in cui l’Agile avrebbe dovuto giocare un ruolo primario nello sviluppo collaborativo e cross-funzionale.
Ricordo come un brillante slogan del periodo, in occasione del contestuale ritorno in Borsa di Pirelli, recitasse:
per mettere in luce la sua vocazione all’innovazione, spinta per definizione dall’avvento della digitalizzazione.
Come Product Owner, iniziai a capire cosa significasse creare da zero un intero prodotto/servizio digitale, nel bene e nel male. Insomma, conobbi le due facce della stessa medaglia:
- il piacere del successo — inteso come riuscire a soddisfare i bisogni degli utenti
- la scottatura del fallimento — inteso come l’esatto opposto
Fast forward fino alla fine del 2019. Un fallimento, in particolare, mi spinse a cercare assiduamente una risposta alla domanda che ne scaturì:
Possibile che siano solo sporadiche idee geniali — prerogativa di pochi — a spingere lancio e sviluppo dei prodotti di maggior successo?
In particolare, mi imbattei in un corso su una nota piattaforma di e-learning che mi aprì gli occhi su moltissimi aspetti della gestione dei prodotti digitali. Ovvero su alcuni di quei Product First Principles bollati da Marty Cagan come “foundation upon which transformation rests“.
Quel corso, incentrato sulla metodologia “Lean Startup” di Eric Ries, rispose finalmente alla mia domanda:
No, è il Product Management.
e rappresentò lo spartiacque della mia carriera. Sì, perché fu da allora che iniziai a sperimentare senza sosta sul lavoro — grazie ad un contesto abbastanza favorevole — questo “nuovo” approccio.
Step#2: analisi del contesto
Già, perché come appena accennato, condizione necessaria affinché si potesse sperimentare, fu proprio un contesto particolarmente favorevole grazie al manifestarsi delle seguenti condizioni:
- Un team IT empowered
- Un team Business partner
- L’opportunità di rilanciare un prodotto di nicchia
Un team IT empowered
Ci trovavamo ancora in piena Digital Transformation, rallentata dalla crisi da COVID-19, e di cui iniziativa integrante fu una riorganizzazione della funzione “IT” a cui afferivo. La missione definita per il neonato team “Digital Products” fu quella di diventare un centro di eccellenza che agisse da catalizzatore, acceleratore e facilitatore dello sviluppo end-to-end di tutti i nuovi prodotti e servizi digitali Pirelli. In pratica, come accennato poc’anzi, diventare partner dei team Business.
A tal scopo, la leadership Digital agì su due fronti principali:
- assumendo professionisti con forti competenze nel design e sviluppo “agile” di prodotti tecnologici innovativi — p.e. Product and Service Designers, Full Stack Engineers, iOS/Android Engineers, Cloud Architects, DevOps Engineers
- estendendo l’offerta formativa per le persone già presenti nel Gruppo — p.e. integrandola di una nota piattaforma di e-learning particolarmente fornita di corsi tech-oriented (tra cui proprio quello che mi fece scoprire il Product Management).
La commistione delle due azioni potenzianti plasmò un intraprendente team di talenti, pronto ad affrontare nuove sfide mettendo in gioco queste nuove competenze. In pratica, gettammo le fondamenta per lo sviluppo di quello che secondo Marty Cagan è IL concetto (principale) su cui si basa il Product model: un team di prodotto
- empowered — disposto a farsi carico di problemi (degli utenti finali o del business Pirelli) da risolvere, e non solo di soluzioni da implementare
- cross-funzionale — composto da membri che potessero coprire ciascuna delle competenze necessarie all’ideazione di soluzioni efficaci per i problemi assegnati
e che fungesse da “faro” in questa storia di trasformazione.
Un team Business partner
Queste azioni potenzianti rispondevano direttamente ad una domanda sempre maggiore di esplorare e sviluppare nuove opportunità di business a forte connotazione digital.
Una delle sfide che il rinnovato team fu chiamato ad affrontare fu la stabilizzazione di uno dei prodotti digitali Consumer più popolari di Pirelli.
Stiamo parlando dell’applicazione mobile DIABLO™ Super Biker, lanciata nella sua prima versione nel lontano 2011, in grado di fornire ai motociclisti particolarmente avvezzi alle prestazioni una sorta di telemetria con cui monitorare alcune interessanti statistiche di guida altrimenti difficili da rilevare come angolo di piega, velocità massima, accelerazioni laterali e frontali, etc. Fu una delle prime — se non addirittura la prima — a soddisfare questo desiderio in maniera semplice ed efficace, e complici un paio di articoli dedicatigli da alcune testate giornalistiche di settore, l’app divenne in un paio d’anni molto popolare, nonché la principale fonte di contatti CRM per la Business Unit Moto di Pirelli.
Tuttavia, negli anni successivi, l’app necessitò di aggiornamenti tecnici e di usabilità al punto che — tra il 2018 e il 2019 — non fu più possibile rimandarli. Fu proprio in questo frangente che i colleghi Marketing della BU Moto ci affidarono il compito, ma in regime di best-effort. La missione, infatti, ambiva a stabilizzare l’app, seppur consapevoli che fosse necessario un profondo re-design tecnologico e di esperienza utente.
Riuscimmo a portare a termine la missione con discreto successo. Ma non fu tanto questo l’aspetto cruciale della vicenda, quanto l’opportunità di poterci misurare direttamente coi principali problemi e desideri di un’ampia e appassionata base utenti Consumer.
Affrontando questa sfida, il nostro approccio evolvé da lì a poco da reattivo al bisogno impellente e orientato alla tecnologia, a proattivo e orientato all’opportunità — facendoci cioè portavoce delle potenzialità che un simile prodotto tecnologico avesse di impattare positivamente sia nella vita di migliaia di motociclisti appassionati, che nel business di Pirelli.
Da quel momento, il team Marketing si affidò alla nostra capacità di gestire non solo soluzioni “impacchettate” sotto forma di requisiti, ma anche l’intero processo di ricerca della miglior soluzione da implementare.
In questo stimolante clima di fiducia, diventammo a tutti gli effetti partner del Business.
L’opportunità di rilanciare un prodotto di nicchia
Dall’intervento sull’app DIABLO™ Super Biker, ci portammo a casa due evidenze:
- la base utenti era incredibilmente appassionata, e tra i problemi che riportava più spesso, emergevano dei pattern ricorrenti
- l’app era da riprogettare, sia la UX che l’architettura software.
Come logica conseguenza, iniziò a balenarci in testa sempre la stessa domanda:
E se riprogettassimo interamente l’app, spogliandola di qualsiasi funzionalità non necessaria, affinché risolva in maniera impeccabile i soli bisogni primari ed esaudisca i principali desideri dei nostri utenti?
A proposito della proattività — che fa rima con opportunità — non passò molto tempo prima che ponessimo la domanda anche ai colleghi del Marketing.
E fu subito comunione d’intenti.
D’altra parte, ambivano a rilanciare l’app in grande stile già da un po’ di tempo.
Loro avevano finalmente trovato i partner ideali per affrontare questa sfida. Noi la grande opportunità di partecipare a un’iniziativa:
- con pochi stakeholder da ingaggiare
- con molti utenti appassionati e “sostenitori”
- con pochi riflettori puntati addosso rispetto ad altre considerate più “strategiche”
In pratica, l’habitat perfetto per generare reale valore non solo per Pirelli, ma soprattutto per centinaia di migliaia di motociclisti appassionati.
Step#3: definizione collaborativa di missione e strategia di prodotto
Quando si pensa ai concetti di missione e strategia, sfido chiunque a non immaginarsi qualcosa di estremamente complesso e intricato, partorito da menti geniali come quelle del Professore ne “La Casa di Carta” o di Michael Scofield in “Prison Break”.
In questo caso, invece, entrambe ebbero origine da una semplice e-mail di recap.
Lo ammetto: era lunghetta. Ma in quella mail mi sforzai di mettere “nero su bianco” tutto quanto discusso e concordato coi vari stakeholder nelle puntate precedenti. In particolare:
- il macro-obiettivo che volevamo raggiungere con questa iniziativa di re-design → la missione
- il nostro piano composto da alcuni investimenti concreti che, se azzeccati, ci avrebbero permesso di raggiungere il macro-obiettivo → la strategia
La peculiarità di aver formalizzato “a quattro mani” questi due concetti — responsabilità che fino ad allora poteva collocarsi nel dominio delle funzioni Business — fu un’ulteriore prova che in questa iniziativa non vi era più alcun c.d. silos funzionale.
Missione
Figlia delle osservazioni pregresse su sorgenti informative eterogenee, la missione della nuova app DIABLO™ Super Biker ingloba(va) una componente più “romantica” — l’aspirazione di ripartire da quello spirito originario fatto di minimalismo, efficacia e affidabilità che l’avevano contraddistinta — e una più “pragmatica” — l’ambizione di far poi crescere organicamente il prodotto, ossessionandoci nel risolvere con massima soddisfazione i problemi e i desideri reali degli utenti.
In prima istanza scritta “alla buona”, come ogni missione che si rispetti, successivamente anche la nostra fu sintetizzata tramite un “bold statement” che avrebbe dovuto ispirarci nel lungo termine:
«TO PROVIDE THE SIMPLEST AND THE MOST RELIABLE APP THAT ENABLES PASSIONATE BIKERS TO TRACK AND RELIVE TO THE FULLEST THEIR RIDING EXPERIENCES»
- “To provide the simplest and the most reliable app…” → richiamo agli antichi fasti delle origini
- “…that enables passionate bikers…” → segmento di mercato target, confermato da quanto osservato durante il progetto di stabilizzazione dell’app
- “…to track and relive […] their riding experiences.” → desiderio primario del nostro segmento di mercato
- “…to the fullest…” → l’ambizione di alzare continuamente l’asticella in termini di esperienza utente.
Non mancava nulla all’appello. Avevamo ufficialmente una missione da compiere.
Strategia
Se la missione rappresenta ciò che stiamo cercando di realizzare, la strategia dovrebbe fornirci le istruzioni per riuscirci.
Come accennato, ciascuna istruzione costituiva un investimento concreto fatto a partire dalle nostre osservazioni sia del mondo esterno (industria di riferimento, trend tecnologici, etc.) che di quello interno (dati qualitativi e quantitativi, contesto aziendale, etc.), e che possiamo schematizzare come segue:
“Costruiamo un “MVP bulletproof” con cui re-ingaggiare i nostri utenti →
dopo averli re-ingaggiati, iniziamo a far evolvere l’MVP con piccoli add-on di valore →
mentre il prodotto cresce organicamente risolvendo con soddisfazione i reali problemi degli utenti, generiamo “leads” →
iniziamo a segmentare al meglio i nostri utenti e facciamo leva sulle nuove tecnologie impiegate per veicolare promo marketing mirate →
parliamo continuamente con sempre più utenti per ideare soluzioni ad alto valore aggiunto da monetizzare.”
Come potete notare, non si tratta di “rocket science”, ma di quanto basta a tracciare un percorso inequivocabile dall’”oggi” al “domani” che ci siamo immaginati per la nuova app, caratterizzato da alcune conquiste intermedie, l’una propedeutica all’altra.
E come ogni strategia che si rispetti, ci fornì(sce) l’assist per il prossimo step in questo percorso di trasformazione.
Step#4: ideazione Lean di un MVP da cui ripartire
La prima istruzione della nostra strategia indicava di ideare un “MVP bulletproof” con cui re-ingaggiare gli utenti.
Cos’era per noi un MVP?
Iniziamo con una doverosa premessa. Sul significato di Minimum Viable Product, e su cosa possa definirsi tale o no, si è dibattuto per anni.
Secondo la definizione originale di Eric Ries, l’obiettivo di un MVP è di validare le ipotesi chiave su un’idea di prodotto, ottenendo il massimo apprendimento con il minimo sforzo. Creare direttamente il prodotto, soprattutto scrivendo software, sarebbe invece uno dei modi più costosi per verificare queste ipotesi. Se si rivelassero errate, il lavoro svolto in molti mesi e iterazioni sarebbe sprecato.
Tuttavia, l’assunzione chiave che stavamo facendo su un prodotto così basilare:
- che avrebbe re-ingaggiato i nostri utenti storici
- che ne avrebbe acquisiti di nuovi
era già stata supportata da molte evidenze qualitative e quantitative. Avevamo ora bisogno di un vero e proprio “atto di fede” — a.k.a. investimento concreto — per ripartire dalla nostra “promessa principale” che ancora riecheggiava tra i bisogni principali dei motocicli appassionati di performances.
Quindi, prendendo in prestito alcuni contenuti da questo e da quest’altro articolo, chiarisco subito che nel nostro caso, lo intendessimo più come un “Single Feature MVP”:
O ancora, come un “Minimum Lovable Product (MLP)”, il cui scopo non è tanto quello di convalidare idee di prodotto, quanto quello di fare innamorare gli utenti del prodotto attraverso un’esperienza d’uso appagante.
Comunque lo si etichetti, la nostra filosofia era “less is more”: volevamo ripartire da un prodotto che facesse il “minimum” indispensabile, ma che lo facesse in maniera ineccepibile sotto tutti i punti di vista.
A dover di cronaca, il termine “MLP” è quello che utilizzammo nelle fasi successive, e quello che coerentemente utilizzerò da qui in avanti. 😊
“Come idearlo e quanto costerebbe?”
Ci chiesero i colleghi del Marketing della BU Moto.
Fu esattamente in questo momento che chiamai in causa il framework “Lean Startup” di Eric Ries.
Ricordate quel corso online che spiegava concretamente come applicarlo, e che mi permise di scoprire il Product Management? Lo avevo da poco completato, quindi organizzai col mio team un workshop a esso ispirato per giungere a un potenziale MLP da proporre e da stimare.
Quella esperienza, oltre che darci un assaggio di cosa significasse risolvere problemi comprovati degli utenti e del business, ma in una modalità che i nostri utenti amino e che sia al contempo sostenibile per il business, ci permise di:
- prendere decisioni informate a partire dall’analisi di dati qualitativi (recensioni — molte!, questionari, etc.) e quantitativi (metriche, analytics, etc.)
- identificare le assunzioni più rischiose dell’iniziativa
- definire ipotesi testabili a partire dalle assunzioni
- identificare i criteri minimi di successo di un test
- prioritizzare le funzionalità per l’MLP
Grazie a quest’ulteriore spinta di empowerment, avevamo definito insieme un MLP fattibile, che ci avrebbe permesso di convalidare le nostre ipotesi sulla desiderabilità, e che ci aiutò a stimare costi e potenziali benefici dell’iniziativa.
Mancava ora un ultimo passaggio — nonché quello principale — prima di metterci all’opera per consegnare l’MLP nelle mani dei nostri utenti: l’investimento “concreto”… nel vero senso della parola! 💰
Step#5: redazione Business Case per finanziamento dell’iniziativa
Ricordate il modello operativo di partenza?
In un mix tra IT model e Project model, qualsiasi iniziativa digital ottiene i fondi necessari alla sua esecuzione solo se sostenuta da un solido Business Case.
Chiunque abbia letto INSPIRED, certamente ricorderà come Marty Cagan elencasse, tra le principali cause del fallimento dei progetti di prodotto, il modo in cui vengono pensati la maggior parte dei Business Cases. Nello specifico, quelli redatti a partire da una roadmap prestabilita di feature “prioritizzate” (secondo criteri tutt’altro che data-driven), e per cui pretendiamo di prevedere:
- quanto ci costeranno → difficile
- quanto ci faranno guadagnare → impossibile!
“Next, let’s talk about the fatal flaw in these business cases. To be clear, I’m personally in favor of doing business cases, at least for ideas that need a larger investment. But the way most companies do them at this stage to come up with a prioritized roadmap is truly ridiculous and here’s why. Remember those two key inputs to every business case? How much money you’ll make, and how much it will cost? Well, the cold, hard truth is that, at this stage, we have no clue about either of these. In fact, we can’t know.”
— Marty Cagan
Col senno del poi, posso affermare che il nostro Business Case non facesse parte del gruppo “demonizzato”, ma piuttosto del gruppo di casi “ammessi” dallo stesso Marty perché necessari a valutare la sostenibilità finanziaria (business viability risk) di un’idea che richieda un investimento consistente.
In ogni caso, non esistono Business Case sicuri, e non poteva esserlo nemmeno quello della nuova DIABLO™. Ma facemmo del nostro meglio per abbassare il rischio ipotizzando:
- una stima di costo cautelativa di un set di attività prestabilite e assolutamente indispensabili allo scopo → poco spazio per gli “unknown unknowns”
- trend misurabili → p.e. una crescita lineare in termini di acquisizione già osservata in anni precedenti.
Qualche mese dopo, a fine 2021, la leadership Pirelli reputò viable l’iniziativa, complice una strategia che convinse, e ne approvò l’investimento.
Livello sbloccato; si (ri)parte! 🚀
Step#6: nuova discovery e testing dei prototipi
Era passato un po’ di tempo tra la prima fase di discovery — che ci permise di definire un MLP feasible, viable e potenzialmente valuable — e l’avvio del progetto, perciò decidemmo di percorrere una fase preliminare di Understanding in cui:
- aggiornare le evidenze pregresse sul mercato di riferimento
- definire Value Proposition e UX/UI dell’MLP
- condurre i test di usabilità dei prototipi
In pratica, si trattò di una nuova iterazione di discovery, volta ad abbassare ulteriormente il rischio di valore (value risk) e, soprattutto, minimizzare quello di usabilità (usability risk).
Aggiornamento evidenze sul mercato di riferimento
Con l’aiuto di brillanti UX Researchers e guidati dai colleghi esperti di Product e Service Design, il primo passo fu quello di effettuare una nuova analisi del mercato delle app per motociclisti, allo scopo di raccogliere evidenze fresche sull’attuale offerta. In particolare, ci focalizzammo sulle funzionalità incluse nel nostro MLP, ed effettuammo un approfondito benchmark study che ci permise di affinare i jobs to be done.
Per confermare che i bisogni individuati fossero reali, e individuarne di altri, il passo successivo fu la conduzione di alcune interviste sia ad attuali che a potenziali utenti. Questo passaggio ci permise di definire le User Personas a cui avremmo potuto rivolgerci e, complici dei risultati incoraggianti, di abbassare ulteriormente il rischio valore del nostro MLP.
Value Proposition e UX/UI
Prima regola del Product Management: non possiamo accontentare tutti. Ecco perché, tra le User Personas definite, decidemmo di focalizzarci su una in particolare — ovvero quella per cui abbiamo riscontrato minor offerta sul mercato.
Per quanto possa sembrare una scelta scontata, in realtà, rappresentò un rischio che decidemmo di prenderci, perché si tratta(va) di un segmento di mercato abbastanza di nicchia, dal quale avremmo poi scalato con difficoltà. Ma varie ragioni — tra cui un’eredità Pirelli legata al mondo delle prestazioni e delle corse — ci rassicurarono sul fatto che era questa la nicchia che avremmo servito al meglio, e che avrebbe potuto contraccambiare con nostra maggiore soddisfazione.
Fissata bene in testa la Persona a cui rivolgerci, definimmo da lì a poco la nostra Unique Value Proposition e, coerentemente, lo “scheletro” dell’MLP:
- l’architettura informativa
- i primi high-fidelity wireframe di UX/UI
Quella che era poco più di un’idea iniziava ora a prendere forma. Dopo un paio di iterazioni sui wireframe, necessarie per raccogliere i primi feedback dagli stakeholder interni, in particolare dal team Legal, eravamo pronti a fare un passo avanti.
A tal proposito, e guardando a esperienze simili pregresse, sebbene possa sembrare azzardato partire direttamente con wireframe ad alta fedeltà, il vantaggio in termini di comprensione reciproca che si ottiene presentando ai colleghi di Compliance una UI quasi definitiva, invece di bozze a bassa fedeltà, giustifica pienamente l’azzardo.
Quel passo avanti, consisteva nella “rifinitura del trucco” al nostro quasi-prototipo in vista del “primo appuntamento” con dei veri centauri. 🏍️
Test di usabilità dei prototipi
Il passo da wireframe high fidelity a prototipo usabile — completo delle principali interazioni tra le schermate — fu breve. Dopo aver finalizzato anche il Tone of Voice dei testi, giunse il momento di consegnare il nostro prototipo nelle mani dei motociclisti per minimizzare il rischio di usabilità.
A tal scopo, ci affidammo ad una community di crowdtesting da cui selezionammo dei tester in linea con il nostro target, ed organizzammo due tipologie di test di usabilità:
- Thinking Aloud — tecnica che richiede all’utente di esprimere ad alta voce quali siano i suoi pensieri, le sue azioni, le sue intenzioni e le difficoltà incontrate durante l’interazione col prodotto → per catturare un feedback in tempo reale
- Questionario utente → per catturare un feedback post-utilizzo
L’incrocio dei risultati di entrambi i test qualitativi ci fornì molti spunti di miglioramento sia per la UX che per la UI, nonché l’outfit v.1.0 col quale la nuova DIABLO™ si sarebbe ufficialmente presentata al mondo da lì a poco.
Step#7: formalizzazione e monitoraggio obiettivi tramite OKRs
Ricordate? Uno dei cambiamenti fondamentali per implementare con successo il Product model — e quindi massimizzare il ritorno d’investimento tecnologico — riguarda il modo in cui decidiamo quali problemi risolvere.
In questo contesto, il ruolo del leone è interpretato non solo da una visione/missione che ispiri, ma anche da una strategia che determini inequivocabilmente quali opportunità perseguire. Avevamo dato forma ad entrambe le entità, ma ora come potevamo esser sicuri di star perseguendo le giuste opportunità — e dunque dell’efficacia della nostra strategia nel guidarci verso il raggiungimento della nostra missione?
Era indispensabile tracciare le conquiste intermedie. In altre parole, avevamo bisogno di misurare il successo nel breve termine attraverso la definizione di obiettivi quanto più S.M.A.R.T. — Specific, Measurable, Achievable, Reachable and Time bound — possibile.
A proposito di obiettivi, quello che mi ero personalmente prefissato in questo progetto era che qualsiasi sviluppo dovesse adempiere solo ed esclusivamente a uno scopo comprovato e misurabile — ovvero generare outcome. Ancor più che l’output, ovvero un prodotto di valore per gli utenti e per l’azienda, ciò che mi stava veramente a cuore era l’outcome: volevo osservare un cambiamento nel comportamento delle persone che vi avrebbero lavorato. Volevo che un cambio di mentalità fosse esso stesso il prodotto… del prodotto.
Ecco perché non bastava definire e condividere obiettivi S.M.A.R.T., ma era necessario integrarli di una forte componente ispirazionale. E per cercare di mettere a fattor comune entrambe le esigenze, proposi di formalizzare quelli della DIABLO™-che-verrà attraverso il framework OKRs:
- un Objective deve essere significante, concreto, chiaramente definito e ispirazionale → appunto, la componente più ispirazionale
- un Key Result è un criterio di successo misurabile utilizzato per monitorare il raggiungimento dell’obiettivo → la componente più S.M.A.R.T.
A proposito della “T” di Time bound, optammo ancora per la semplicità e formalizzammo degli OKRs annuali considerando che:
- i KPIs utilizzati nel Business Case erano annuali → si traducevano immediatamente in KRs annuali, con l’ulteriore vantaggio di creare una connessione diretta tra product goals e business goals
- l’app ha una connotazione stagionale → usata principalmente per le uscite in moto durante le stagioni calde dell’emisfero boreale
- l’app è totalmente gratuita → non era necessario monitorare metriche di (recurring) revenue
Definimmo tre Objectives, ciascuno dei quali composto da uno o due Key Results, e con cui ambivamo a garantire totale aderenza alla nostra strategia:
- “Rebuild a highly-satisfied and engaged user base” → “Costruiamo un MVP bulletproof con cui re-ingaggiare i nostri utenti → dopo averli re-ingaggiati, iniziamo a far evolvere l’MVP con piccoli add-on di valore”
- “Build a high-quality CRM” → “mentre il prodotto cresce organicamente risolvendo con soddisfazione i reali problemi degli utenti, generiamo leads”
- “Boost product placement” → “iniziamo a segmentare al meglio i nostri utenti e facciamo leva sulle nuove tecnologie impiegate per veicolare promo marketing altamente mirate”
In ultimo, ma non per importanza, gli OKRs sono in grado di garantire totale trasparenza, allineamento, collaborazione e condivisione (tutti princìpi cardine del Product model). A tal proposito, e per monitorarli, concordammo un incontro mensile post-lancio a cui avrebbero partecipato tutti i principali stakeholder.
Con in testa dei chiari obiettivi di breve termine, il team Tech poteva finalmente dedicarsi a quel che più li entusiasmasse: costruire un prodotto a regola d’arte. 🛠️
Step#8: delivery dell’MLP
Anzi no, mancava ancora qualcosa.
Nel nostro modello operativo Project misto IT, erano necessari ancora un paio di passaggi prima di poter passare alla fase di sviluppo.
Abbiamo già detto come finanziamento e staffing in questi modelli avvengano sulla base di un progetto da portare a termine, e questa iniziativa — anche se volta al rifacimento di un intero prodotto — costituiva in fin dei conti un progetto.
Quindi, ottenuto il finanziamento, procedemmo con:
- lo staffing di progetto → nonostante avessimo almeno una persona per competenza cross-funzionale, ci serviva ancora una mano “dall’esterno”
- il piano di progetto → per dare un ordine temporale ai principali rilasci interni e alle milestone successive
A proposito del piano, ne definimmo uno in tre macro-fasi:
- Sviluppo Agile dell’MLP
- Lancio incrementale dell’MLP
- Pianificazione delle funzionalità successive
e che riportava, per ogni attività di ciascuna fase, la presunta data fine lavori.
1. Sviluppo Agile dell’MLP
Durante questa prima macro-fase, l’obiettivo era plasmare in maniera incrementale e condivisa il nostro MLP. Dal punto di vista del processo di sviluppo, abbiamo continuato ad adottare una versione “Pirelli-adapted” del framework Agile SCRUM, caratterizzata dalle seguenti peculiarità:
- Sprint della durata di due settimane, con l’obiettivo di rilasciare almeno un incremento significativo — cioè che avesse senso “mostrare” — del prodotto
- Cerimonie e riunioni ridotte al minimo indispensabile, mantenendo però l’incontro di Sprint Review per condividere con tutti gli stakeholder i vari incrementi di prodotto.
La vera peculiarità di questa fase, tuttavia, fu l’opportunità che il team Tech ebbe di sperimentare una serie di soluzioni tecnologiche — framework e servizi cloud di ultima generazione — del tutto inedite in Pirelli, confermando come:
“The little secret in product is that engineers are typically the best single source of innovation.”
— Marty Cagan
Questa fase di sviluppo e test dell’MLP durò circa 5 mesi, e terminò a fine settembre 2022. Eravamo ad un passo dal lancio della nuova app! 🚀
2. Lancio incrementale dell’MLP
Messa a punto col team Marketing la strategia di Go-To-Market, e dopo due settimane di intensi test “family&friends” che ci permisero di lavorare i primi — utilissimi — feedback, era tutto pronto alla pubblicazione dell’aggiornamento v.7.0.0 dell’app DIABLO™ Super Biker.
Ma non per tutti, quantomeno non subito.
Considerando l’entità del cambiamento — a dir poco “radicale” — optammo per un rilascio incrementale secondo parametri di territorialità, e il 13 ottobre 2022, l’Italia fu il primo paese a poter scaricare la nuova app.
Complice la bassa stagionalità, una sostenibile mole di dati qualitativi e quantitativi raccolta nelle settimane successive ci permise di effettuare le prime iterazioni sull’MLP, stabilizzandolo in vista del prossimo lancio sugli altri paesi.
Inoltre, il lasso di tempo in cui l’app era disponibile solamente in Italia, ci permise di gestire la localizzazione del piano di Go-To-Market. Difatti, app e comunicazioni sono tradotte in otto lingue, oltre all’italiano.
Il processo di rilascio incrementale durò circa 2 mesi, e terminò il 5 dicembre 2022, data in cui l’MLP “iterato” era ormai disponibile in tutti i paesi.
3. Pianificazione delle funzionalità successive
La fase di discovery allo Step#6 ci aveva lasciato in eredità alcune evidenze forti, che si tradussero nei primi potenziali “add-on di valore”, tema della seconda “conquista” della nostra strategia.
Con una genuina volontà di rimanervi fedeli, e di aumentare quanto prima il valore percepito dagli utenti, la terza e ultima fase del nostro piano di progetto prevedeva il rilascio — in date prestabilite — di un paio di nuove funzionalità.
Le intenzioni erano buone, l’esecuzione legata alle date un po’ meno. Perché…
***SPOILER ALERT***
ci apprestavamo a operare in modalità “feature factory”
non avevamo opportunamente considerato l’eventualità di dover iterare sul nostro MLP.
Ma d’altra parte, Roma non è stata costruita in un sol giorno… stavamo imparando attraverso il “fare”.
E se siete curiosi di sapere come andò a finire, compiete un altro “step”!
Step#9: da roadmap “date-bound | output-driven” a “period-bound | outcome-driven”
Alla stregua del tema MVP, anche quello delle roadmap è sempre molto caldo. Basta tornare su di qualche riga per rileggere le considerazioni pungenti di Marty Cagan a tal proposito. E anche in questa storia, l’argomento non ha lesinato dibattiti.
Erano passati circa cento giorni dal lancio della nuova app su tutto il mondo, ed iniziavamo a vedere i primi incoraggianti progressi dei nostri Key Results.
Nonostante ciò, gli stakeholder ci chiedevano costanti aggiornamenti sulle funzionalità aggiuntive che avevamo ipotizzato ad avvio progetto, e che erano state pianificate in versioni immediatamente successive a quella del lancio della nuova app.
Come mai?
Perché in un modello operativo misto Project e IT, tutto — compreso il concetto di successo — ruota attorno alla realizzazione di progetti e/o funzionalità entro determinate date. E se consideriamo che, durante tutta la fase di sviluppo della nuova app, avevamo sempre condiviso un piano con delle date attese di rilascio dei vari incrementi, dovevamo aspettarci che servissero buone argomentazioni per trasmettere l’importanza di spostare il focus dagli output agli outcome.
Per riuscirci, decidemmo di avvalerci della migliore delle argomentazioni: ovvero dei dati, letti dal punto di vista della nostra strategia.
I primi 100 giorni dal lancio, difatti, non furono una passeggiata. Svariate fonti qualitative e quantitative — analytics, recensioni e richieste di supporto — stavano suggerendo necessità diverse da quelle che le funzionalità “a piano” avrebbero soddisfatto. E quelle necessità dovevano essere trattate con la massima priorità, perché erano direttamente riconducibili alla prima “conquista” che la nostra strategia ci imponeva di fare: garantire un prodotto sì “minimal”, ma impeccabile.
D’altra parte, avevamo rilasciato una forma evoluta di MVP, e in quanto tale, ebbe bisogno di ulteriori iterazioni prima di generare il valore di business atteso.
Dunque, per restare veramente fedeli alla nostra strategia, dovevamo posticipare qualsiasi altro incremento di prodotto che divergesse da questo scopo, perché tema della conquista successiva.
Grazie a un’adeguata presentazione dei dati, riuscimmo a dimostrare come:
- i “primi incoraggianti progressi dei nostri Key Results” altro non fossero che un’inversione di tendenza innescata dalle azioni correttive intraprese in sostituzione delle funzionalità “a piano”
- i risultati — e non le funzionalità — siano ciò che veramente conta per avere impatto positivo sul business.
Da lì in poi, fu più facile passare da un formato di roadmap “date-bound | output-driven” — espresse come una lista prioritizzata di funzionalità da rilasciare entro una certa data — ad uno “period-bound | outcome-driven” — fatta in questo modo:
Nella colonna Objective sono elencati i nostri OKRs annuali, per non perderli mai di vista, mentre nelle colonne
- NOW → alta priorità, termine ~1 mese
- NEXT → media priorità, termine ~3 mesi
- LATER → bassa priorità, termine > 3 mesi
tutte le iniziative — sia discovery che delivery — su cui sta(rà) lavorando il team di prodotto, e che potranno “spingere” su uno o più OKRs. Questa roadmap viene aggiornata quando necessario, a seconda delle evidenze raccolte, e condivisa per conferma con tutti gli stakeholder durante l’incontro mensile di monitoraggio degli OKRs discusso poco sopra.
Ovviamente, ciò non significa che le date siano inutili. Per quanto sia più appropriato parlare di “high integrity commitment”, le date continuano ad essere importanti per:
- sincronizzare qualsiasi interdipendenza funzionale con altri team, soprattutto in società ampie e strutturate come Pirelli
- definire la strategia di Go-To-Market, per pianificare la comunicazione interna ed esterna
E in questo caso, quando necessario, almeno per le iniziative in colonna NOW abbiamo sempre fatto del nostro meglio per rispettarle.
Questo passo avanti costituì forse il più grande tra quelli compiuti in questo percorso di trasformazione, perché, lasciandoci alle spalle l’emblema dell’inefficienza del modello operativo di partenza, iniziammo a cambiare veramente il modo in cui avremmo risolto i problemi.
Il focus di tutti si era finalmente spostato dal Time To Market al Time To Money.
Step#10: Continuous Discovery e continuous evangelization
Per cambiare il modo in cui risolvere i problemi, bisogna innanzitutto saper individuare i problemi giusti da risolvere.
A tal scopo, diventano imprescindibili altri due concetti — oltre al già discusso team empowered — che stanno alla base del Product model:
- una strategia definita a partire dalla profonda conoscenza del “campo di battaglia” — ovvero del mercato di riferimento
- un appropriato processo di Product Discovery col quale validare che un problema sia reale per gli utenti, e che sia possibile risolverlo con soluzioni tecnologiche fattibili, di valore, usabili e sostenibili per il business.
Avevamo già plasmato il primo concetto, ora avevamo bisogno di mettere a terra il secondo.
Lo ammetto: tra tutti gli sforzi profusi lungo questo percorso, quello per istituire un processo strutturato di costante discovery è stato (e continua ad essere) il maggiore. O quantomeno, quello per cui mi ritrovo più spesso a chiedermi:
“Ma staremo procedendo nel modo corretto?”
Soprattutto considerando che, in questa storia di trasformazione, eravamo noi il team “faro” — portavoce di un nuovo modello concettuale — che altro non poteva fare se non sperimentare quanto appreso dalla teoria.
Ma d’altra parte, non c’è modo migliore di imparare se non applicando — anche rischiando di sbagliare — quanto studiato. Ce lo hanno sempre detto fin da bambini: sbagliando, s’impara.
A maggior ragione se la risposta alla mia frequente domanda sembra essere che non esista un unico modo corretto di costruire i prodotti:
“It’s important to emphasize that there is no single right way to build products. […] But for now, know that there are many good ways, much as there are an even larger number of bad ways.”
— Marty Cagan
Quindi, per quanto riguarda la discovery, mi impegnai a definire un approccio “che potesse funzionare”, ovvero che ci permettesse continuamente di:
- raccogliere i feedback — problemi e desideri — degli utenti
- sperimentare le nostre soluzioni prima di svilupparle
- validare le nostre assunzioni e ipotesi.
La nostra Continuous Discovery
Qualche riga più in su abbiamo già affrontato il tema della discovery iniziale della nuova app.
Tuttavia, questa non era un’attività che potevamo relegare esclusivamente alla fase iniziale. Stavamo costruendo un prodotto digitale che non dovrebbe mai essere considerato finito, ma adattarsi continuamente:
- ai bisogni degli utenti
- ai cambiamenti del mercato
- al sopraggiungere di nuove tecnologie
A maggior ragione se volevamo rispettare la seconda istruzione della nostra strategia:
→ dopo averli re-ingaggiati, iniziamo a far evolvere l’MVP con piccoli add-on di valore →
Per garantire il valore, era necessario mantenere un canale costantemente aperto coi nostri motociclisti e col mercato.
In pratica, dovevamo stabilire un processo di “Continuous Discovery”.
Secondo la definizione più recente di “Continuous Discovery”, resa celebre dall’illuminante lavoro divulgativo di Teresa Torres, il team di prodotto — composto come minimo dal “trio” Product Manager, Product Designer e Software Engineer — deve parlare coi propri utenti almeno una volta a settimana:
“At a minimum, weekly touchpoints with customers
By the team building the product
Where they conduct small research activities
In pursuit of a desired outcome”— Teresa Torres
E da dove partimmo?
Dal vestire (anche) i panni del Customer Success!
Sebbene l’app sia completamente gratuita, non potevamo trascurare le necessità di supporto, soprattutto considerando il nostro approccio assolutamente incentrato sulla massima soddisfazione degli utenti.
Ed è incredibile quante opportunità possano nascere presidiando questo canale.
Innanzitutto, quella di trasmettere la nostra passione direttamente ai motociclisti, cercando genuinamente di risolvere i loro problemi. Ciò è qualcosa che ci sta particolarmente a cuore, perché vogliamo che il nostro prodotto regali un’esperienza appagante prima, durante e soprattutto dopo il suo utilizzo. Ad oggi, possiamo affermare con estremo orgoglio di non aver lasciato senza risposta alcuna:
- nuova recensione negli store
- proposta di nuove funzionalità
- richiesta di assistenza o informazioni.
Ed è proprio da questa ossessione verso l’utente che nasce la seconda opportunità. Quella di arruolare i più appassionati per:
- condurre Alpha, Beta e usability test
- intervistarli al telefono o in videoconferenza
- approfondire offline il “perché” delle loro segnalazioni
Non avendo un team di Customer Success preposto, il nostro è un approccio alla Continuous Discovery sicuramente “intenso”, sostenibile finché non raggiungeremo determinati volumi. Non sapremo mai se è un approccio “giusto” o “sbagliato”, ma ad oggi sappiamo che sta funzionando.
D’altra parte, scopo della Continuous Discovery è proprio quello di far evolvere costantemente il prodotto al mutare del contesto in cui è proposto. E se non può esistere prodotto senza discovery, non è forse tra gli obiettivi della stessa anche quello di evolvere… essa stessa?
Continuous Evangelization
Allo Step#7, quando abbiamo parlato di OKRs della nuova app, avevo accennato anche al mio obiettivo personale di indurre un cambiamento di mentalità nelle persone che vi avrebbero lavorato.
Per raggiungere questo obiettivo, non sarebbero bastate sporadiche conquiste ottenute principalmente durante la fase iniziale del ciclo di vita del prodotto:
- Definizione collaborativa di missione e strategia
- Workshop “Lean Startup” per progettare un MVP
- Formalizzazione e monitoraggio degli OKRs annuali
- Passaggio a roadmap “period-bound | outcome-driven”
- Istituzione di un nostro processo di Continuous Discovery
ma, alla stregua di quest’ultima, erano opportune delle attività continuative di evangelizzazione dei concetti tipici del Product Operating Model, e dei risultati grazie a esso ottenuti.
A tal scopo, non esistono pratiche universalmente efficaci. Oltre a provare ad importare — previa accurata analisi del contesto dello Step#2 — le best practices in ogni prodotto o progetto in cui si è coinvolti, si può parlarne durante una pausa caffè, coinvolgere quanti più colleghi possibile a vari eventi sul Product Management, o consigliare fonti informative sull’argomento.
Nel mio caso, ho avuto l’opportunità di raccontare a due diversi team Digital, in momenti dedicati, i vari princìpi fondamentali di una gestione olistica di prodotti digitali, calandoli — esattamente come in questo articolo — nel contesto del rifacimento della nuova app DIABLO™ Super Biker.
Conclusioni
Se siete arrivati a leggere fino a qui, vi starete certamente chiedendo:
“Ok, tutto molto bello. Ma che risultati avete ottenuto?”
Senza ulteriori indugi, ecco alcune statistiche della nuova app aggiornate a Dicembre 2023, dopo un anno di attività su (quasi) tutto il mondo:
- Valutazione media dal primo lancio dell’app
- iOS: da 3,9/5 a 4,3/5 → superato nettamente il Key Result
- Android: da 3,4/5 a 4,0/5 → centrato il Key Result
- Customer SATisfaction: 8,1/10
- Acquisition: +57% → superato nettamente il Key Result
- Engagement: +35% → centrato il Key Result
Può essere considerato un caso di successo?
Dal punto di vista degli utenti
Esperimento riuscito. Gli utenti hanno percepito quanto sia importante per noi la loro soddisfazione e continuano a menzionare “esperienza d’uso” e “supporto” come fattori distintivi del prodotto:
Riporli “al centro” era la nostra principale ambizione, perciò siamo molto fieri del risultato, oltre che stimolati a fare sempre meglio.
Dal punto di vista degli stakeholder
Decisamente. Secondo i colleghi del Marketing della BU Moto, “la passione e la dedizione con cui avete affrontato questa iniziativa rappresenta un caso di successo di cui bisogna parlare”. Detto → fatto.
Mentre, secondo i colleghi Tech e Design, questo progetto “è stato quello su cui abbiamo lavorato meglio, e quello che ci sta regalando le maggiori soddisfazioni. Soprattutto perché abbiamo potuto sperimentare soluzioni tecnologiche inedite per risolvere problemi reali degli utenti”. Pensate che una delle principali migliorie introdotte lo scorso anno è frutto di un hackathon organizzato dal team Tech.
Infine, anche la leadership Pirelli ha notato le potenzialità sbloccate dalla nuova DIABLO™, al punto che l’app ha recentemente ottenuto un innalzamento di priorità e attenzione tra le iniziative digitali del Gruppo. Ulteriore indizio di come una trasformazione bottom-up sia possibile.
“Nulla si crea, nulla si distrugge, ma tutto si trasforma”
Anche le organizzazioni.
Che questo (ancor piccolo e in continua evoluzione) caso di successo possa contribuire a un’imprescindibile e completa trasformazione digitale per Pirelli, ed essere d’ispirazione per chiunque riconosca la stessa necessità nella propria azienda ma non sappia da dove iniziare.
