Allineamento tramite le roadmap di prodotto (con Brandon Blackman di Crema)

Michael Luchen

Roadmap, il documento chiave che può promuovere la collaborazione in tanti team di prodotto o diminuirne il potenziale a causa della disallineamento. Tutti conosciamo le roadmap, ma cosa succederebbe se potessero davvero favorire una collaborazione autentica? E se invece di considerarle come un documento statico, fossero organiche, trasparenti e iterative? Oggi abbiamo con noi un product manager di primo livello con esperienza che spazia dalla sanità allo sviluppo enterprise che si unisce a noi per parlare di roadmap di prodotto e di come possano essere usate al meglio per creare prodotti di grande valore. Rimanete sintonizzati.

Questo è il podcast del product manager, le voci di una comunità che sta scrivendo il manuale della gestione, dello sviluppo e della strategia di prodotto. Siamo sponsorizzati da Crema, un’agenzia digitale che aiuta persone e aziende a prosperare grazie a creatività, tecnologia e cultura. Scopri di più su crema.us.

Continua ad ascoltare per avere suggerimenti pratici e autentici per avere successo nel mondo del product management.

Sono molto felice oggi di dare il benvenuto a

Brandon Blackman nel podcast. L’expertise di Brandon nella gestione di prodotto è iniziata in una startup tecnologica in ambito sanitario ed è cresciuta fino a supervisionare lo sviluppo di negozi e-commerce, app mobili e lavorare su applicazioni web a livello enterprise. È appassionato del trasformare idee in realtà.

La passione di Brandon si concentra sul motivare team di prodotto Agile di alto livello e cross-funzionali. Oltre ad aver avuto il piacere io stesso di collaborare con Brandon in Crema, lui è anche membro del consiglio di amministrazione di HealthSplash, una piattaforma sanitaria focalizzata sulla risoluzione del problema dei rifiuti nelle richieste mediche dovuti a dati errati.

Brandon, benvenuto nello show.

Brandon Blackman

Ciao. È un vero piacere essere qui.

Michael Luchen

Grazie mille per essere con noi. Dunque roadmapping di prodotto, pronti a entrare nel vivo?

Related Read: Come usare la mappatura delle user story per migliorare la prioritizzazione del backlog Agile

Brandon Blackman

Sì. Sono davvero entusiasta di parlarne.

Michael Luchen

Bene, anche io sono entusiasta. Questo è uno di quegli argomenti su cui ci sono tanti pareri e molti modi corretti di procedere.

Vorrei partire dalle basi: qual è il tuo background personale con le roadmap?

Brandon Blackman

Sì, ho ovviamente accumulato molta esperienza per necessità come product manager. È una parte fondamentale del nostro processo di sviluppo prodotto e del workflow. La mia formazione, però, si basa molto su tentativi ed errori e lezioni dirette. Ricordo le prime roadmap che preparavo: erano molto focalizzate sulle date, quasi da Waterfall, effettivamente, e non venivano mai rispettate. Di solito erano più una fonte di stress e ansia quando qualcuno tra gli stakeholder o dalla direzione mi chiedeva: “Quando possiamo aspettarci XYZ oppure posso vedere la roadmap?” E io pensavo, accidenti, mi sto mettendo da solo all’angolo, ma devo comunque condividerla. Così ho iniziato con le roadmap e mi sono detto che ci dovesse essere un modo migliore. Ho letto molto, mi sono documentato e ho sperimentato con i team di prodotto con cui lavoro, e ora sono molto soddisfatto del risultato.

In realtà ora la roadmap mi piace molto. È diventata uno strumento preziosissimo per me, la mia squadra e i nostri utenti o stakeholder, interni ed esterni, e mi piace molto imparare a strutturarle.

Michael Luchen

Fantastico, hai quindi raccontato come sia passato da un approccio rigido e da Waterfall a incontrare dei limiti.

Che filosofia personale hai maturato sulle roadmap di prodotto grazie a queste esperienze?

Brandon Blackman

È una bella domanda. Non è un testo poetico, ma direi che i principi chiave della mia filosofia sono: mantenerla ad alto livello. Più la rendi granulare, più rischi di creare aspettative disattese; tenerla sempre aggiornata, quindi manutenerla costantemente; e infine sempre rilasciare. Io sono tra quelli che preferiscono rilasciare spesso e presto, quando si tratta di prodotti digitali.

Michael Luchen

Cominciamo dalle basi del roadmapping di prodotto. Qual è, secondo te, l’obiettivo finale di una roadmap?

 

Brandon Blackman

Ottima domanda. Direi che l’obiettivo finale di una roadmap deve essere comunicare la direzione del prodotto. Anche, in realtà, della comunità: deve riflettere la direzione dell’azienda o dell’organizzazione nel suo insieme. Il motivo è che il cuore stesso della roadmap è ottenere allineamento tra tutti coloro che sono coinvolti nel prodotto. Allineamento esterno con gli utenti, allineamento interno col team di prodotto o con la leadership aziendale. L’intera chiave è allineare varie persone con differenti prospettive su ciò che possono aspettarsi in futuro. È una sfida davvero complessa, e quindi l’obiettivo della roadmap è, in modo chiaro e conciso, dire a tutti gli stakeholder dove si sta andando con quel prodotto.

Michael Luchen

Quindi è una sorta di storia che cambia sempre, in un certo senso, perché…

Brandon Blackman

Assolutamente.

Michael Luchen

Serve a più stakeholder.

Brandon Blackman

Esatto, proprio così. E come ogni buona storia, non vuoi annoiare con troppi dettagli. Mi piace il concetto della storia perché vuoi tenerla coinvolgente e dare solo le informazioni giuste per arrivare all’obiettivo, ovvero l’allineamento. Ma non bisogna scendere troppo in dettaglio rischiando di mancare alcuni requisiti o deadline perché ci si è soffermati troppo sul dettaglio.

Michael Luchen

Assolutamente. Abbiamo iniziato a entrare in queste acque, ma per chiedertelo esplicitamente: una roadmap deve essere un artefatto statico creato una volta per tutte, oppure qualcosa di più organico e iterativo?

Brandon Blackman

Io sono decisamente dell’idea che debba essere organica, iterativa. Se è qualcosa di statico, probabilmente abbiamo fatto delle assunzioni sbagliate sugli utenti e su come il prodotto verrà usato una volta rilasciato. Alla fine la roadmap comunica qualcosa sul futuro, è una previsione su qualcosa che, comunque, per quanto pianifichi, non potrai mai sapere esattamente finché non ci arrivi. Quindi la roadmap va presa per quello che è: una previsione, una visione del futuro e il modo migliore per avere la previsione più accurata è guardare il presente e aggiustare la previsione di conseguenza. Deve essere sempre iterativa: mai pensare che esista una versione finale.

Michael Luchen

Certo, e supporre anche che sia una versione finale può andare contro agli obiettivi stessi a cui aspira.

Mi piace la parola previsione perché si basa sulla nostra attuale “scienza” del prodotto. Comprensione attuale di utenti, bisogni, il contesto aziendale e di mercato. Ma mentre costruiamo tutto cambia, quindi anche la roadmap deve tenere conto ed evolvere.

Brandon Blackman

Al cento per cento. Concordo pienamente.

Michael Luchen

Quindi, se sto per creare una roadmap di prodotto per il mio fantastico prodotto ABC, su cosa dovrebbe concentrarsi?

Brandon Blackman

Bella domanda. Devi davvero concentrarti sul perché e sul cosa stai costruendo. Penso che sia molto forte la tentazione, specialmente senza esperienza, di focalizzarsi sul come. Ma questa è la domanda che una buona roadmap può creare: come ci arriviamo?

Bisogna evitarla. Il come sta nel backlog. Sarà il backlog a spiegare come ci arriviamo, ma la roadmap si concentra su perché e cosa. Perché ci muoviamo in questa direzione? Perché certi elementi sono prioritari? Su cosa ci concentriamo? Questo deve rispondere la roadmap, non il come.

Michael Luchen

Nelle nostre roadmap inseriamo spesso stati, temi e risultati. Puoi parlarne nel contesto della roadmap?

Brandon Blackman

Ottima domanda. Lo stato di una roadmap, se ci sono stati, sono: cosa stiamo facendo ora, cosa faremo dopo, cosa affronteremo più avanti. Questi stati non hanno date! Appena inserisci una data, e a volte serve, ma appena la metti ti auto-imponi un vincolo che magari non era necessario.

Lo status non ha data: è quello che si lavora ora, oggi, domani, dopodomani, ma ora lavoriamo su questo. Il prossimo status dice agli stakeholder cosa verrà, senza una data. Puoi partire domani, o la prossima settimana, ma intanto sanno cosa arriverà. E poi più avanti, a indicare che prima o poi arriveremo anche a quegli argomenti. Il tema è una prospettiva comune della roadmap: ad esempio “relazione con il cliente”. Un tema, poi puoi mappare elementi che contribuiscono a quella relazione. Un approccio orientato all’outcome, ad esempio, potrebbe essere “incrementare le interazioni con i clienti del 30%.” Questo è un outcome, può essere collegato al tema, ma indica che puntiamo ad aumentare le interazioni del 30%.

Questo dà un bel perché e cosa. Il come lo lasci agli esperti, alle persone del team prodotto: ci sono molti modi per arrivare a quell’obiettivo, la roadmap deve solo comunicare che stiamo puntando lì.

Michael Luchen

Fantastico. Grazie mille per questa panoramica dei percorsi possibili. Personalmente, ho visto quanto sia potente un approccio davvero Agile alle roadmap. Si enfatizza ciò che sappiamo adesso, avendo anche una “zona d’attesa” per il dopo, in funzione di temi e outcome.

E poi tenere tutti gli altri elementi nel backlog, idee che possono o meno diventare preziose. Non è impegnarsi, non è qualcosa di scolpito nella roadmap permanente.

Brandon Blackman

Esatto. Più ci si impegna, più si aumenta il rischio di ulteriori vincoli e aspettative da rispettare.

Michael Luchen

Vero, hai detto spesso “Non mettere le date”. So che molti di noi invece devono mettere delle date: i nostri stakeholder vogliono il rilascio per una certa scadenza. Come gestisci questa pressione sulle date?

Brandon Blackman

Se tutto dipendesse da me, le date non esisterebbero sulle roadmap. Ma so che questa è una visione ideale. Spesso hai il CEO che vuole sapere quando aspettarsi qualcosa, il marketing chiede le tempistiche, l’assistenza clienti anche. Quindi purtroppo date servono, ma io cerco sempre di stare nel compromesso e dare la data più generica possibile che serva al team o allo stakeholder.

Nella maggior parte dei casi, va bene una roadmap trimestrale: ad esempio, entro il Q2 aumenteremo le interazioni col cliente del 30%. Vediamo quali funzionalità contribuiscono e dai abbastanza dettagli al marketing per iniziare campagne sulla relazione col cliente. Vale per qualunque tema, outcome o funzionalità. Anche l’assistenza si regolamenta, attivando i canali necessari entro Q2. La roadmap orientata a temi o outcome comunica la direzione a tutti e il livello di dettaglio temporale il più alto possibile.

Quindi trimestrale è perfetto: hai tre mesi di margine. Poi può variare, per l’esterno è magari per il trimestre successivo, internamente per quello attuale.

Michael Luchen

Mi piace la parola margine da usare come strumento nelle roadmap e adoro l’approccio trimestrale.

C’è un’altra tecnica utile, un modello mentale: il cosiddetto cono di incertezza. Per chi non lo conoscesse, pensa a un triangolo ruotato su un lato, tagliato in fondo: la base larga è oggi.

Andando avanti, c’è molto spazio (e quindi incertezza) su consegna di funzionalità o raggiungimento degli outcome/temi della roadmap. Ma col passare del tempo e avvicinandosi agli obiettivi, ci sono più apprendimenti, più certezza. Una cosa pratica: sfruttare in Agile il concetto di velocity del team (story points). Dopo qualche sprint, puoi prevedere meglio, capire rischi tecnici, UX, di mercato, che potrebbero impattare la velocity. Avvicinandosi alla scadenza puoi essere molto più preciso pur restando Agile.

Brandon Blackman

Mi piace molto il concetto del cono di incertezza e mi ricorda qualcosa appena successa: proprio la settimana scorsa ho dato un’occhiata al mio 401k. Anche se sono lontano dalla pensione, il portafoglio ha uno strumento di previsione che in molti modi è come la mia roadmap per la pensione e mostra il cono di incertezza.

Ti imposta investimenti, allocazioni, affinché con il 90% di certezza si arrivi a una cifra alla pensione. Non c’è certezza sul futuro, specie tra 30 anni, ma aiuta a decidere l’allocazione degli investimenti. Facendo cambi, il cono di incertezza ti dice: con il 30% di probabilità avrai tot, col 90% tot altro. Penso che le roadmap siano simili. Più un stakeholder è in alto, più vuole la data precisa.

Quando ti chiedono cosa aspettarsi per una data, va bene rispondere: vuoi una previsione al 90% di certezza o al 30%? Così almeno sanno cosa aspettarsi.

Michael Luchen

Bellissima analogia. Cambiando argomento: come gestisci le dipendenze nella roadmap?

Brandon Blackman

È una domanda difficile a cui rispondere genericamente. Il modo migliore per gestire le dipendenze è annotarle e comunicarle. Devono essere sulla roadmap. Hai una roadmap basata su temi/output/status: indica le dipendenze attaccate a quegli elementi. Anche se hai un risultato previsto in una certa data/quadrimestre, specifica che dipende da X, Y, Z. Comunichi così l’allineamento. Spesso capita tra team frontend e backend: il frontend dipende dal backend e viceversa. Allora si può stipulare un contratto (ad es. API contract) che delinea cosa farà l’API e su cui il frontend può lavorare anche senza API già pronta.

Vale anche all’inverso: il backend sa cosa deve offrire al frontend. Questo contratto è un punto di convergenza, vincola entrambe le parti. Può essere un documento anche tra dev e marketing o customer service: si scrive cosa aspettarsi a lavoro concluso e permette ai team dipendenti di prepararsi.

Michael Luchen

Molto interessante, soprattutto la nota sui contratti API. Non si tratta solo di dipendenze di business o contenuto, ma anche di dipendenze tecniche e su come strutturare la collaborazione tra team di sviluppo.

Brandon Blackman

Assolutamente. Da qui deriva che le cose possono andare male: è il concetto stesso di dipendenza. Ci si deve aspettare che qualcosa non va come previsto, ecco perché scrivere le dipendenze sulla roadmap consente di spiegare perché serve cambiare qualcosa: una dipendenza è cambiata, era più grossa del previsto.

Se tutto è comunicato in anticipo, elimini l’80-90% dei problemi di previsione. Ecco perché l’allineamento è il vero obiettivo della roadmap.

Michael Luchen

Hai citato le sfide delle roadmap. Quali sono le più comuni con gestione del rilascio in Agile?

Brandon Blackman

Spesso i problemi derivano da stakeholder o team non legati al prodotto, soprattutto in azienda, che non conoscono l’Agile. Il lavoro sta nel comunicare e formare, spiegando cos’è Agile, perché si costruisce così. Mi piace la metafora che non stiamo semplicemente costruendo una casa: le case sono sempre state fatte, sappiamo come si fa. Qui invece si costruisce qualcosa mai visto, o comunque diverso dagli altri, quindi non c’è modo di prevedere tutto.

Un’altra sfida di Agile è ammettere che c’è tanto ignoto. Ci sono cose note, cose note di non sapere e cose ignote di non sapere. Agile non le elimina, ma permette di gestirle. Si vive nella tensione dell’incertezza, ma consente comunque di costruire prodotti utili agli utenti.

Michael Luchen

Vero. Una cosa che mi torna in mente è che lo sviluppo software è proprio creazione di conoscenza. La metafora della casa non regge davvero: non è solo costruire una casa, è anche capire quali mattoni servono, come crearli, e magari si scopre che ne serve un tipo nuovo. Quindi anche la costruzione del prodotto comporta creare e acquisire nuova conoscenza strada facendo, con variabilità che si riflette sulla roadmap.

Sono contento che tu abbia parlato di questi aspetti di ambiguità.

Brandon Blackman

Giusto.

Michael Luchen

Scendiamo dal livello 50.000 piedi al livello 30.000: gli sprint e la suddivisione della roadmap. Brandon, come aiutano gli sprint a articolare la roadmap?

Brandon Blackman

Ogni sprint deve avere un obiettivo chiaro, da raggiungere entro la fine. Questo obiettivo deve far progredire prodotto, team e utenti rispetto alla roadmap.

Se l’obiettivo di sprint è sconnesso dalla roadmap, quello che si sta facendo non contribuisce alla direzione del prodotto. Negli sprint planning e kickoff, parto sempre dalla roadmap (visuale a 50.000 piedi), prima di parlare dello sprint, delle storie, del goal. Così teniamo sempre il collegamento.

Quindi, per le due settimane scegliamo le storie e definiamo il goal, che deve collegarsi chiaramente alla roadmap. Se non è esplicito, deve essere uno step propedeutico, tipo una storia tecnica di backend che prepari il terreno per la prossima storia direttamente collegata alla roadmap. Il goal di sprint funge quindi da ponte fra il lavoro di oggi e la roadmap, e va dichiarato in modo conciso nello sprint.

Michael Luchen

Molto bene. Adoro gli sprint goal come punto di partenza. Una delle difficoltà più comuni è che gli sprint rischiano di diventare piccoli Waterfall da due settimane. Come evitare questo rischio, nel contesto della roadmap generale?

Brandon Blackman

Gli sprint devono essere composti da user story indipendenti e utilizzabili.

Per chi lavora davvero in Agile, questo è un principio base, ma ammetto che anch’io a volte mi rilasso sulla scrittura delle user story e dimentico che devono essere indipendenti, testabili e utilizzabili.

Quindi, bisogna assicurarsi che ogni obiettivo di sprint sia indipendente e usabile da solo. Non dovresti mai concludere uno sprint con qualcosa che potrà essere usato solo dopo altri due o tre sprint. Quello è un mini-Waterfall. Bisogna pianificare gli sprint in modo che ogni sprint sia indipendente e, se vuoi, rilasciabile. Gli utenti dovrebbero poter usare la funzionalità, anche se solo ipoteticamente in preproduzione.

Così si mantiene la filosofia “rilascia spesso”. Non significa che si va sempre subito in produzione, ma che ogni sprint genera qualcosa realmente utilizzabile.

Michael Luchen

Verissimo. E inoltre, sulle user story: senza approfondire (potremmo fare un podcast intero), bisogna trovare il giusto equilibrio tra chiarezza e ambiguità. Troppa chiarezza rischia di rendere la story troppo Waterfall, troppa ambiguità rende difficile l’avanzamento, ma bisogna lasciare il giusto spazio alla creatività della squadra.

Brandon Blackman

Esatto. Se si entra troppo nel dettaglio si rischia di ricadere nel “come” e, da product manager, senza competenze da dev o designer, è meglio restare sul livello alto, lasciando agli esperti la soluzione. Così si lascia ai membri più brillanti del team la libertà di risolvere i problemi e tu non devi capire ogni dettaglio.

Michael Luchen

Assolutamente. Abbiamo parlato di roadmap, dei loro tipi e di come procedere tramite sprint. Ogni quanto va rivista la roadmap?

Brandon Blackman

Da product manager, la vedo ogni giorno, se non un giorno sì uno no. Per il team di prodotto, andrebbe rivista a ogni kickoff o sprint planning. Dovrebbe essere la base per determinare lo sprint goal e quali user story o epic includere.

A livello aziendale, ogni volta che il product manager o owner comunica aspetti del prodotto agli stakeholder, è il momento di mostrare la roadmap per il contesto. Non va fatta vedere una piccola finestra, ma tutta la panoramica, così tutti capiscono cosa stiamo facendo e perché. Quindi il più spesso possibile, sicuramente a ogni riunione di kickoff e planning; il PM dovrebbe rivederla quasi quotidianamente.

Michael Luchen

Ottimo. Domanda personale: qual è il tuo tipo di roadmap preferito, il tuo default?

Brandon Blackman

Dipende dal prodotto, ma in genere preferisco le roadmap orientate ai temi. Dannno una visione chiara di come il tema si colleghi agli obiettivi aziendali e permette al team di scegliere cosa fare, ma dà anche libertà a sviluppatori e designer di decidere il come. Una roadmap tematica rende quindi il team più autonomo e valorizzato.

Per prodotti piccoli, dove magari si lavora solo un paio di settimane l’anno su un progetto, la roadmap deve essere molto concisa ma precisa, così tutti sanno cosa sarà consegnato nel corso dell’anno. Mi piacciono molto anche le roadmap a stato: comunicano subito cosa si sta facendo, cosa arriverà e cosa ci sarà più avanti.

Michael Luchen

Siamo quasi al termine: un rapido giro di domande personali se sei d’accordo.

Brandon Blackman

Certamente.

Michael Luchen

Quale abitudine personale ha contribuito di più al tuo successo?

Brandon Blackman

Sono un po’ vecchio stile: prendo appunti a mano. Non sempre, spesso scrivo veloce su digitale, ma passare gli appunti su carta, tenere un quaderno, mi aiuta a fissare nella memoria, passare da quella a breve termine a quella a lungo termine. Mi piace anche sognare il futuro su carta, fare liste, disegnare, progettare. Quindi la mia abitudine è: quaderno e penna per ripercorrere il passato, organizzare il presente, progettare il futuro. Prendo in prestito questa filosofia dal metodo bullet journal.

Michael Luchen

Ottimo. A parte carta e penna, qual è il tuo strumento preferito?

Brandon Blackman

Non sarà una sorpresa: Miro, la lavagna virtuale. La uso costantemente. Non credo di aver mai fatto una roadmap fuori da Miro da quando l’ho scoperto. Tutte le mie roadmap sono lì: posso avere un frame per la roadmap, integrare immagini, Figma, scrivere user story che si integrano poi su Jira. Miro è stato rivoluzionario e lo uso ogni giorno.

Michael Luchen

Vero! La migliore roadmap contestuale possibile.

Brandon Blackman

Sì.

Michael Luchen

Ultima domanda: a chi inizia il proprio percorso come product manager, quale consiglio daresti?

Brandon Blackman

Se potessi parlare al giovane Brandon all’inizio, gli direi: accetta il lavoro in startup e fai il product manager anche senza esperienza. Non sapevo nulla di product management, né cosa fosse Agile. Provaci e basta. A chi aspira a fare il PM: trova una startup o creala da solo, anche affiancando al tuo lavoro principale, usando le sere. Metti in pratica Agile creando qualcosa dal nulla. Potrebbe essere un servizio, un prodotto digitale, qualsiasi cosa. Applica i principi Agile creando qualcosa per te stesso. O diventi un unicorno da 1 miliardo di dollari, o non succede niente: ma avrai imparato tantissimo e potrai fare il lavoro che ami mettendo a frutto quelle competenze.

Michael Luchen

Parole sagge. Grazie mille, Brandon, per essere stato con noi e per tutto ciò che hai condiviso sulle roadmap e anche su altri aspetti dello sviluppo prodotto.

È stato bellissimo anche per me. Per chi ascolta: scoprite di più sul lavoro di Brandon su crema.us o su LinkedIn. Ancora grazie per aver partecipato.

Brandon Blackman

Grazie mille a voi per l’invito.

Michael Luchen
E grazie a tutti per l’ascolto!

Lasciate una recensione al podcast, fateci sapere cosa vi è piaciuto, cosa vorreste ascoltare di più, o se c’è qualcosa che non abbiamo trattato e su cui vorreste un follow-up. Seguiteci e unitevi alla nostra community@theproductmanager.com. Grazie ancora a tutti e ci sentiamo alla prossima.