Ottobre 24, 2022 - di Redazione
Se avessi un centesimo per ogni volta che ho sbagliato a prendere una decisione manageriale, sarei ricco e non starei qui a scrivere. Scherzi a parte, se c’è qualcosa che ho imparato nella mia – breve ma proficua – esperienza di leadership di prodotto è un elenco di red flags che non sono stato capace di vedere prima e che sono in grado di riconoscere ora, con il senno di poi.
Questo articolo dedicato alla product culture è, di fatto, la mia versione di “Transforming Product Culture at Scale” di Vincent Chan, che è stato per me illuminante e mi ha aiutato a riordinare tutti i pensieri.
Visto che gli argomenti da trattare sono davvero troppi, ho deciso di dividere il mio scritto in due parti. In questo articolo affronterò tutti i problemi e i sintomi di una product culture assente, nel successivo (a breve lo pubblicheremo qui sul blog) scriverò sulle tattiche e strategie per combattere e risolvere questi problemi.
Quindi, entriamo nel vivo.
Indice:
Il post è abbastanza lungo, ma altrettanto interessante. Se sei di fretta, puoi scaricarlo in PDF e in versione completa (prima e seconda parte) in modo da leggerlo con calma quando vuoi tu.
In ogni azienda ci sono sicuramente più problemi di quanti le persone abbiano il tempo di affrontarne. Nel migliore dei casi, questo si traduce in situazioni in cui sono i problemi minori a essere trascurati. Nel peggiore dei casi, il continuo fire-fighting esaurisce tutte le risorse disponibili per un’operazione. I manager e gli sviluppatori passano da uno sviluppo all’altro senza chiudere quello precedente. Il tentativo di risolvere i problemi diventa un inutile patchwork. La produttività del team crolla. La gestione si trasforma in un gioco infinito di destrezza nel decidere quale “incendio spegnere” per primo e dove collocare le persone oberate di lavoro.
In Argentina lo chiamiamo “remare nel dulce de leche”.
Se tutto questo vi suona familiare, allora la vostra azienda potrebbe soffrire della fire-fighting syndrome. Sono certo che riconoscerete alcuni o tutti questi sintomi:
La brutta notizia è che quando gli Engineer sono sotto pressione per “spegnere un incendio”, sono costretti a trovare soluzioni quick and dirty, piuttosto che efficaci. Si limitano a fare una diagnosi intuitiva, invece di lavorare su un problema a sufficienza per determinarne la vera causa di fondo. Poi, invece di testare la loro diagnosi speculativa, modificano impulsivamente il codice. E se la “breve riparazione” non risolve completamente il problema (cosa tra l’altro sempre molto ambigua), la mantengono e tentano un approccio diverso. Non riescono ad affrontare il problema con metodo, il che si traduce nell’incapacità di trovare una soluzione. Il patching non solo richiede più tempo rispetto alla soluzione metodica dei problemi, ma non risolve nemmeno le cause che sono alla radice dei problemi stessi.
In generale, il patching è deleterio. I nuovi problemi creati dalle varie patch e quelli vecchi che non sono riusciti a risolvere si ripresentano sempre più spesso, fino a quando una buona parte dei problemi in arrivo sono in realtà vecchi problemi che ritornano. Il contesto in cui si muove lo sviluppatore diventa sempre più caotico, il che rende più difficile eseguire esperimenti e individuare i problemi. In alcuni casi, la capacità dell’organizzazione di risolvere i problemi collassa completamente e le performance complessive anche.
Come descritto da Marty Cagan, un’azienda con una “mentalità IT” – in contrasto con una “mentalità di prodotto” – è un’azienda che cerca di gestire il proprio software Internet rivolto al cliente come se fosse un software IT rivolto all’interno (a uso interno), con il risultato di una cattiva esperienza per il customer e un’azienda in difficoltà.
Per una serie di motivi: i dipendenti sono pagati per lavorare in un’azienda e per utilizzare il software che viene detto loro di usare; al contrario, nel software di prodotto, ogni utente prende la propria decisione di acquisto: se non lo vuole, non lo userà. Inoltre, nel software IT un’azienda può fare a meno di richiedere corsi di formazione, lettura di manuali e servizi professionali specializzati; al contrario, nel software di prodotto, se gli utenti non riescono a capire come usare il vostro software sono a un click di distanza dal vostro concorrente.
Nel caso del software IT, la scala e l’utilizzo simultaneo si misurano in centinaia di utenti; nel caso del software di prodotto, invece, si parla di centinaia di migliaia o spesso di milioni di utenti. Nel caso del software IT, se si verifica un problema, i dipendenti sono i vostri e sono costretti a occuparsene; nel caso del software di prodotto, un problema che ne interrompe l’utilizzo, blocca anche le entrate e attira immediatamente l’attenzione del CEO.
La verità è che la maggior parte dei software di prodotto ha un livello molto più alto in termini di definizione, progettazione, implementazione, test, distribuzione e supporto rispetto alla maggior parte dei software IT. È anche vero che gli stipendi di solito riflettono questa situazione. Trovare persone con esperienza nel prodotto è molto più difficile che trovarle con esperienza nel settore IT.
Alcune delle differenze tra le due mentalità possono essere riassunte come segue:
Per parlare in termini strettamente agili, nei team con metodologie di tipo SCRUM, la velocity è un’indicazione della quantità media di Product Backlog che viene trasformata in un incremento di prodotto durante uno Sprint da un Team Scrum (ciò che viene solitamente misurato con un burndown chart). Varia significativamente da team a team e dipende fortemente dalla complessità. Un problema della velocity è che confonde il lavoro svolto con l’accuratezza della pianificazione. In altre parole, un team può “gonfiare” la velocity stimando le attività in modo più prudente. Se un team dichiara che un compito richiederà quattro ore o 4 point, invece d’impiegare due ore o valere 2 point, la sua velocity apparirà migliore (talvolta chiamata point inflation). Ciò significa che non esiste una velocity buona o cattiva.
Inoltre, il problema di concentrarsi sulla velocity degli output e non sulla velocity degli outcome, è che agli utenti non importa nulla. Il vostro fantastico processo CI/CD non ha senso se non influisce direttamente sul valore che viene generato dal prodotto per i customer.
La sfida è che puntare sugli outcome richiede, a seconda dello scenario, un’innovazione solida e disruptive, che non tutte le aziende sono in grado di sostenere.
Un altro sintomo evidente di una cultura di prodotto assente è il continuo cambio di direzione che porta a una pianificazione caotica. Se sentite che ogni volta che cambia il vento, cambiano anche le vostre priorità, è ora di prestare attenzione alla vostra Product Vision.
La causa di fondo potrebbe essere la totale mancanza di una solida Product Vision o di una Product Vision troppo debole per resistere alle condizioni del vostro business. Questa mancanza di visione causa molteplici problemi, non solo una pianificazione caotica. Altri sintomi sono, ad esempio, le difficoltà nello strutturare e organizzare i team, i domini di business, le priorità, gli OKR e così via.
Un modo semplice per testare la vostra visione è eseguire questa semplice lista di controllo:
In ogni caso, la mancanza di vision non è l’unica causa possibile di una pianificazione caotica. Potrebbe derivare anche solo da processi inefficaci, da una catena di comando inefficiente o da una cultura aziendale problematica.
Come risultato di tutto ciò, la fiducia nell’organizzazione del prodotto diminuisce. Gli stakeholder vedono i processi, i Product Manager, i Product Designer e tutto il resto come un ostacolo al progresso. La software development machine si guadagna la cattiva reputazione di non fornire un valore reale.
E come forse già sapete, la fiducia gioca un ruolo importante nell’aumentare l’efficienza di qualsiasi azienda, poiché una comunicazione aperta e onesta tra le parti è possibile solo se esiste un certo livello di fiducia. Una comunicazione inefficiente tra i dipendenti può rallentare il flusso di lavoro, ridurre la produttività e aumentare i costi.
Un segnale comune che indica se questo sta accadendo è quando le parti interessate tendono a parlare direttamente con gli sviluppatori per “portare la loro cosa” in produzione, saltando completamente i Product Manager o qualsiasi processo di richiesta di modifica che potreste avere in atto.
La verità è che non ho ancora capito cosa sia la Product Culture.
È chiaro che non è una serie di attività di team building una tantum, né una guida unica per fare le cose “alla prodotto maniera”. Non è qualcosa da prescrivere, ma da scoprire e che tutti noi abbiamo il potere di plasmare.
Poiché non posso dirvi ora che cos’è la Product Culture, ho fatto del mio meglio per dirvi che cosa non è.
Quindi, se notate uno di questi segnali nella vostra azienda:
Potrebbe essere il momento di agire!
E tu, che pensi? La tua azienda ha una forte product culture o hai notato uno di questi sintomi? Raccontacelo nei commenti! Puoi rileggere l’articolo di Miguel in versione originale a questo link.
Se l’articolo ti è piaciuto e vuoi rimanere aggiornato sui prossimi contenuti, iscriviti alla nostra Newsletter 📩
Le slide sono disponibili per studenti ed ex studenti del Master in Product Management