Il Divario Prodotto-Processo: Come Fermare Questa Emorragia Nel Budget Della Tua Organizzazione

Leggi la Trascrizione:

Stiamo provando a trascrivere i nostri podcast utilizzando un programma software. Ti preghiamo di scusare eventuali errori di battitura, poiché il bot non è sempre preciso al 100%.

Hannah Clark: Una delle cose meravigliose delle organizzazioni Agile è che sperimentiamo costantemente e impariamo a migliorare le nostre organizzazioni e i prodotti che offriamo. Ogni innovazione tecnologica nasce da una qualche forma di sperimentazione, ma c'è anche il rovescio della medaglia: non tutti gli esperimenti portano a risultati positivi. In realtà, molti esperimenti sono altamente difettosi—e quando ci sono in ballo centinaia di migliaia di dollari, l'ultima cosa che vogliamo è prendere decisioni su dati errati. Ed ecco la parte spaventosa: la maggior parte delle volte non ci rendiamo nemmeno conto che i dati sono sbagliati finché non è troppo tardi.

Il mio ospite di oggi è Manuel Da Costa, fondatore di Effective Experiments. Come si può facilmente dedurre dal nome della sua organizzazione, Manuel si occupa principalmente di aiutare le aziende a condurre esperimenti migliori, conducendo a migliori decisioni di prodotto. Sebbene gli strumenti giusti possano certamente aiutarci a migliorare la sperimentazione e l'analisi dei dati, lui ha anche identificato un fenomeno che nasce ai margini dell'organigramma chiamato divario prodotto-processo—e che silenziosamente costa milioni alle aziende tech. Iniziamo subito.

Bentornati al podcast The CPO Club. Oggi sono qui con Manuel Da Costa.

Manuel, grazie mille per essere con noi oggi.

Manuel Da Costa: Ciao a tutti! Hannah, grazie per avermi invitato.

Hannah Clark: Puoi raccontarci un po' del tuo background e di come sei arrivato dove sei oggi?

Manuel Da Costa: Certo. Sono il fondatore di Effective Experiments. Siamo un'azienda che fornisce software per aiutare le aziende a collaborare meglio e prendere decisioni migliori sui prodotti. Il mio background risale agli inizi nell'ambiente lean startup, dove ho imparato l'approccio "test and learn" per la validazione. Mi sono poi avvicinato al mondo dell'ottimizzazione della conversione e gradualmente al mio prodotto, dove aiutiamo davvero i team di prodotto e CX a lavorare meglio insieme.

E questo mi porta a questo punto della mia carriera in cui sento il bisogno di raccontare questa storia, che è proprio ciò per cui siamo qui in questo podcast.

Hannah Clark: Non vedo l'ora di approfondire.

Oggi ci focalizzeremo su un fenomeno che hai chiamato divario prodotto-processo. Puoi darci una panoramica di cosa si intende e delle circostanze che lo circondano?

Manuel Da Costa: Sì, certo. McKinsey ha condotto recentemente una ricerca in cui ha analizzato il divario tra buone e cattive pratiche di gestione del prodotto, e si riduce tutto a questa aspettativa della leadership su come dovrebbe essere eseguita la funzione prodotto rispetto a ciò che in realtà accade, con i product manager che eseguono e dove c'è questa disconnessione. Ho dato questo nome di divario prodotto-processo, ma in realtà è il divario tra aspettative e realtà.

Ci sono molte ragioni per cui ciò accade e le analizzeremo, ma in ultima analisi la direzione vuole prodotti migliori e i manager e owner di prodotto non li forniscono. E ci sono molte ragioni per cui accade.

Hannah Clark: Andiamo un po' più a fondo. Hai detto che ci sono molti fattori per cui questo può accadere. Qual è il percorso o l'origine di questo divario e come ci arriviamo?

Manuel Da Costa: Certo. Vediamo cosa viene chiesto oggi ai team di prodotto, ovvero validare ogni decisione di prodotto presa. La sperimentazione è diventata lo strumento per validare le ipotesi e capire se il prodotto proposto è quello giusto.

Molti team di prodotto incaricati di gestire esperimenti non hanno esperienza o conoscenze adeguate, e anche chi le ha spesso sono conoscenze superficiali su come sperimentare. Il risultato è che si prendono decisioni sulla base di esperimenti che però possono essere difettosi o non abbastanza rigorosi. Ci sono anche altri elementi.

Si parla di collaborazione tra team, consapevolezza di cosa fare e di come prioritizzare efficientemente, perché ci sono tante priorità tra loro in conflitto, soprattutto con la sperimentazione aggiunta al mix. Bisogna capire come prioritizzare efficacemente il backlog.

Questi sono alcuni dei sintomi che abbiamo visto, dove i team di prodotto sono chiamati a eseguire e integrare la sperimentazione nei processi senza però ricevere il supporto necessario.

Hannah Clark: Cosa manca in tutto questo? Sembra che ci sia come una competenza UXR sottosviluppata nei product manager messi in questa posizione, e questo genera una specie di effetto domino di output difettosi. Cosa vedi come contributori principali a questa impreparazione?

Manuel Da Costa: Vediamo dove la sperimentazione viene inserita. In molte aziende, era responsabilità del team marketing o conversion optimization (CRO).

Forse erano poche persone o un piccolo centro di eccellenza. Poi hanno iniziato a trasferire le competenze ai team di prodotto per renderli autonomi. La prima sfida nasce dalla mancanza di conoscenza. Magari ci sono workshop, sessioni guidate, ma finisce lì: accesso agli strumenti e formazione superficiale. Non ci sono risorse che aiutino a capire se migliorano davvero.

Così si procede a numeri: abbiamo fatto X esperimenti, ma nessuno monitora se sono stati pianificati, eseguiti e analizzati correttamente.

Questa competenza richiede tempo per svilupparsi: è come un muscolo, non si diventa bravi subito. Ci sono product manager che fanno buoni esperimenti, ma spesso sono troppo semplici, o esperimenti complessi ma strumentati male. Quando comunicano i risultati alla leadership, le decisioni si basano su informazioni potenzialmente errate, senza saperlo perché manca supervisione.

Manca quindi l'elemento di supervisione. Spesso c'è fiducia nei team: "Fate e crediamo ai vostri risultati". Ma per mancanza di risorse, nessuno verifica l'accuratezza. I risultati possono derivare da buone o cattive pratiche.

Altra cosa, manca il livello di leadership: non parlo solo del product owner, ma di VP prodotto e CPO, che dovrebbero responsabilizzare i team.

Non solo responsabilizzare, ma anche concedere margine per imparare a sperimentare meglio, prendere decisioni migliori e priorizzare. Per questi due motivi si crea un divario tra aspettativa e realtà, perché i product manager faticano ad avere il tempo di fare le cose per bene.

Quindi parte della responsabilità è della leadership, che deve dare mandato e tempo ai team.

Hannah Clark: In termini pratici, che aspetto ha tutto ciò dal punto di vista della leadership? Quali passi dovrebbero fare i leader per evitare di aprire il divario prodotto-processo?

Manuel Da Costa: La prima cosa è impostare i KPI giusti. Capitano incentivi perversi, cioè fissare obiettivi numerici tipo: "devi lanciare X feature nel trimestre".

Diventa una questione di quantità, non di qualità. Puoi lanciare una feature complessa o molte semplici, purché raggiungi il numero. Si tratta quindi di fissare KPI che incentivino nel modo giusto, invece che permettere di fare qualsiasi cosa per arrivare al traguardo.

La seconda cosa è dare capacità di coachare, monitorare e migliorare i team di prodotto nel tempo. Come detto, non si diventa bravi a sperimentare con un solo workshop. Serve coaching e mentoring continuo. Spesso manca il tempo per raggiungere i numeri e perciò non si migliora. È un ciclo vizioso. L’iniziativa deve partire dalla leadership che vuole migliorare le decisioni di prodotto.

Come? Sperimentando e validando assunzioni, quindi dobbiamo dotare i team di mezzi, tempo, mandato e sicurezza per commettere errori, perché la sperimentazione implica anche poter sbagliare. Se i KPI puntano solo alla quantità o al successo degli esperimenti, il rischio è che il sistema venga "giocato" per ottenere quei numeri.

La sperimentazione è testare se qualcosa può funzionare, ma non lo sappiamo finché non la proviamo. Il feedback dei clienti e del mercato ci indica la strada.

Poi si decide se continuare in quella direzione o no. L’elemento di sicurezza psicologica è fondamentale: senza di essa, product manager e owner tendono a perseguire le soluzioni più sicure solo per raggiungere i KPI, e quindi si ottengono decisioni conservative, mai innovative.

Hannah Clark: Posso immaginare un'organizzazione in cui il divario prodotto-processo passa inosservato, i KPI vengono raggiunti, tutti sono generalmente contenti, l’azienda va avanti ma manca qualcosa. Quali sono i sintomi che un'organizzazione soffre silenziosamente di questo gap, che ci sarebbero miglioramenti da apportare e che forse si stanno prendendo decisioni sbagliate a causa di sperimentazioni fallate?

Manuel Da Costa: Se si sperimenta male, capita spesso che CPO e VP dicano di non fidarsi dei risultati degli esperimenti. Si torna dunque a decisioni "a sentimento" anche se ci sono dati, ma se non ci si fida dei dati, vengono subito scartati.

Se un’azienda è "al sicuro" ora, è bene sottolineare: per ora. Se non sperimenti, non innovi, giochi sul sicuro. Ma prima o poi il mercato obbligherà a migliorare o deciderà il destino dell’azienda. La mancanza di fiducia nei risultati degli esperimenti o delle decisioni è la prima cosa da migliorare.

Un'altra cosa: le aziende possono dirsi "data driven", "orientate al prodotto", "orientate al cliente", ma spesso sono solo parole. Si vede dalle pratiche: lancio di feature e aggiornamenti prodotto non allineati con i reali bisogni dei clienti. Si trasforma tutto in una "feature factory": si spingono aggiornamenti solo per fare qualcosa, senza valore reale per cliente o business.

Hannah Clark: Hai framework da consigliare per sperimentare meglio o azioni pratiche da intraprendere?

Perché sembra un problema dalle molteplici cause. Da dove partire se ci si accorge che il fenomeno si verifica nella propria organizzazione?

Manuel Da Costa: Il primo passo è standardizzare. Quando i team di prodotto ricevono tool per fare esperimenti, abbiamo notato che due team diversi della stessa azienda si discostano subito su come li gestiscono, classificano e raccolgono i dati. Il primo passo è capire quale processo si vuole.

Una volta definito, lo si standardizza. Spesso questa parola spaventa perché sembra limitante, senza flessibilità. Con troppa flessibilità, però, regna il caos e i dati diventano inutili nel tempo.

Standardizzare significa fissare processi, classificazioni dei dati, nomenclature, pratiche di analisi, chi firma cosa, ad esempio usando un modello RACI (chi è responsabile, accountability, da informare, ecc).

Sembrano rigidità, ma sono in realtà protezioni. Così, anche se cambia la composizione del team o arrivano nuove persone, la pratica resta. Ogni decisione o esperimento segue la stessa logica.

Inoltre, bisogna rafforzare il collegamento tra decisioni e obiettivi di business. Non basta il "lancia e prega", ma allinearsi con KPI e scopi generali. Ottenendo questi due aspetti, si ha una base migliore per partire. All’inizio ci vuole tempo perché serve abituarsi a una nuova consapevolezza su priorità, backlog, cosa sperimentare, come lanciare o valutare le iniziative, e se diventano feature o meno.

In seguito, è importante che esista supervisione chiara. Ovvero, chiunque deve poter analizzare il lavoro di un team a posteriori – non per trovare colpe, ma per individuare lacune e come coachare meglio.

Per esempio: hai lanciato cinque esperimenti questo trimestre, ma alcuni non hanno un’ipotesi forte o non hai scelto bene le metriche. Ecco cosa puoi migliorare, e solo così le persone crescono: ricevendo feedback orientato al miglioramento.

Agendo su questi due fronti si alza la base dell'organizzazione e si chiude il gap.

Hannah Clark: È interessante perché sembra che serva anche una certa intelligenza emotiva a livello di leadership per gestire in questo modo. Molto si basa sulla capacità dei leader e dei team di coltivare relazioni sicure, dove ci sia sicurezza psicologica anche nel commettere errori o avere esperimenti che non vanno come previsto.

Quali suggerimenti daresti per rafforzare le relazioni tra i team, in particolare trasversalmente all’organigramma? Come migliorare la fiducia quando si lavora insieme, soprattutto su processi nuovi come questo?

Manuel Da Costa: È più facile a dirsi che a farsi, perché ci sono persone, ego, vulnerabilità. Ma, di nuovo, serve dalla leadership offrire sicurezza psicologica e cambiare anche il linguaggio.

Non dire "questo test è riuscito" o "è fallito", ma concentrarsi su ciò che si è imparato. Spostare la conversazione dalle vittorie e sconfitte a: sperimentando, abbiamo validato la necessità della feature o la domanda del cliente e abbiamo generato valore.

Oppure: abbiamo invalidato l'idea, non serve sviluppare la feature, così abbiamo risparmiato risorse e imparato. Bisogna abbandonare il concetto di sperimentare per vincere, da cui deriva l’importanza di come vengono impostati i KPI.

Anche se specialisti e owner di prodotto ascoltando potrebbero pensare "vorremmo farlo, ma i KPI sono diversi", è importante ottenere attenzione dalla leadership. Senza questo, l’organizzazione rischia di trasformarsi in una feature factory, apparentemente produttiva ma senza vero impatto.

Hannah Clark: Domanda pratica: i KPI e le dimensioni dei team variano. Come gestire la supervisione di un team di prodotto mentre si scala e si aggiungono persone con diversi livelli di conoscenza?

Come standardizzare la supervisione, specie se leader e senior non hanno forte background in sperimentazione?

Manuel Da Costa: Nel nostro mondo abbiamo introdotto il ruolo di "orchestratore". In base al numero di team e dimensioni, questa figura sovrintende a un certo numero di persone o team. Si occupa di onboarding, coaching, mentoring, monitorando che tutto proceda come dovrebbe e riportando ai livelli superiori.

Piuttosto che avere un solo leader che segue tutti, è meglio una figura responsabile di alcuni team, con il compito specifico di onboarding, coaching e mentoring perché si sperimenti meglio e si prendano giuste decisioni di prodotto.

Si lavora all'interno dei confini e processi fissati dall’organizzazione. L’orchestratore può seguire più team, ma tutto dipende ancora dalla dimensione.

Hannah Clark: Concordo anche sul concetto di "guardrail". Spesso sembra limitante, ma nella pratica riduce la fatica decisionale e rende il lavoro più chiaro, evitando di dover reinventare continuamente i processi.

Sono curioso: come standardizzare la supervisione anche se si ha poca esperienza diretta in sperimentazione?

Manuel Da Costa: Si parte con un framework di governance. Questo prevede le regole per la creazione di un esperimento.

Quindi: quali elementi chiave devi raccogliere creando un esperimento? Alcuni sono basilari, per esempio l’ipotesi. Ma c'è differenza tra un’ipotesi semplice e una solida.

Poi: quali altri dettagli sono rilevanti? Non solo i dati tecnici, ma anche i dati utili per il business. Ogni esperimento deve quindi avere alcuni dati obbligatori e altri opzionali.

Questo sistema si può “imporre” come livelli minimi di dati. Troppa flessibilità produce varianti di processo team per team, con risultati confusi. La governance richiede quindi che ogni esperimento raccolga dati tecnici e di business rilevanti.

Poi il processo: non puoi progettare, eseguire e analizzare un esperimento senza rispettare certi step. Non lanceresti una feature senza QA, e lo stesso vale per l’esperimento: serve una fase di QA anche per questo. Queste tappe non sono negoziabili e ogni esperimento deve seguirle. Se avviene una deviazione, può essere monitorata e capita.

Qui entra il concetto di "health scorecard" – una checklist su cui valutare l'esperimento: è stata creata un’ipotesi? Quando? È stata creata all’inizio o a posteriori (cioè "harking": ipotesi dopo aver visto i risultati)? Questo capita quando si aggiusta l’ipotesi per far risaltare il successo.

Le guardrail e la governance sono fondamentali per prevenire questi problemi, che spesso non avvengono per malizia ma per rincorrere i KPI "quantitativi": allora si adattano obiettivi e metriche. Lo "health score" serve anche per monitorare la coerenza e regolarità del processo, la qualità dei dati durante ogni esperimento.

Così puoi stabilire se puoi fidarti di quell’esperimento e delle decisioni conseguenti, oppure no (e per quali ragioni), che diventa a sua volta opportunità di coaching e miglioramento delle decisioni di prodotto e delle pratiche di sperimentazione.

Hannah Clark: Apprezzo molto i framework che hai fornito, sono molto utili.

Hai casi di successo in cui un’organizzazione è riuscita a trasformarsi eliminando il divario prodotto-processo?

Manuel Da Costa: Non posso fare nomi, ma abbiamo lavorato con una grande azienda e-commerce globale che stava passando da un centro di eccellenza ai team di prodotto e di mercato. Non abbiamo introdotto la sperimentazione ovunque da subito. Abbiamo creato una SWOT analysis di ogni team e li abbiamo valutati sia sulle competenze sia sul grado di motivazione.

Abbiamo iniziato con i più pronti e disponibili, usandoli come "social proof". Ogni "sprint" durava tre mesi, con coaching e onboarding mirato all’autonomia. Poi abbiamo coinvolto altri team, favorendo la comunità interna tra gruppi.

Alla fine di due anni, i team erano molto più competenti sulla sperimentazione. E anche con turnover, il tempo per integrare un nuovo dipendente in questi processi era inferiore a un mese, proprio perché c’erano framework e sistemi stabili: bastava seguire il percorso.

Hannah Clark: Davvero interessanti gli esempi, grazie di tutte le informazioni condivise.

Manuel, grazie di cuore per essere stato con noi. Dove possono seguirti i nostri ascoltatori per saperne di più sul tuo lavoro e su Effective Experiments?

Manuel Da Costa: Sono molto attivo su LinkedIn. Puoi visitare anche EffectiveExperiments.com per scoprire cosa facciamo e leggere il nostro blog. Seguimi pure su questi due canali.

Hannah Clark: Fantastico, grazie mille.

Grazie per averci seguito. Per altre analisi, guide pratiche e recensioni di strumenti, iscriviti alla nostra newsletter su theproductmanager.com/subscribe. Puoi ascoltare altre conversazioni come questa abbonandoti a The CPO Club ovunque trovi i tuoi podcast.