Product Mindset: oltre il Top-down e verso il Product Thinking

“Ci sono 2 motivi per intraprendere una trasformazione.  
Uno, vogliamo ridurre il rischio. E il rischio è principalmente quello di costruire la cosa sbagliata sprecando tempo e denaro.  
Due, vogliamo aumentare la profittabilità dell’azienda”. 

All’interno delle organizzazioni, la differenza tra l’approccio “Top-down” e il product thinking è sempre più marcata. Negli ultimi anni, l’adozione di nuovi framework, metodologie e tecniche ha accelerato notevolmente lo sviluppo dei prodotti. Tuttavia, questo progresso potrebbe portare le aziende a diventare semplici “feature factory”? Ne abbiamo parlato con Valerio Zanini, innovatore nel Product Management e Leader Digitale. 

Valerio, iniziamo dal principio: da dove nasce la tua passione per il Product Management? 

Questa è una domanda interessante! Ci sono 2 motivi. Numero uno, mi è sempre piaciuto costruire cose, sin da quando ero bambino. Un giorno, i miei genitori mi comprarono un computer – all’epoca qualcosa di fantastico! – il Commodore VIC-20.  

Invece di usarlo per giocarci, cominciai subito a programmare. Ricordo che sviluppai un primo programma per la gestione dei contatti personali. Gli diedi un nome e trovai un nome anche alla “Company” che stavo creando per gestire quel programma. Avevo 11 anni e già pensavo: “Adesso lo vendo, vado in business!”. 

Il secondo motivo è la mia formazione in ingegneria elettronica e computer engineering. So come costruire prodotti software, e mi è sempre piaciuto stare all’intersezione tra questi due mondi: il mondo del “business” – pensare a cosa fare, a cosa può essere utile; e il mondo “tecnico” – e quello del decidere come farlo. 

Ed è tra mondo tecnico e mondo del business che si svolge il lavoro del Product Manager. 

Insomma, un Product Manager ante litteram sin da giovane. 

Beh, ma con i miei successi e fallimenti! 

E i fallimenti sono sempre un’opportunità di apprendimento. Per esempio, ho lavorato per una società cresciuta tantissimo nei primi anni 2000 che gestiva un servizio di e-commerce. Un mercato nuovo con un servizio innovativo. Vendevano dati e ricerche di mercato. 

Verso il 2008-2009, però, quando c’è stata l’innovazione del mobile phone con il conseguente accesso massivo a tutti i search engine, il mercato è cambiato. E quando sono entrato io all’inizio del 2011, l’azienda stava già andando male.  

Abbiamo speso tantissimo tempo e energie. 

Ero Direttore Tecnico – quindi gestivo la parte di sviluppo del prodotto – ma siccome non c’era una figura di Product Manager in azienda, di fatto, le scelte di cosa fare e non fare con il prodotto erano mie e del mio team. 

E noi abbiamo affrontato – anzi io ho scelto di affrontare – il lavoro principalmente basandoci sulle feature da fare. 

Abbiamo cominciato a lavorare sul codice, ci siamo chiesti: “come facciamo a migliorare le prestazioni del nostro website?” 

Abbiamo guardato le singole web pages e abbiamo cercato di capire quale fosse il funnel che un nuovo customer avrebbe dovuto attraversare. Abbiamo intrapreso un grosso progetto di ristrutturazione di tutto il website, anche per accomodare il marketing che si appoggiava principalmente su Search Engine Optimization; quindi, l’ottimizzazione che consente alla nostra pagina di posizionarsi tra i primi risultati nei motori di ricerca, quando viene cercata una parola chiave correlata al nostro sito. 

Dopo mesi e mesi di lavoro siamo riusciti a lanciare questa nuova versione sul mercato.  

Immediatamente abbiamo riscontrato un +20% di traffico sul sito (page views) e un +25% di registrazioni.  

Il problema fu che, un mese dopo, quando uscì il Report del Fatturato, scoprimmo che continuavamo ad andare giù. Lì ho realizzato: le metriche che stavamo misurando noi – il traffico, il numero di registrazioni, le page views … – non erano “Value Metrics” ma “Vanity Metrics”, perché l’incremento di queste non portò nessun valore né per i customers né per il business. 

Ai nostri customers non gliene importava nulla del numero di page views e del numero di registrazioni che stavamo raccogliendo, e al nostro business questo traffico portò un risultato opposto, perché incrementare il traffico sul sito aveva significato incrementare il traffico sui server. Quindi avevamo avuto necessità di server addizionali, ci occorreva maggiore bandwidth, ovvero la capacità del team di gestire il lavoro, e questo determinò un incremento di costi – e comunque il fatturato continuava a scendere. 

In pratica abbiamo fatto mesi e mesi di lavoro per diminuire la profittabilità della nostra azienda! 

È stato quindi un momento difficile. 

Sì, e lì mi si è accesa una lampadina. Ho realizzato: “Ok, abbiamo fatto tutte queste scelte sulla base di quello che noi pensavamo fosse giusto, ma in realtà non abbiamo nessuna idea di quello che serve ai nostri customer”. 

Perché nessuno di noi era andato a parlare con i customer? 

Perché non siamo andati a cercare di capire come mai le persone si registravano ma poi non acquistavano? 

Quindi sono andato dal CEO e gli ho chiesto: “Posso avere una lista dei nostri clienti su Washington DC? Vorrei fare qualche intervista”. 

Il CEO mi disse “No: noi non parliamo con i customers. Abbiamo investito un sacco di soldi in analytics: vai e guarda i dati”. 

Ma io i dati li conoscevo bene. I dati ti dicono cosa sta succedendo, ma non ti dicono perché. E a me serviva sapere il perché. 

Cosa successe poi? 

Non riuscii ad avere apertura. E quello fu un blocco sia perché non potevo aiutare per risolvere il problema, sia per me come professionista.  

Cambiai azienda e andai a lavorare in una grande banca qui negli Stati Uniti dove trovai l’opposto. In una delle prime settimane di lavoro, il mio manager mi disse: “Valerio, vai fuori dall’ufficio e parla con i customers”. 

Da lì misi in moto tutta una serie di attività coinvolgendo anche il mio Team per fare in modo che almeno una volta a settimana fossimo fuori dall’ufficio. 

Era un momento in cui la banca stava attraversando una trasformazione agile, e tutti noi cercavamo di imparare di più sull’approccio. 

Studiavamo tecniche varie: si parlava tanto per esempio del libro “Lean Startup” di Eric Ries che era diventata un po’ la nostra Bibbia. 

In quel periodo, per le banche, l’innovazione digitale dentro le filiali era ancora un territorio da esplorare e, per questo, stavamo costantemente fuori a fare interviste e lavoro di Discovery per raccogliere informazioni riguardo ai bisogni degli utenti finali. 

Grazie a questo, un anno dopo, il mio Team lanciò un servizio per Tablet – e fummo i primi in America a farlo! – creando una serie di applicazioni che permettevano a customer e consulente bancario di lavorare insieme per facilitare la scelta dei prodotti finanziari da acquistare. 

Quindi questa banca aveva un modo completamente diverso di concepire la creazione di prodotti, rispetto all’azienda di e-commerce che ci hai raccontato prima.  

Sì, si può vedere chiaramente il contrasto di un’organizzazione che pensa ai prodotti in maniera “Top-Down” (N.d.A. nell’ approccio top-down le attività vengono individuate dagli stakeholders e calate al team di prodotto per la realizzazione.) versus una che fa effettivamente “Product Thinking” (N.d.A. caratterizzato da un approccio incentrato sull’outcome che si vuole realizzare tramite il prodotto). 

Oggi sono ormai quasi 7 anni che lavoro come Consultant indipendente e purtroppo continuo ancora a vedere questa differenza – in aziende piccole o grandi che siano. 

E in qualche modo lo scenario oggi sembra addirittura peggiorato. 

Davvero? Perché? 

Negli ultimi 10-15 anni sono nati tanti framework, metodologie e tecniche per sviluppare. Si parla sempre di come sviluppare più velocemente e di come andare sul mercato il prima possibile. 

Ma tutto questo mette i Team a rischio di diventare delle Feature Factory (N.d.A Fabbrica di feature, dove il focus è sulla produzione di output piuttosto che sui benefici che questo produce). 

Quindi, paradossalmente, la facilità con cui riusciamo a produrre software oggi ci sta portando a ragionare ai prodotti in modo Top-down?  

E non solo. Poi cosa succede: le aziende devono implementare sistemi di Performance Review per i propri dipendenti. 

Lì il tipico obiettivo assegnato a Product Manager e Product Owner diventa il numero di features (N.d.A Funzionalità specifiche che richiedono alcune settimane di lavoro) che hanno lanciato o quanto in fretta hanno lanciato una nuova feature. 

Tutte misure di output e questo può essere addirittura enfatizzato in sistemi scalati. 

In questo modo, questi Team diventano “schiavi” del compito di creare output, e cadono dentro il “Delivery Gap” – ciò che succede quando un Team costruisce un prodotto (output) e questo prodotto non fornisce i risultati attesi dai customers o dal business (outcome). 

E questo “scivolare” verso l’approccio Top-Down secondo te dipende in prima battuta più dai Framework o, semplicemente, più dalla maggiore facilità di misurare gli Output rispetto agli Outcome? 

Dipende da entrambi. Da un lato, l’abbiamo già accennato: framework e tool ci facilitano a produrre output. Dall’altro è anche più facile misurare l’output.  

Misurare gli outcome invece è difficile.  

Per questo, istintivamente, siamo portati a pensare: “è più facile produrre gli output, quindi pensiamo agli output”.   Ma in questo modo non riusciamo veramente a trasformare il modo di pensare e di operare delle aziende. E attenzione: quando parliamo di trasformazione non parliamo di qualcosa che facciamo perché “ci piace farlo”.  

Ci sono 2 motivi per intraprendere una trasformazione. Uno, vogliamo ridurre il rischio. E il rischio è principalmente quello di costruire la cosa sbagliata sprecando tempo e denaro. Due, vogliamo aumentare la profittabilità dell’azienda. 

Per questo motivo, se io spendo – anche se poco – a costruire tante feature ma quelle feature non producono alcun valore, noi abbiamo comunque sprecato risorse, invece di utilizzarle per realizzare qualcosa di valore. 

E comprendere questo richiede una trasformazione nel modo di pensare – quindi prima di tutto nel mindset – e solo poi sulle pratiche che possiamo adottare per implementarlo. 

Questo cambiamento nel mindset è quello che io chiamo “Product Thinking”. 

E per un’azienda che sta iniziando ad affacciarsi a questo modo di pensare cosa consigli? 

Un cambio di approccio richiede innanzitutto un cambio di dinamiche.  

Si dovrebbe iniziare ad approcciare la creazione di prodotti in maniera leggera, creando dei Product Team molto snelli. Non facendo, quindi, un “big up-front plan”, definendo tutti i requisiti a monte e creando budget per costruire una “specifica cosa”. 

Occorre chiedersi sin da subito: quale problema vogliamo risolvere? E soprattutto, qual è il problema giusto da risolvere? E quale può essere la soluzione giusta per questo problema? 

Dobbiamo partire da delle domande – ovvero da ipotesi. 

Quando noi consideriamo i requisiti, appunto, come “requisiti”, questi diventano cose che dobbiamo fare. E a quel punto possiamo solo implementare e fare Delivery. 

Siamo più lenti all’inizio perché dobbiamo validare alcune ipotesi, ma nel momento in cui troviamo conferma acceleriamo. Ma non acceleriamo tanto nella delivery di output, quanto nella delivery di valore ai nostri customers e al nostro business. 

Il primo passo verso il “Product Thinking” quindi è prendere consapevolezza sulla natura “ipotetica” delle soluzioni che costruiamo. Come aiuti le persone ad assorbire questo concetto?  

Se il lavoro è predefinito, l’end-state, cioè il risultato finale desiderato è chiaro e sappiamo cos’è che dobbiamo fare per arrivare dove vogliamo – magari perché l’abbiamo già fatto in precedenza, o abbiamo lavorato con quegli stessi customers altre 10 volte in passato e conosciamo a memoria chi sono, cosa vogliono e di cosa hanno bisogno – allora abbiamo pochi “unknown”. Il nostro lavoro di fatto si riduce a “build and deliver”. 

In questi casi, a monte possiamo tranquillamente definire budget e creare piani dettagliati. Non c’è problema. 

Il problema invece nasce quando facciamo “New” Product Development. Quando cerchiamo di costruire qualcosa che è nuovo, che non è mai stato fatto in precedenza. Magari perché i customers sono nuovi – o la tecnologia, il mercato. In questi casi siamo esposti a tanta ambiguità e incertezza. 

Affrontare questo tipo di lavoro utilizzando un approccio top-down è un rischio enorme. Ci sono tantissime cose che noi pensiamo di sapere ma che davanti hanno un grandissimo punto interrogativo. E finché non rispondiamo a queste domande noi davvero non possiamo sapere cosa costruire. 

Ti viene in mente un esempio che hai vissuto? 

Qualche anno fa lavoravo con una Fortune500 company (N.d.A la celebre rivista economica Fortune stipula annualmente una classifica con le prime 500 aziende statunitensi per fatturato) che voleva costruire una nuova applicazione per gestire tutta la parte ERP, ovvero il sistema integrato che permette di gestire la pianificazione delle risorse d’impresa, all’interno dell’azienda. 

Avevano approcciato questa iniziativa come un “Big project”. Quindi avevano iniziato con 6 mesi di solo planning per creare una lista con tutti i requisiti che avrebbero dovuto implementare i Team.  

3000 features tutte incluse all’interno di un file Excel. 

A quel punto, mi chiamarono e mi dissero: “non sappiamo da dove iniziare!”. 

Non ho fatto fatica a crederci! Dove puoi iniziare con un Product Backlog di 3000 items? Come puoi anche solo semplicemente prioritizzarlo? 

Perciò il mio suggerimento è stato: “Delete the file and let’s start over” (N.d.A.: cancellate il file e ricominciamo da capo). 

A quel punto, abbiamo creato un piccolo Team di Key Stakeholders – con alcuni Chief Officer – e abbiamo passato alcune settimane insieme per ristrutturare l’iniziativa. 

Siamo partiti dalla Vision e dagli obiettivi che volevamo ottenere con questo prodotto. Ci siamo chiesti quali fossero gli Outcome che volevamo realizzare per i nostri utenti finali. E, soprattutto, su quali ipotesi si poggiavano questi Outcome.   

Lo step successivo è stato quello di pensare: “Ok, ora che abbiamo questo elenco di ipotesi, quali sono quelle più critiche ed importanti? Come facciamo a validarle?” 

Ci sono varie strade per farlo – noi abbiamo costruito un piccolo MVP (N.d.A Minimum Viable Product ossia una versione opportuna per validare le ipotesi fondamentali del nostro prodotto. Deve darci la possibilità di raccogliere quante più informazioni sul cliente nel minor tempo possibile) per un numero ristretto di end-user. Glielo abbiamo fatto utilizzare e abbiamo raccolto il feedback per validare le ipotesi che avevamo. Questo ci permise di determinare cosa fare dopo. 

Pensi che esistano delle pratiche che possano spingere le persone a lavorare in ottica di Product Thinking sin da subito? 

Il punto è sempre evitare di partire dalle feature, dall’output. 

Dobbiamo partire dalle ipotesi e validarle in maniera ciclica.  

Mi vengono quindi in mente i Team Agili: in qualche modo questo aspetto è già incorporato nel loro modo di lavorare. 

Penso all’utilizzo delle User Story (N.d.A Elementi lavorabili che descrivono un singolo requisito dal punto di vista dell’utente), per esempio. Queste ci aiutano a capire chi ha bisogno e perché ha bisogno di qualcosa. Questo è l’outcome, l’esito che vogliamo raggiungere. Ma le User Story non definiscono l’output – ovvero cosa costruire e come. 

Quindi le User Story, se usate correttamente, danno l’opportunità di fare un ciclo di Discovery e Validation prima di impegnarsi verso la Delivery. 

Quello che vediamo spesso nella pratica è che le User Story vengono prese come un template per scrivere requisiti – e i requisiti, di nuovo, sono output da creare. 

Quando succede questo, gli Agile Team semplicemente prendono le User Story come requisiti da sviluppare. Non creano spazio all’interno del loro Sprint per fare prototipazione o validazione. Gli viene negata questa possibilità. 

Quindi una situazione da affrontare non attraverso i processi ma promuovendo la collaborazione, attraverso il lavoro svolto insieme. 

Sì, ma aggiungo un pensiero. Spesso, su questo punto, vediamo resistenza e la resistenza c’è perché la performance degli sviluppatori è misurata sull’output che producono. 

E allora se io devo lavorare 8 ore al giorno a scrivere codice, non posso prendere 2 ore per fare la customer interview con il Designer! Rischierei di essere penalizzato. 

E neanche 2 ore per una Retrospettiva, altrimenti non riesco a “deliverare”! 

Certo. Questo perché misuriamo le performance sulla base dell’output delle persone invece che sugli outcome creati come Team. 

Vorremmo farti 2 ultime domande. Se dovessi pensare alla principale differenza culturale che hai visto tra USA e Europa, cosa diresti? 

Mi sono trasferito negli USA quando avevo 32 anni.  

Crescendo in Italia, ricordo che quando mi relazionavo con persone più grandi di me ho sempre avuto un atteggiamento di riverenza.  

Pensavo: “sono più grandi, sono più competenti di me. Io sono inesperto”. 

La cosa che mi ha colpito subito in America è vedere invece ragazzi di 20 anni parlare con persone di 50 anni avendo una relazione assolutamente paritaria.  

E questo aspetto culturale di maggiore apertura si riflette inevitabilmente anche in ciò che succede all’interno dell’azienda. 

Takeaway

• Il fallimento non è inutile, ma può aiutarci a comprendere a fondo le sfide da affrontare. Valerio nella sua esperienza ha riscontrato, proprio grazie a un fallimento, che non è necessario concentrarsi sulle metriche di vanità, ma piuttosto sui valori reali per i clienti e per l’azienda. 

• Promuovere un approccio Product Thinking implica fondare la struttura sull’identificazione e validazione di ipotesi critiche prima dello sviluppo. Al contrario, il metodo top-down, centrato sulla produzione, rischia di trascurare il valore finale per l’utente. Questo non significa che non sia appropriato in ambito aziendale, ma che per essere adottato, è essenziale chiarire fin da subito l’obiettivo finale per non compromettere il valore per l’utente. 

• Prima di utilizzare l’approccio Product Thinking in un’azienda bisogna porsi questa domanda: “quali problemi vogliamo risolvere e quali soluzioni sono realmente necessarie?”. Una volta stabilito questo punto di partenza possiamo iniziare un processo di Discovery volto a validare delle ipotesi, anziché procedere con l’elaborazione di un piano rigido da seguire. 

Bio: Valerio Zanini è un CST (Certified Scrum Trainer) e un CPIT (Certified Product Innovation Trainer). È stato certificato come Scrum Trainer da Jeff Sutherland (co-creatore di Scrum). Insegna corsi di Agile, Scrum e Product Management a centinaia di studenti ogni anno in tutto il mondo.