La Mancanza di Chiarezza Sta Silenziosamente Uccidendo il Tuo Prodotto?

Leggi la Trascrizione:

Stiamo sperimentando la trascrizione dei nostri podcast tramite un software. Chiediamo venia per eventuali refusi, il bot non è preciso al 100%.

Hannah Clark: È praticamente un cliché, ma succede sempre: dici qualcosa a tre persone e ognuna comprenderà qualcosa di diverso. Non è grave se si tratta di: “Vado a prendere un caffè, qualcuno vuole qualcosa?”. Ma quando stai costruendo un MVP con una disponibilità di tempo sempre più ridotta, o stai cercando di lanciare qualcosa entro una scadenza rigorosa, la mancanza di chiarezza può essere il bacio della morte per una startup.

L’ospite di oggi è Bijan Shahrokhi—fondatore di Product Management Exercises e Product Monkey AI. Bijan ha dedicato la seconda parte della sua carriera ad aiutare i PM ad essere più produttivi e più efficaci nella gestione dei team. E la capacità di portare chiarezza e allineamento a un team di prodotto è fondamentale per queste competenze. Tra poco, Bijan condividerà un processo facile da replicare che richiederà un po’ di tempo iniziale, ma che ha il potere di salvare una startup sull’orlo del baratro. Iniziamo subito.

Bentornati, ascoltatori. Sono oggi in compagnia di Bijan Shahrokhi. È il fondatore di ProductManagementExercises.com e recentemente ha lanciato uno strumento di produttività pensato appositamente per i product manager, chiamato ProductMonkey.ai.

Bijan, grazie mille per essere con noi oggi.

Bijan Shahrokhi: Grazie mille per avermi invitato.

Hannah Clark: Ottimo. Iniziamo sempre nello stesso modo. Ci piacerebbe sapere qualcosa in più sul tuo percorso e su come sei arrivato dove sei oggi.

Bijan Shahrokhi: Certo. Sono un product manager nell’anima. Ho fatto il PM per oltre 10 anni, per puro caso.

Non sapevo nemmeno cosa fosse il product management finché non avevo una startup che non stava andando molto bene. Chiesi a un amico cosa pensasse dovessi fare dopo e lui mi disse “dovresti fare il product manager”. Mi sono detto, aspetta un attimo. Sembra interessante, tipo occuparsi del prodotto e gestire il prodotto. È proprio quello che voglio fare.

Da lì sono diventato PM. Ho fatto diverse cose negli ultimi dieci anni. Nei primi anni ho lavorato in grandi organizzazioni, ad esempio in banca come product manager e poi come strategist. Successivamente, sono stato coinvolto in due startup. Entrambe le abbiamo lanciate dopo il mio ingresso e una è stata acquisita entro un anno e mezzo da un grande player del settore.

L’altra, invece, è stata un progetto di successo, ha raggiunto un valore di diversi miliardi di dollari nei suoi momenti di punta. Tuttora è attiva e sta attraversando una forte crescita. Da alcuni anni, però, mi sono dedicato soprattutto a Product Management Exercises. Recentemente, abbiamo lanciato un altro prodotto per la community del product management chiamato ProductMonkey.ai.

Hannah Clark: Fantastico. Oggi parleremo di chiarezza nelle organizzazioni, argomento che ti sta molto a cuore. Per chiarezza intendo assicurarsi che tutti gli stakeholder siano allineati e condividano la stessa visione di cosa sta succedendo e di cosa va realizzato.

Come si manifesta secondo te la mancanza di chiarezza in un’organizzazione?

Bijan Shahrokhi: Ottima domanda. Il segnale più grande, quello più evidente, che un’organizzazione manca di chiarezza, si osserva quando andando in giro e chiedendo a persone diverse quali siano secondo loro i criteri di successo per il prossimo grande traguardo, si iniziano a sentire risposte diverse.

Faccio un esempio. Supponiamo di lavorare su un prodotto molto tecnico che deve gestire metriche di performance, come latenza, velocità, numero di transazioni al secondo, o il volume di operazioni gestite. Se questi criteri non sono chiaramente definiti da una persona tecnica, potrebbe cercare di sviluppare qualcosa in grado di reggere volumi altissimi di transazioni.

Invece, se interroghi qualcuno di più orientato al business o a contatto col cliente, la risposta potrebbe essere: basta lanciare qualcosa per iniziare a raccogliere feedback. Capisci che manca chiarezza quando dialogando con persone diverse emergono numeri differenti, o ti senti dire “non ci abbiamo mai pensato” o “non ne abbiamo mai parlato”. Questo è un chiaro campanello d’allarme per un PM: sembra che manchi chiarezza.

Hannah Clark: Quindi sembra che tu abbia vissuto in prima persona queste situazioni. Senza fare nomi, puoi raccontare un aneddoto?

Bijan Shahrokhi: Certo. In realtà l’ultimo progetto di cui ti parlavo, quello valutato diversi miliardi di dollari, era una società a pochi mesi dalla fine dei fondi e senza aver ancora lanciato nulla.

Sembrava che il lancio fosse a pochi mesi. Quando sono arrivato, mi dissero che mancavano solo tre mesi. In realtà, ciò che i fondatori avevano in mente era a 5-10 anni dalla realtà.

E anche ciò che gli ingegneri pensavano di consegnare era a mesi di distanza. C’era quindi un’enorme distanza tra le parti. Per questo lavoravano da anni sul progetto: il team tecnico continuava a pensare di essere pronto, i fondatori o le figure business guardavano il risultato e pensavano “non è quello che avevamo in mente”. Rivisitavano cosa bisognava costruire, il team tornava a lavorarci, finendo delusi e sentendosi poco utili all’azienda.

Cosa ho fatto? Nei primi tre mesi come head of product ho incontrato molti stakeholder per comprendere quali fossero gli attributi o i punti su cui c’era più divergenza.

Ad esempio, ho scoperto che per alcune persone una particolare funzionalità doveva stare nel lancio iniziale, per altri no. Da lì abbiamo iniziato a discutere su questi punti e chiarito se sarebbero stati sviluppati o meno, facendo scelte nette o progettando versioni molto ridotte.

Solo dopo, ci è voluto circa un anno per realizzare una versione semplificata di ciò che si pensava all’inizio sarebbe stato lanciato in tre mesi. Solo ottenere chiarezza su cosa realizzare ci ha richiesto mesi.

Ecco quindi un esempio di come, portando chiarezza, si possa davvero spedire un prodotto, raccogliere feedback dalla community e capire cosa dovrà essere prioritario in seguito.

Hannah Clark: Sì, è davvero un traguardo enorme ridurre un gap di questo tipo. Se allarghiamo lo sguardo, quali sono le implicazioni più ampie di una mancanza di processi di chiarezza nella cultura di un’organizzazione in senso lato, non solo nel team di prodotto?

Bijan Shahrokhi: L’impatto più grave è che spesso non si riesce a lanciare nulla, e questo è un problema enorme. Ci sono grandi progetti che non arrivano mai sul mercato perché finiscono i fondi prima di cominciare a generare ritorni. Questo fenomeno è ancora più forte nei progetti basati su R&D. I progetti di ricerca e sviluppo che puntano a una rottura sono spesso guidati da fondatori con solide basi accademiche.

E da persone con background tecnico e accademico, con tutto il rispetto—anch’io vengo da lì e credo sia un valore—ma accade che si cerchi la perfezione. Si continua ad aggiungere e costruire perché si pensa agli scenari peggiori, che in fase di incubazione di un progetto non sono nemmeno così critici.

Così, alla fine, non si lancia mai e il mondo non vede mai quella visione di nuova tecnologia.

Hannah Clark: Sì, il solito dilemma tra “fatto” e “perfetto”, con i perfezionisti che si scontrano con chi vuole spedire. Un esempio in cui la chiarezza è fondamentale, come dicevi, è lo sviluppo di un MVP, fase in cui ci sono parecchi rischi di fraintendimenti e incidenti, anche devastanti.

Quali sono gli errori più comuni che rischiano di commettere i team che costruiscono MVP, e che rimedi suggerisci?

Bijan Shahrokhi: L’errore più comune delle startup sull’MVP è confonderlo con la consegna di un prodotto rotto e inutilizzabile.

L’ho visto tantissime volte. Da investitore in un prodotto enterprise di cui sono entusiasta, uno strumento che avrei usato volentieri nella mia organizzazione, la più grande difficoltà nell’adottarlo è stata che è pieno di bug, al punto da renderlo inutilizzabile.

Come product leader dobbiamo vigilare su questo e assicurarci che ‘MVP’ non significhi spedire qualcosa che non trasmette il valore del prodotto. L’esperienza d’uso al centro deve funzionare bene, senza intoppi. È lecito ridurre molte cose accessorie, ma bisogna offrire quell’esperienza essenziale.

L’equivoco più grande è pensare che MVP significhi poter spedire qualcosa di rotto.

Hannah Clark: Quindi ci sono quelli che non vogliono aspettare la perfezione e quelli che rischiano l’opposto… ha senso.

Hai accennato ad un processo intenso per ottenere chiarezza nelle organizzazioni. Se chi ci ascolta volesse applicare questo processo, quali passi suggeriresti per allineare tutto il team?

Bijan Shahrokhi: Bella domanda, e ci tengo perché molti su PM Exercises trovano utile questo metodo. A dire il vero, è piuttosto diretto: consiste nel fare il lavoro duro all’inizio, prima di avviare un progetto, seguendo pochi step chiari.

In pratica, passi molto tempo a portare allineamento in azienda seguendo un percorso step-by-step. Solo quando tutti sono allineati si parte col lavoro. Questo approccio è usato anche in grandi organizzazioni, come alcune istituzioni finanziarie.

Quando siamo passati da Waterfall a Agile e Scrum sembrava che non occorresse più chiarezza sulla destinazione finale, ma solo sul prossimo sprint. Non era questa l’intenzione dell’Agile: bisognava consegnare valore ogni due settimane, ma avendo chiaro dove si voleva arrivare nei mesi successivi.

Come lo faccio? Se guido un progetto con poca chiarezza, la prima cosa è fissare incontri one-to-one con gli stakeholder. Devono essere individuali: in gruppo, se un partecipante si esprime su temi delicati, qualcun altro interviene e come responsabile di prodotto si rischia di non cogliere bene il contesto.

Devi ascoltare ognuno, capire il loro punto di vista, in particolare sui trade-off binari (costruire o non costruire X). Chiedi cosa reputano importante per decidere e raccogli tutte le variabili essenziali per loro.

Nell’R&D questo è ancora più delicato: più un prodotto o le sue dipendenze sono tecniche, più vanno consultati gli esperti materia. Dopo i singoli incontri, spesso le tue opinioni sui trade-off si rafforzano o cambiano, e capisci quali aspetti sono più semplici o complessi di quanto pensassi.

Lungo la strada, torni da alcuni invitati a confrontarsi su punti emersi altrove: “Mi hai detto che le tue priorità sono 1,2,3, ma da altre conversazioni queste paure non sembrano fondate. Cosa ne pensi?” Tramite questo ping pong, che richiede tempo, ti accorgi che tanti problemi nascono dalla mancata comunicazione: nessuno aveva mai esplicitato quei trade-off tra tutti e molte cose si chiariscono così.

A un certo punto restano solo poche questioni su cui permangono opinioni opposte—ad esempio metà del team ritiene che la sicurezza sia essenziale, l’altra metà no. Qui organizzi incontri di gruppo, spieghi le diverse visioni e tenti di arrivare a una decisione tramite confronto diretto.

A volte servono approfondimenti tecnici con nuove riunioni e poi si decide. Quando tutte le alternative sono chiare, è molto più facile come team scegliere la direzione o definire le priorità. Allora puoi dire: ecco la nostra strategia o le specifiche o le priorità prodotto.

In pratica: step 1, colloqui individuali per capire ogni prospettiva. Step 2, confronto incrociato finché i dissensi non si riducono o si segnalano per i gruppi. Step 3, discussione di gruppo. Così ottieni una strategia, specifica o lista di priorità coerente.

Per le priorità di prodotto spesso serve chiarire prima l’obiettivo: magari “vogliamo lanciare subito e imparare”. Se tutti concordano puoi procedere col metodo sopra.

Hannah Clark: Mi piacerebbe parlare ancora di priorità di prodotto. Anche con obiettivi chiari, può essere complicato gestire priorità contrastanti. I framework di prioritizzazione sono tantissimi, ma quali hai trovato più utili e applicabili per bilanciare priorità in questi contesti?

Bijan Shahrokhi: Uno degli approcci che uso è attribuire un punteggio alle priorità, valutandole da più punti di vista.

Primo: l’impatto che una funzionalità avrà sui nostri utenti target. Secondo: la probabilità di riuscire effettivamente a generare quell’impatto, perché a volte non c’è certezza che il nuovo prodotto venga davvero accolto positivamente.

Terzo: la facilità di implementazione. La formula mentale è “impatto moltiplicato per la probabilità di impatto più la facilità di realizzazione”. L’impatto è da 1 a 5: cinque massima importanza, uno minima.

Anche la facilità di implementazione è su questa scala: cinque è molto facile da realizzare, uno estremamente complessa. Da qui si ottiene un punteggio. Ciò che mi piace di questo metodo è che è oggettivo e permette di avere dialoghi simili al processo descritto poco fa.

Puoi presentare ai colleghi la tua tabella delle priorità con tutti i punteggi assegnati a impatto ed effort. Da qui si vedono le “top five”. Qualcuno potrebbe farti notare progetti mancanti, altri da spacchettare, o disaccordi sui punteggi. Ma la discussione si sposta sugli oggetti, non sulle persone.

Per di più, dato che non si tratta di stimare la precisa durata dei singoli progetti, ma di valutazioni relative, è più facile convergere su un valore e su quanto effort serva. Così ottieni una lista di priorità chiara su cosa concentrare il trimestre. Quando arrivano nuove proposte, puoi confrontarle col tavolo delle priorità, motivare le scelte, e aggiornare la lista solo alla chiusura di qualcosa.

Chiaramente potrebbero esserci aggiunte—possiamo parlare anche di quello se vuoi.

Ma questo metodo è più oggettivo e facilita la sintesi delle priorità.

Hannah Clark: Apprezzo molto. Abbiamo parlato spesso dell’importanza di depersonalizzare feedback e priorità, così che nessuno pensi che il proprio progetto sia stato messo in fondo per motivi personali.

Questo è davvero un metodo prescrittivo, mi piace molto. Cosa volevi aggiungere a proposito di nuove priorità?

Bijan Shahrokhi: Dicevo che può capitare che qualcuno insista sull’urgenza di una nuova priorità, che risulti realmente importante.

Come gestirlo? Non può essere semplicemente inserito tra le priorità: bisogna decidere se togliere altro dalla lista per non rallentare i progetti già ad alta priorità, quindi la nuova voce entra con il sistema di punteggio. Oppure, si usano risorse aggiuntive dedicate solo a quella nuova attività, così da non rallentare ciò che già si sta consegnando. Questo approccio secondo me distingue un grande PM—c’è chi non lo fa e poi i progetti non vengono spediti.

Un ottimo PM deve tutelare qualità e velocità di delivery, ed essere pronto a rimuovere o riassegnare risorse in caso di nuove priorità davvero importanti.

Hannah Clark: Interessante. Vorrei però cambiare argomento mentre ci avviciniamo alla fine, perché vorrei parlare della produttività, altro tema che ti sta molto a cuore e probabilmente uno dei motivi per cui hai fondato productmonkey.ai.

Hai qualche consiglio sulla produttività in generale per chi ci ascolta, e vorresti raccontarci qualcosa su Product Monkey AI, che è davvero uno strumento interessante?

Bijan Shahrokhi: Certo. Con Product Monkey AI automatizzo uno dei compiti più necessari ma meno amati dai PM: scrivere requisiti dettagliati e criteri di accettazione. Con Product Monkey AI raccogliamo le info sul progetto, sull’azienda, sullo user flow in questione, e con la guida dell’utente usiamo l’AI per fornire requisiti di prodotto dettagliati, criteri di accettazione, scenari di test, persino eventi e metriche a cui prestare attenzione durante lo sviluppo.

Così puoi ricevere una bozza pronta all’80% delle specifiche e dei ticket per sviluppatori e documentazione, lasciando al PM il refinamento del restante 20%. Credo che una delle maggiori possibilità dei PM sia portare chiarezza, e Product Monkey AI può farlo riducendo il tempo per trasmettere chiarezza ai team di sviluppo.

Hannah Clark: Ottimo, sono sicura che chi ascolta troverà molto utile questo strumento. Bijan, grazie ancora per essere stato con noi. Dove possono seguirti online?

Bijan Shahrokhi: Su Twitter o X, ora si chiama così: il mio handle è bijan_sha. Potete cercare anche PM Exercises o Product Management Exercises, troverete il nostro sito e potrete contattarmi lì.

Hannah Clark: Perfetto, grazie ancora per il tuo tempo.

Bijan Shahrokhi: Grazie mille a voi per l’invito.

Hannah Clark: Grazie a tutti per l’ascolto. Per altre riflessioni, guide pratiche e recensioni di strumenti, iscrivetevi alla nostra newsletter su theproductmanager.com/subscribe. Potete ascoltare altre conversazioni come questa iscrivendovi a The CPO Club ovunque ascoltiate i vostri podcast.