Sintomi di una Product Culture assente – Parte 1

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:

• La sindrome “antincendio”
• Mindest IT VS Product Mindest
  • Perché il software di prodotto è così diverso dal software IT?
  • IT Mindset
  • Product Mindset
• Lenta velocity degli outcome
• Pianificazione caotica
• Perdita della fiducia
• Conclusioni
  

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.

📥SCARICA IL PDF COMPLETO

La sindrome “antincendio”

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:

• Non c’è abbastanza tempo per risolvere tutti i problemi. I problemi sono più numerosi delle persone che possono risolverli – sviluppatori, manager o altri – nel modo giusto.
• Le soluzioni sono incomplete. Molti problemi vengono rattoppati e non risolti. In altre parole, si affrontano gli effetti superficiali, ma non si risolvono le vere cause.
• I problemi si ripresentano a cascata. Le soluzioni incomplete fanno riemergere vecchi problemi o ne creano di nuovi, a volte in altre parti dell’organizzazione.
• L’urgenza sostituisce l’importanza. Gli sforzi messi in campo per risolvere i problemi in corso e le attività a lungo termine, come lo sviluppo di nuovi processi, vengono ripetutamente interrotti o rinviati perché è necessario “spegnere gli incendi” che divampano.
• Molti problemi diventano crisi. I problemi si alimentano lentamente per poi esplodere e divampare spesso prima di una scadenza. Allora richiedono sforzi eroici per poter essere risolti.
• Le performance calano. Molti problemi vengono risolti in modo inadeguato e molte opportunità vengono messe nel dimenticatoio, tanto da far crollare le prestazioni complessive.

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.

Mindset IT VS Product Mindset

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à.

Perché il software di prodotto è così diverso dal software IT?

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:

IT Mindset

• Scopo: il personale esiste per soddisfare le esigenze tecnologiche percepite dal business.
• Passione: Prodotto e Tech sono mercenari. La passione per il prodotto è scarsa o nulla. Sono lì per costruire qualsiasi cosa.
• Requirement: I requisiti vengono “raccolti” dagli stakeholder, classificati in base alle priorità sotto forma di roadmap e implementati.
• Staff: Mancanza di veri Product Manager (soprattutto di PM bravi), mancanza di veri interaction designer, prevalenza del vecchio stile di project management, scarsa familiarità degli engineer con la richiesta di scalabilità e performance, esistenza di business analyst vecchio stile e un uso esagerato dell’outsourcing.
• Finanziamento: Finanziamento dei progetti (output).
• Processo: Processi waterfall molto lenti e pesanti, anche quando gli sviluppatori si considerano Agili.
• Prioritizzazione: Tutto è importante. L’obiettivo è rendere soddisfatti tutti gli stakeholder interni.
• Silos: le persone si allineano per funzione, creando silos tra le diverse aree aziendali, prodotto, UX design, dev, QA e operation.
• Struttura organizzativa: Gli engineer sono spesso alle dipendenze di un CIO o di un CEO. Il prodotto non è rappresentato al C-level.
• Accountability: La responsabilità è una farsa. Le persone che lavorano effettivamente a un progetto di solito non hanno alcuna voce in capitolo su ciò che stanno costruendo, e a volte nemmeno su come viene costruito, e nemmeno quando viene consegnato. In teoria, la leadership potrebbe cercare di responsabilizzare le parti interessate per i risultati, ma se lo fanno si sentono subito dire che non hanno ottenuto quello che volevano e che, a causa di ritardi e costi, hanno dovuto tagliare degli sviluppi importanti, e non certo per colpa loro.
• Il ruolo della tecnologia: La tecnologia è vista come un male necessario. È una fonte di paura più che una fonte d’ispirazione.
• La leadership: La leadership è divisa in silos. Ogni silos spinge per i propri obiettivi. Il mantenimento dello status quo è più importante dell’innovazione.

Product Mindset

• Scopo: il personale esiste per soddisfare i bisogni dei clienti, nel rispetto del business.
• Passione: Prodotto e Tech sono missionari. Si sono uniti all’azienda perché hanno a cuore la missione e aiutano i customer a risolvere problemi reali.
• Requirement: I Product Manager devono “scoprire” il prodotto necessario da costruire. Inoltre, sappiamo che la maggior parte delle idee non funzionerà con i clienti nel modo in cui speriamo, e sappiamo anche che quelle che funzionano richiederanno diverse iterazioni per raggiungere i risultati commerciali sperati.
• Staff: PM e sviluppatori competenti, con una profonda conoscenza degli utenti e dei clienti, una profonda conoscenza dei dati, una profonda conoscenza del business e una profonda conoscenza del settore.
• Finanziamento: I team di prodotto finanziati sono misurati in base agli outcome.
• Processo: Le organizzazioni di prodotto basate sulla tecnologia devono semplicemente muoversi molto più velocemente e lavorare in modo diverso per fornire le soluzioni necessarie ai nostri clienti e alla nostra azienda.
• Prioritizzazione: Le esigenze degli utenti sono l’unica priorità. Si esercita una “prioritizzazione spietata”.
• Silos: dipendono da una vera collaborazione tra prodotto, UX design, tech e unità aziendali.
• Struttura organizzativa: C’è una grande differenza tra i dev che supportano il “vero IT” e quelli che lavorano sui prodotti commerciali. I veri engineer IT di solito riportano al CIO, mentre gli engineer dei prodotti commerciali riportano al CTO.
• Accountability: Le persone sono realmente responsabili e misurate in base agli outcome. Non ci sono scuse.
• Il ruolo della tecnologia: La tecnologia abilita e alimenta il business. Viene accolta e valorizzata. Le persone che creano la tecnologia sono rispettate per il loro contributo fondamentale.
• Leadership: La leadership di un’azienda di prodotti commerciali comprende che è suo compito creare la cultura e l’ambiente necessari per alimentare l’innovazione continua.

Lenta velocity degli outcome

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.

Pianificazione caotica

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:

• È incentrata sul customer?
• È ambiziosa ma non irrealistica?
• È diversa da quella dei competitor?
• Guarda al futuro?

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.

Perdita della fiducia

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.

Conclusioni

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:

1. Sindrome “antincendio“
2. Mindset IT
3. Lenta velocity degli outcome
4. Pianificazione caotica
5. Perdita della fiducia

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 📩