Sintomi di una Product Culture assente – Parte 2

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:

• Sindrome “antincendio”
• Mindset IT
• Lenta velocity degli outcome
• Pianificazione caotica
• Perdita della fiducia

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:

• Smettiamo di “combattere gli incendi“
  • Metodi tattici
  • Soluzioni strategiche
  • Metodi culturali
• Come passare dall’IT mindset al Product Mindset
• Evitare una cultura ossessionata dalla produttività
• Dedicare il 20% del tempo all’innovazione continua
• Tracciare una linea tra il software rivolto ai customer e quello a uso interno
• L’arma segreta del Timeboxing
• Empower Product Manager
• L’importanza della leadership
• 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

Smettiamo di “combattere gli incendi”

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.

Metodi tattici

• “Spegnere gli incendi con la benzina“. Se una parte della vostra attività o del vostro prodotto è costantemente “in fiamme” e distoglie la vostra attenzione da ciò che è importante, allora datele fuoco. In altre parole, bloccate tutte le attività quando un prodotto porta più problemi che soluzioni;
• Siate spietati nel definire le priorità ed eseguite il triage su tutto. Come ha detto Brandon Chu nel suo famoso articolo “Ruthless Prioritization”, c’è sempre un modo per raggiungere il vostro obiettivo più velocemente di quanto non stiate pianificando. Anche se essere spietati di solito sembra innaturale per i team, è responsabilità dei leader sfidare le persone a essere spietate e a tagliare davvero ciò che non è necessario;
• Chiedere un aiuto esterno. L’aggiunta di problem solver temporanei ed esterni al team consentirà alle persone di concentrarsi su ciò che è importante, mentre altri “spengono gli incendi”. Questo non è solo un modo efficace per andare avanti, ma alzerà sicuramente il morale. Di solito, i team non vogliono occuparsi dei problemi e vogliono concentrarsi su ciò che è divertente e gratificante, come la creazione di nuove funzionalità.

Soluzioni strategiche

• Cambiare la strategia di sviluppo del software. Ho provato di tutto: roadmap molto lunghe e dettagliate e nessuna roadmap, estimation basate su pianificazioni Gantt e cicli basati sull'”appetito“. OKR molto aggressivi e nessun obiettivo. Non esiste una ricetta per la strategia di prodotto, indipendentemente da ciò che si legge nei libri. Se la vostra strategia non funziona, provate qualcosa di diverso. Inoltre, ci sono momenti in azienda che possono richiedere strategie diverse, ed è quindi giusto cambiare, purché non si cada in un continuo oscillare;
• Esternalizzare prodotti e funzionalità accessorie. Se qualcosa non è fondamentale per la vostra attività, non lasciate che attiri la vostra attenzione. L’esternalizzazione completa di parti del vostro prodotto eviterà al vostro team di doversi occupare dei problemi connessi e dei costi di manutenzione;
• Risolvete classi di problemi, non singoli problemi. Raggruppare i problemi nella stessa classe vi permetterà di identificare e, idealmente, risolvere la causa principale. All’inizio questo metodo sembrerà più costoso, ma vi consentirà di vedere i problemi con anticipo e vi ripagherà nel tempo.

Metodi culturali

• Siate tranquilli. Proprio come il cane del meme, rilassatevi. Nella maggior parte dei casi, la vita non è minacciata dai bug irrisolti. Se i leader impazziscono, tutti impazziranno;
• Non tollerate il patching. Questo spetta principalmente ai tech leader, ma anche i Product Manager non devono spingere per soluzioni quick and dirty. Una patch è un credito che alla fine dovrete pagare (il cosiddetto technical debt);
• Non spingete per rispettare le deadline a tutti i costi. So che questo è particolarmente difficile per i Product Manager, dato che il loro ruolo principale è quello di spingere a rispettare le scadenze. Ma ciò che è importante sottolineare è la parte “a tutti i costi”. Nelle aziende di prodotto, la maggior parte delle deadline sono auto imposte, quindi usate i vostri criteri e siate flessibili;
• Non premiate i “pompieri”. Smettete di glorificare gli sviluppatori che hanno trascorso 4 ore nel fine settimana per risolvere un bug. Non perché sia un comportamento sbagliato, ma perché è segno di una cultura tossica. Le aziende dovrebbero riconoscere e premiare i manager che praticano soluzioni preventive e metodiche a lungo termine e che non hanno molti incendi da spegnere.

Come passare dall’IT mindset al Product Mindset

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:

• Tracciare una chiara linea di demarcazione tra il software rivolto ai clienti e il software interno. Le esigenze sono diverse, le competenze necessarie sono diverse e vi accorgerete di avere bisogno di staff, processi e risorse diversi. (Ulteriori informazioni su questo argomento sono riportate di seguito)
• Trasformate i vostri designer in progettisti di prodotto. Si tratta di una questione importante che merita un articolo a sé stante. Se siete interessati a questo argomento, ecco un articolo veloce e piacevole: “La netta differenza tra UX Design e Product Design, spiegata” di Aaron Travis.
• Fate in modo che tutto passi attraverso un Product Manager. Non importa cosa, non importa quanto sia tecnico, far passare tutto al vaglio di un PM aiuterà il vostro team a modellare tutto dal punto di vista degli utenti e non della tecnologia. Potrebbe non essere una misura efficace, ma è una mossa culturale.
• Assumete engineer che comprendano le esigenze di un software su larga scala e quanto sia diverso da un “software enterprise”.
• Ottimizzate il processo di sviluppo in funzione dell’outcome e non dell’output. Trovate il modo di far sì che il “cambiamento nel comportamento delle persone” (ovvero l’outcome) faccia parte della vostra Definition of Done. Assicuratevi che nulla venga “fatto” finché non c’è un qualche tipo d’impatto sul business.
• Assicuratevi che i vostri Product Manager abbiano una visione olistica del business. Devono comprendere e “criticare” tutto ciò che accade al di fuori dell’organizzazione del prodotto, compresi marketing, vendite, risorse umane, operazioni e tutto ciò che riguarda il prodotto, l’azienda o il team.

Evitare una cultura ossessionata dalla produttività

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

Cos’è l’Agile

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.

Dedicare il 20% del tempo all’innovazione continua

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.

Tracciare una linea tra il software rivolto ai customer e quello a uso interno

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.

Software interno

• Non richiede una stretta accountability.
• Il Product Management è facoltativo.
• Le scadenze sono auto imposte e flessibili.
• La qualità prevale sulla velocità.
• Non consente necessariamente la sperimentazione.

Software rivolto al customer

• Tutto necessita di accountability.
• Il Product Management è mandatorio.
• Il time to market è cruciale.
• La velocità prevale sulla qualità, perché “un prodotto consegnato prima vale di più per i clienti di un prodotto consegnato in un momento successivo”.
• È costruito per la sperimentazione.

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.

L’arma segreta del Timeboxing

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.

Empower Product Manager

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:

• Impedire agli stakeholder di aggirare i PM per arrivare alla tecnologia.
• Evitare il più possibile il processo decisionale dall’alto verso il basso.
• Evitare di prendere decisioni in riunioni in cui i PM sono assenti.
• Aiutare i PM a comprendere meglio i problemi invece di cercare d’imporre soluzioni.

L’importanza della leadership

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:

• Fate in modo che i PM eseguano regolarmente una demo del prodotto. È una grande opportunità per mettersi in mostra e diffondere allo stesso tempo la cultura del prodotto.
• Fate in modo che i PM mostrino l’impatto e i risultati di business durante le riunioni dove sono presenti tutti i dipartimenti (nel caso in cui ne abbiate). Se non ne avete, potete comunque condividere regolarmente i risultati assegnando un punteggio agli OKR, mostrando le metriche attraverso una dashboard o qualsiasi altro metodo che la vostra azienda è solita utilizzare.
• Spingete i PM a prendere l’iniziativa nel processo decisionale. Ad esempio, fate in modo che siano loro a convocare le riunioni e insegnate loro a gestire gli stakeholder.
• Costringete i PM a essere la voce dei vostri customer. Potete farlo esponendoli ai feedback dei clienti e facendoli condividere con tutti.
• Creare una cultura sana premiando coloro che si impegnano davvero a creare valore per i clienti. La ricompensa deve essere tangibile. In genere si tratta di aumenti di stipendio, promozioni, bonus o qualsiasi altra ricompensa significativa che invii un messaggio chiaro a tutti gli altri.

Conclusioni

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 📩