Ottobre 31, 2022 - di Redazione
Nel mio precedente articolo, Sintomi di una Product Culture assente – Parte 1, ho scritto delle cosiddette red flags che potremmo ritrovare nelle aziende che fanno prodotto, e mi sono concentrato principalmente sui problemi e sui sintomi di una Product Culture assente. In questo articolo, invece, tratterò le possibili tattiche e strategie per risolvere questi problemi.
Per riprendere le fila, i problemi che ho evidenziato nella parte 1 sono i seguenti:
Come vedete, questo articolo è rivolto ai responsabili dello sviluppo del prodotto e del software in generale, ma ovviamente il contenuto è rilevante per tutti coloro che sono coinvolti nel processo.
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.
Facile a dirsi, difficile a farsi. Direte voi…
Ci sono diversi modi per smettere di “combattere gli incendi” in azienda, ma come per qualsiasi altro problema, il primo passo è riconoscere di averlo. Pertanto, il primo significativo passo in avanti si fa nel momento in cui il management lo riconosce e decide di farne una priorità. Può sembrare ovvio, ma in realtà la maggior parte dei fire fighting è causata proprio dal management e dalla sua ossessione per l’urgenza rispetto all’importanza. Ecco perché è fondamentale che qualcuno ne parli, sia dall’interno che dall’esterno.
Prendo in prestito le categorie e alcune idee dall’articolo “Stop Fighting Fires” di Roger Bohn in HBR.
Uber è una “azienda tecnologica” o una “azienda di prodotti”? È una domanda difficile a cui rispondere. Una risposta facile è dire che sia un’azienda di “prodotti tecnologici”, ma quasi nessuno lo dice. So che può sembrare banale, ma se fate questa domanda a un’azienda, la risposta più frequente sarà sulla sua cultura e il suo mindset.
Non ho numeri a sostegno di questa mia affermazione, ma credo che la maggior parte delle aziende sia fondata da sviluppatori e, che in generale, ci siano molti più CTO che CPO. Ciò crea nel mercato una cultura dominante orientata alla tecnologia, in cui tutto si concentra sulla creazione di software, lasciando l’esperienza del customer in secondo piano.
Il fatto è che la tecnologia non dovrebbe essere un “male necessario”, né il fine in sé. La tecnologia può e deve essere parte della proposta di valore. I founder creano aziende per mille motivi, ma si suppone che ogni azienda abbia l’obiettivo di aiutare gli esseri umani a progredire in qualche modo. E quando l’obiettivo è aiutare le persone, la tecnologia diventa secondaria per definizione.
Ora chiedetevi: qual è il background delle persone nella mia azienda? Il 99% è composto da persone che hanno studiato finanza, marketing, sviluppo, design, amministrazione aziendale, risorse umane, ecc. Nessuno ha studiato “Come aiutare le persone a migliorare la loro vita”. Per venire al nocciolo, un’azienda di prodotto è un gruppo di persone che sanno come sviluppare software, insieme a un gruppo di persone che sanno come farci i soldi.
Tutto questo per dirvi che il “mindset IT” è la norma e che avere un vero “mindset di prodotto” è innaturale per i team.
Ecco perché assumere Researcher è la cosa più disruptive che si possa fare per passare a una mentalità di prodotto. Queste persone sono ossessionate dall’esperienza del customer e dall’aiutare le persone a fare “meglio”, e come azienda di prodotto non potete permettervi di non averle nel vostro team. Di solito hanno un background di studi come la psicologia o la comunicazione. E anche se i Product Manager e i designer possono e devono svolgere attività di ricerca, culturalmente parlando non è come avere ricercatori a tempo pieno.
L’altro sintomo di questo problema è quando le aziende trattano il software di prodotto come un software informatico. Per affrontare questo problema, Marty Cagan ha dato dei consigli che mescolerò ai miei:
C’è un grande discorso di Jeff Gothelf in cui, tra le altre cose, parla di cosa è l’Agile. Spiega che essere agili significa semplicemente rispondere ai cambiamenti piuttosto che seguire un piano. Purtroppo, quello che è successo nel mondo reale è che le aziende hanno usato l’agilità non per imparare, non per l’agilità e l’adattabilità, ma per lo sviluppo di software e la delivery di codice di alta qualità.
Sono sicuro che avete visto il vostro CEO dare di matto perché i vostri sviluppatori sono “lenti” e lo capisco, non sono così ingenuo. Le aziende devono ripagare i costi degli stipendi, ma ‘produrre’ solo software non è la strada giusta. La strada è quella di produrre valore per il customer, e questo potrebbe dipendere dalla scrittura di una singola riga di codice, come anche dalla sua eliminazione.
Un modo per risolvere questo problema è introdurre un periodo di cool-down nel processo di sviluppo. In questo periodo gli sviluppatori possono concentrarsi su ciò che vogliono, come la correzione di bug, l’esplorazione di nuove idee o la sperimentazione di nuove possibilità tecniche.
Nel processo Shape Up, dopo ogni ciclo di sei settimane, si dovrebbero programmare due settimane di cool-down. Si tratta di un periodo senza lavoro programmato in cui potete respirare, riunirvi se necessario e valutare cosa fare dopo.
Le startup di prodotto di solito faticano a trovare un equilibrio tra innovazione continua e sostenibile. Sebbene l’innovazione sia disperatamente necessaria, la realtà di una startup è che ha bisogno di una pista di decollo per eseguire gli esperimenti necessari a guidare un’innovazione disruptive. Le risorse sono sempre scarse e mantenere la macchina in funzione mentre si fa innovazione a volte sembra come correre e allacciarsi le scarpe allo stesso tempo.
Un modo per risolvere questo problema è utilizzare una semplice regola: dedicare l’80% del proprio tempo a ciò che porta ricavi oggi e assicurarsi un 20% per ciò che porterà ricavi in futuro.
È proprio questo il consiglio che Eric Schmidt, ex CEO di Google, ha ricevuto da Bill Gates. Per saperne di più, potete leggere il libro “How Google Works” di Eric Schmidt e Jonathan Rosenberg.
Come viene spiegato nel libro, questa regola può essere ingannevolmente difficile da seguire. I team di leadership spesso sottovalutano il tempo necessario affinché i ricavi di un nuovo prodotto decollino. Il nuovo prodotto può essere molto più interessante del vecchio e noioso core business, ma è lui che paga le bollette e, sul quale, ogni errore commesso, può pesare in modo irreparabile.
Oltre a prestare attenzione all’80% al core business, è importante dedicare il 20% sull’innovazione. E non mi riferisco alla famosa “regola del 20%” di Google, ma a un’attenzione diretta e strategica all’innovazione che deve provenire dalla leadership. In caso contrario, chi sarà titolato a farlo, criticherà il vostro operato e il vostro team si sentirà demotivato nel non aver avuto la chance di poterlo fare.
Si sa, che le aziende consolidate che smettono d’innovare, di solito non muoiono dall’oggi al domani. Potenzialmente, possono vivere del loro brand per diversi anni. Ma è anche importante sapere che tutto quello che può spingerle verso una crescita molto rapida, può allo stesso tempo, accelerarne la fine.
Le esigenze sono diverse, le competenze necessarie sono diverse e sono necessari processi e risorse diversi. Entrambi sono importanti, ma sono molto diversi e la maggior parte della vostra attenzione deve essere rivolta al software di prodotto.
Le differenze tra i due tipi di software sono solitamente molto evidenti.
Se potete esternalizzare o avere in outsourcing il software IT vero e proprio (quello rivolto all’interno), dovreste farlo, in modo da poter dedicare le persone, il tempo e la menti migliori al customer-facing software.
Chiunque mi conosca sul lavoro sa che il mio asso nella manica sono i cicli di prodotto e chi ha sperimentato i cicli di prodotto sa qual è l’ingrediente segreto: il timeboxing.
Non scriverò qui dei cicli di prodotto perché ci sono molti articoli e letteratura in merito, tra cui “Shape Up” di Basecamp (probabilmente il più rilevante a oggi). Ma lasciatemi spiegare perché il timeboxing è così importante.
Nelle aziende “IT Mindset” o tech-driven esiste un paradigma di sviluppo per estimation, in cui l’azienda si muove al ritmo degli sviluppatori e spetta a loro decidere quanto tempo ci vorrà per andare live con la funzionalità X. Il problema si basa ovviamente sulla difficoltà di stimare lo sviluppo del software, soprattutto in un’azienda che si basa principalmente su codice legacy e in cui gli sviluppatori devono costantemente scoprire come funzionano le cose. Se state mancando ogni singola estimation e di conseguenza ogni deadline, dovreste fermarvi a riflettere.
Il timeboxing costringe l’intera organizzazione a fare un passo avanti. Da un lato, i leader sono costretti a decidere qual è “l’appetito” desiderato di un’iniziativa. Dall’altro, i responsabili di prodotto sono costretti a far rientrare tutto in un ciclo. Questo paradigma devia la conversazione sul valore per il cliente e su ciò che è veramente importante, anziché su quale sia il miglior modo di costruire un software, e in quanto tempo.
Mettere il valore del cliente e il time-to-market al centro della discussione è uno degli aspetti più importanti della transizione verso una vera organizzazione di prodotto, e lo si può fare con i cicli di prodotto o con qualsiasi altra tecnica di timeboxing.
Recentemente ho avuto il piacere di tenere un intervento con voi, community di Product Heroes, a Milano, e nel Q&A qualcuno ha chiesto:
“E se non avessimo il tempo di fare la discovery?”
Al quale ho risposto:
“O trovate il tempo per fare discovery o trovate un nuovo lavoro”
A posteriori, forse sono stato un po’ troppo duro. Ma quello che cercavo di spiegare è che le aziende o credono nel Product Management o non ci credono. E quando dico “aziende” intendo fondamentalmente la leadership dell’azienda. Se non credono veramente nel potere della ricerca, della sperimentazione scientifica e dell’iterazione costante, allora non c’è molto da fare. Non esiste un processo o un metodo magico che possa risolvere il problema.
È responsabilità del leader (CPO, VP, Head of) combattere questa battaglia. I Product Manager di solito non sono nella posizione di poterlo fare.
I falsi Product Manager (alias “amministratori del backlog“) sono la norma, perché fare veramente Product Management richiede un impegno end-to-end nell’organizzazione.
Quindi, per contrastare questo fenomeno, consiglio di seguire queste regole di base:
Il modo più semplice per far rispettare queste regole è utilizzare i processi, ma potrebbe non essere sufficiente. Le regole sono fatte per essere infrante. Pertanto, è qui che entra in gioco la vera leadership e voi, in qualità di leader di prodotto, dovete mettere i PM sotto i riflettori. Ecco alcune delle strategie che consiglio:
Non esiste un solo modo per combattere questa battaglia e sicuramente non esiste una ricetta magica. Ciò che è certo è che si tratta soprattutto di una battaglia culturale che richiede una leadership seria. E per “seria” intendo persone disposte a parlare quando qualcosa non va e ad agire di conseguenza.
L’assenza della cultura di prodotto porta al fallimento. Se non si riesce a raggiungere il product-market fit, di solito si viene cacciati, o perché si è esaurito il denaro o perché si viene battuti dalla concorrenza. Questo non dovrebbe essere solo nell’interesse dei Product Manager, ma dell’intera azienda.
Le aziende che lavorano in silos faticano ad adottare una product culture, perché implica che al centro ci sia solo il customer e nient’altro. I vostri obiettivi di marketing, i vostri obiettivi finanziari, i vostri obiettivi di recruiting non sono importanti. L’unica e sola cosa che conta è il product-market fit.
E tu, che pensi? La tua azienda ha una forte product culture? Ti sei mai trovato a dover “spegnere un incendio”? Raccontacelo nei commenti! Puoi rileggere questa seconda parte dell’articolo di Miguel Carruego 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