Come Correggere la Rotta Quando la Roadmap È Costantemente Fuori Controllo

Leggi la trascrizione:

Stiamo provando a trascrivere i nostri podcast utilizzando un programma software. Per favore, perdona eventuali errori di battitura dato che il bot non è sempre preciso al 100%.

Hannah Clark: Le roadmap di prodotto, come le vere mappe stradali, sono destinate a imbattersi in ritardi. Alcuni si possono prevedere e pianificare, altri invece spuntano dal nulla, ma nella maggior parte dei casi riesci a trovare una deviazione e tornare sulla strada giusta. Ma cosa succede se noti un modello preoccupante: gli obiettivi vengono mancati, le tempistiche si allungano cronicamente e sembra che l'intera roadmap venga costantemente deragliata?

Nell’episodio di oggi ascolterai Michael Pierce, Direttore del Product Management presso la Public Consulting Group, che sostiene che una roadmap cronicamente in ritardo potrebbe essere sintomo di un disallineamento tra la struttura aziendale e la struttura del team di prodotto. Quindi, se stai lottando per capire perché i tuoi obiettivi e le tue iniziative non sembrano mai andare come previsto, questa potrebbe essere la correzione di rotta di cui hai bisogno. Cominciamo.

Ciao ascoltatori. Bentornati al podcast del Product Manager. Sono qui con Michael Pierce. È il Direttore del Product Management presso la Public Consulting Group. Michael, grazie mille per essere qui con noi oggi.

Michael Pierce: Sì, grazie a te Hannah. Non vedo l'ora di essere qui.

Hannah Clark: Michael, puoi iniziare raccontandoci un po' della tua esperienza e come sei arrivato fino a qui?

Michael Pierce: Certo, assolutamente. Ho iniziato con una laurea in economia, come molti colleghi di prodotto, giusto? Abbiamo una varietà di background. Lavoravo in un broker assicurativo e in quel periodo, un amico mi ha dato una copia di The Lean Startup e ho iniziato a leggerla e riflettere sui vari processi interni che erano inefficienti, un po' con quel mindset molto iniziale da prodotto.

E in realtà ho finito per creare una specie di programma VBA avanzato, ho imparato un po’ di visual basic, ho iniziato ad automatizzare alcune cose. Quello è stato un po’ l'inizio della mia curiosità verso il prodotto, in quel periodo non era ancora così popolare come oggi, ma era già orientato al product management.

Mi piaceva parlare con gli utenti, capire di cosa avessero bisogno, cercare di costruire una soluzione e verificare nel tempo i risultati. Poco dopo, ho creato la mia prima startup, era nel settore dell’acquaticità. Lavoravamo con molte piscine ed il Comune di Denver, da cui provengo, è stato uno dei nostri clienti principali, il che per noi era molto entusiasmante e ha segnato l’inizio del mio percorso nel mondo prodotto.

Parlavamo con gli utenti, costruivamo una sorta di roadmap, quasi in stile now-next-later, perché ero ancora molto alle prime armi, ma è stata una grande introduzione al settore. Anni dopo, c’è stata una situazione di acquihire e mi sono trasferito a lavorare in una grande azienda a Boston. È stata un’esperienza fantastica. Poco dopo sono approdato nella mia attuale azienda, la Public Consulting Group, come Direttore del Product Management.

Hannah Clark: Fantastico. Quindi, nel corso della tua carriera hai lavorato con diversi team, a volte come membro e spesso come leader. Quali sono alcune delle sfide che hai riscontrato, più o meno endemiche nei team di prodotto?

Michael Pierce: Sì, penso che una grande sfida che spesso non si riconosce nel product management è che bisogna guardare all’azienda in cui si lavora e cercare di definirla in due grandi categorie. Prima cosa: è guidata dalle vendite? Finanziera? Marketing? Tutti abbiamo visto ottimi esempi.

Ad esempio, HubSpot sul fronte marketing è decisamente un’azienda guidata dal marketing. Se guardi a Zoom o Slack, sono classici esempi di crescita guidata dal prodotto e leadership basata sul prodotto. Quindi, è fondamentale che i team prodotto capiscano se il CEO, ad esempio, passa molto tempo col reparto vendite e ha un rapporto solido con loro.

Oppure la leadership è nata dall’operations, dalle vendite o da altre funzioni? È una traccia utile per capire come opera l’azienda. L’altro aspetto importante, secondo me, per i team prodotto è comprendere come vengono prese le decisioni importanti.

È tutto dall’alto verso il basso? La leadership sociale le decisioni con i manager? È molto democratico? Capire la struttura decisionale aziendale è cruciale. Se conosci queste due cose – se l’azienda è sales o finance led e la struttura decisionale – puoi capire meglio come può muoversi il reparto prodotto.

Perché se ignori tutto questo e operi come dipartimento prodotto isolato, ti troverai spesso davanti a ostacoli e blocchi poiché non ti stai posizionando correttamente per influenzare gli altri.

Hannah Clark: Inquadriamo questa situazione con un aneddoto: quali sono alcuni esempi di disallineamento tra la visione del team prodotto e il funzionamento reale del business che possono causare problemi più avanti?

Michael Pierce: Certamente. Penso di aver capito la domanda. Un esempio potrebbe essere, adesso si parla molto di crescita guidata dal prodotto. Personalmente la adoro, sono di parte, ma penso che se il reparto prodotto opera in ottica troppo product-led e la vera azienda è invece sales-led, nascerà un forte disallineamento su iniziative da finanziare, ottenere buy-in dagli altri reparti eccetera.

È molto importante riconoscere il proprio ruolo, come dipartimento, in relazione agli altri per scegliere le mosse più giuste da fare come team.

Hannah Clark: Parliamo un po’ di prioritizzazione e delle relative sfide, un tema universale per qualsiasi team prodotto a prescindere dal modello di crescita. Quali difficoltà hai incontrato nella prioritizzazione nelle aziende in cui hai lavorato?

Michael Pierce: Sì, mi vengono in mente due cose. Una grande sfida è spesso il gap tra lo stato ideale, quasi una lista dei desideri, di ciò che si vuole realizzare, e la realtà. Quando lavori con board, aziende quotate, investitori, come in società gestite da fondi PE, c’è molta pressione nel mostrare una roadmap enorme, con tante idee affascinanti.

La sfida è far tornare tutti con i piedi per terra, ma in modo che si sentano coinvolti. Quindi, per me la prioritizzazione parte quando si hanno visione e North Star chiari; solo così la prioritizzazione è efficace. Un altro errore comune è non averli definiti. Solo quando stakeholder e manager sono allineati su visione, successo, KPIs, OKR, è molto più semplice avere una buona prioritizzazione e uscire dalla mentalità della lista dei desideri sterminata. Così, anche se ci sono tante attività, saranno tutte ben definite e collegate alle priorità dell’organizzazione. Questo è almeno il mio approccio al problema della prioritizzazione.

Hannah Clark: In una conversazione passata mi hai condiviso un aneddoto su un'analisi fatta in un’azienda (non ne diciamo il nome) dove ti hanno chiesto di individuare le cause del mancato raggiungimento di certi obiettivi. Puoi raccontarcela?

Michael Pierce: Certo. In questo caso, l’azienda mancava una grossa parte degli obiettivi di roadmap e volevano capirne il motivo, una domanda giusta e legittima. Da product manager, vedo la roadmap come l’output di una scatola piena di processi e variabili complesse.

Così, una delle prime cose che ho fatto è stato analizzare i livelli per capire: stiamo mancando il 50% delle voci in roadmap, quali sono le cause profonde? Prima domanda: forse abbiamo troppi punti in roadmap? Se serve fare 2000 ore di sviluppo e hai solo 1000 ore di capacità del team, è chiaro che ne mancherai la metà. Ma da quanto potevo vedere, ingegneri e QA erano sufficienti.

Quindi sono andato più a fondo per capire il vero motivo. Ho scoperto che i team di sviluppo erano condivisi su più prodotti. Se sei product manager, la sfida nel creare una roadmap efficace è poter contare sulle risorse: se hai 5 ingegneri full time, puoi prevedere (magari stimando 30 ore nette settimanali a testa) e calcolare se il piano è fattibile con probabilità dell’80-90%. Ma con team condivisi, se un altro prodotto ha un “incendio” o arriva un grande contratto, tutto il piano dell’azienda e del tuo prodotto può deragliare. Questa era una prima causa principale: sviluppo condiviso.

La seconda era un alto volume di lavoro non pianificato e difetti. La roadmap sulla carta era seguita, ma nella pratica intervenivano aggiornamenti, grandi contratti improvvisi, bug in produzione, ecc. Tutti elementi che possono far deragliare completamente una roadmap. Noi che lavoriamo nel prodotto sappiamo che ci sono tantissime variabili: occorre sempre capire quali sono fisse e quali dinamiche, per poter pianificare. Ma più variabili entrano in gioco, minore è la probabilità di portare a termine quell’obiettivo in trimestre o anno.

Hannah Clark: E questo è solo quello che riguarda la roadmap. Non abbiamo considerato l’effetto su innovazione e sviluppo futuro.

Michael Pierce: Esatto.

Hannah Clark: Quali sono alcuni modi per proteggere la roadmap? Oltre al tempo per eseguire la roadmap, bisogna anche lasciare spazio a innovazione, sviluppo nuove funzionalità e richieste del team vendite. Come si può proteggere la roadmap e il tempo?

Michael Pierce: Ottima domanda. Il primo passo che consiglio a chi lavora nel prodotto è guardare ai trimestri passati e farsi una base solida sul cosiddetto “tempo meteorologico di ieri”. Se nell’ultimo trimestre il 20% del tempo è stato speso in bug, 20% per richieste dal commerciale, 10% in scommesse innovative, puoi usare quelle proporzioni per il futuro.

Un buon modo per allineare l’organizzazione è socializzare l’idea che la roadmap sia una dieta equilibrata: mettiamo il 40% di nuove funzionalità, il 10-15% su difetti, il 20% per grande richiesta commerciale improvvisa. Puoi così decidere quale porzione del lavoro dedicare a ciascun elemento, proprio come una dieta equilibrata.

Così, quando comunichi queste proporzioni agli stakeholder, non rimarranno sorpresi se il 10% del tempo degli sviluppatori va su progetti particolari o idee innovative, perché è già stato preannunciato. Questo permette ai team di dire “no” in modo costruttivo: “Vorremmo tanto implementare subito questa nuova modifica, ma siamo impegnati per un 10% del nostro tempo a esplorare funzionalità che potrebbero portare valore in futuro”. Tutto ruota sempre attorno alla gestione delle aspettative con il top management e gli altri stakeholder.

Hannah Clark: Parlando di team, che relazione c’è tra il modo in cui i team sono organizzati e l’impatto su ciò che viene prioritizzato e rilasciato?

Michael Pierce: Torniamo un po’ al discorso iniziale, guidato dal prodotto o dalle vendite. Spesso la struttura dei team dipende dalla cultura organizzativa stessa.

Se l’azienda è molto orientata alle vendite – e lo intendo in senso positivo: desiderio di portare a casa molto nuovo business – questo influenza la struttura dei team, con più lavoro di sviluppo su richieste specifiche e magari dei team dedicati alle personalizzazioni per i clienti. Quindi, la struttura del team è determinata da ciò che l’azienda valuta di più: vendite, finanza o prodotto, e dal valore che dà all’innovazione o alle funzionalità “greenfield”.

È anche importante la struttura con cui si gestisce il lavoro: siamo cultura Agile? Waterfall? I vari metodi organizzativi hanno grande impatto sui team. Quando lo comprendi, puoi fare da advocacy, cioè proporre cambiamenti: se eravamo molto Waterfall, possiamo testare un approccio Agile su un prodotto nuovo, o passare a team di sviluppatori dedicati. Avere queste informazioni di contesto rende i team prodotto più forti.

Hannah Clark: Ti è mai capitato di dover sperimentare con la ristrutturazione di un team per adattare la funzione alle necessità aziendali?

Michael Pierce: Sì, assolutamente. Nell’ultima azienda, una private equity di Boston, sono stato assunto per costruire il dipartimento prodotto da zero.

Ho analizzato come lavoravano i team, la loro organizzazione: avevamo vari prodotti in azienda e la situazione era un po’ Waterfall e un po’ confusa. Parlandone con la proprietà e il CEO, ho suggerito una ristrutturazione in piccoli gruppi focalizzati sul valore del portafoglio prodotti.

Abbiamo colto l’opportunità per introdurre Agile su tutti i team, aggregare piattaformisti e sviluppatori focalizzati sui singoli prodotti, e coinvolto alcuni membri come PM tecnici anziché PM classici di SaaS standardizzati.

Questa panoramica mi ha dato la possibilità di suggerire una nuova struttura: dopo si sono viste chiaramente le differenze – più efficienza, standup giornalieri, demo di sprint: tutte pratiche che hanno migliorato molto l’organizzazione. E questa è la massima soddisfazione: fare un impatto misurabile e positivo.

Hannah Clark: Ottimo. Dato che hai vissuto queste esperienze, ci sono segnali d’allarme che chi lavora nel prodotto, soprattutto i leader, dovrebbero cogliere che suggeriscono di iniziare a ristrutturare il team?

Michael Pierce: Sì, assolutamente. Bisogna raccogliere dati. Uno dei segnali è il tempo totale dall’idea alla produzione. Se è molto più alto del normale, può essere un campanello d’allarme (anche se è difficile trovare parametri pubblici su questi dati). Se una nuova funzionalità piccola richiede due settimane per arrivare in produzione, direi che è nella media di uno sprint. Ma se uno sviluppo da 40 ore dev richiede 6-8 settimane, c’è probabilmente un blocco nel QA, o nella raccolta feedback degli stakeholder o nella definizione dei requirements.

Questi sono tutti segnali che l’output non corrisponde alle aspettative e che il sistema necessita di interventi.

Hannah Clark: Come misuri il successo della ristrutturazione di un team?

Michael Pierce: Ci sono diversi modi. I classici: output del team – stiamo producendo più valore per i clienti in meno tempo? Stiamo riducendo l’intervallo dall’idea al rilascio? Siamo più agili?

Un altro modo spesso trascurato è combinare one-to-one con i membri e sondaggi prima e dopo la ristrutturazione: si sentono meno tirati da più direzioni? Si sentono più autonomi? Temi come il context switching e l’empowerment vengono percepiti? Questi sono ottimi indicatori del successo di una ristrutturazione.

Hannah Clark: Ottimo. Riassumendo: quali sono stati i risultati principali della tua esperienza di ristrutturazione del team?

Michael Pierce: Una cosa evidente da subito, parlando con le persone, è stata la drastica riduzione dell’ambiguità e del tempo perso in attesa di risposte: prima si incontravano solo una volta a settimana, dopo la ristrutturazione con standup quotidiani i dubbi venivano risolti quasi subito. Così l’output è aumentato e l’ansia dei devs si è ridotta.

Se avevano una domanda potevano ricevere una risposta il giorno seguente, non dopo una settimana. Questo ha fatto sentire il team molto più supportato dall’organizzazione.

Hannah Clark: E infine: come si convince il top management del valore della ristrutturazione?

Michael Pierce: Un aspetto chiave è chiarire con gli executive la complessità del processo: il software è un percorso caotico, pieno di colpi di scena e complessità. È essenziale spiegare quali risultati – OKR e key results – si vogliono raggiungere e usarli come benchmark per tutta l’organizzazione (lo stesso discorso vale per la misurazione del lavoro di squadra: bisogna sapere quali sono i baseline per valutare il progresso).

Hannah Clark: Perfetto Michael, grazie davvero per essere stato con noi. So che sei contributor per The CPO Club e che i lettori possono trovare i tuoi articoli su TheProductManager.com, ma ci sono altri modi per contattarti online?

Michael Pierce: Certo. Il modo migliore è su LinkedIn. Sono un minimalista digitale, quindi uso solo LinkedIn: scrivetemi pure lì, mi farà piacere parlare con chi ascolta il podcast.

Hannah Clark: Grazie mille per il tuo tempo e per i tuoi insight.

Michael Pierce: Grazie a te, Hannah.

Hannah Clark: Grazie a tutti per l'ascolto. Per altri approfondimenti, guide pratiche e recensioni di tool, iscrivetevi alla nostra newsletter su theproductmanager.com/subscribe. Potete ascoltare altre conversazioni simili iscrivendovi a The CPO Club, ovunque troviate i vostri podcast.