Lezioni dalla Bolla Dot-Com: Come i Leader di Prodotto Dovrebbero Pensare all’IA

Leggi la Trascrizione:

Stiamo sperimentando la trascrizione dei nostri podcast tramite un programma software. Per favore perdona eventuali errori di battitura, poiché il bot non è sempre corretto al 100%.

Hannah Clark: Nelle immortali parole di Bob Dylan, "i tempi stanno cambiando", e un cambiamento di questa portata è... beh, è molte cose. È spaventoso. È entusiasmante. È imprevedibile. Ed è inevitabile. Indipendentemente da come ti senti riguardo all'IA, ha innescato un cambiamento di paradigma in quasi ogni aspetto della gestione di prodotto, soprattutto a livello di leadership. Quali di questi nuovi strumenti dovremmo implementare e come? In che modo impatteranno la struttura e le funzioni dei nostri team? E mentre le nostre organizzazioni cambiano, come dobbiamo cambiare noi insieme a loro?

Il mio ospite di oggi è il meraviglioso Greg Petroff, professore, leader di pensiero nel design ed esperto dirigente il cui curriculum include aziende come SAP, GE Digital, Google, ServiceNow, Compass e Cisco. E mentre Greg e io discutevamo di questi tempi che cambiano prima della registrazione, ha fatto notare che ci siamo già passati, con l'era Dot-Com, ma la differenza sta nella velocità del cambiamento e, di conseguenza, nel ritmo di adattamento richiesto. Ora ascolterete Greg mentre spiega quali strumenti, cambiamenti organizzativi e strategie dovrebbero considerare gli executive in questo momento—perché, dice Bob Dylan, e ci avverte molto bene, "meglio che tu inizi a nuotare o affonderai come una pietra." Iniziamo.

Ben tornati a Il podcast del CPO Club. Sono qui oggi con Greg Petroff.

Grazie mille per essere qui con noi oggi, Greg. Come stai?

Greg Petroff: Sto bene, grazie Hannah. Grazie per l'invito.

Hannah Clark: Sì, grazie.

Quindi cominceremo come facciamo sempre. Mi piacerebbe se potessi raccontarci un po' del tuo percorso e di come sei arrivato dove sei ora.

Greg Petroff: Sì, nella mia carriera ho iniziato come architetto. Ho iniziato nell'architettura molti anni fa. Poi ho ricoperto ruoli nell'ambito del software enterprise, dalla gestione prodotto alla leadership nel design negli ultimi 25 anni. In aziende come SAP, GE, Google, ServiceNow. Più recentemente Compass, sono stato da Cisco e ora in questo momento sto facendo un po' di consulenza indipendente, un po' di leadership nel design frazionale e coaching, e insegno al California College for the Arts.

Hannah Clark: Agenda fitta di impegni. Oggi parleremo di temi importanti, cambiamenti di mentalità che i leader devono adottare per adattarsi a questa nuova era dell'IA in cui ci troviamo e stiamo cercando di orientarci.

Quindi, per iniziare, in passato abbiamo trovato interessanti parallelismi tra il momento attuale dell'IA che stiamo vivendo e l'era Dot-Com, che rappresentò anch'essa un grande cambiamento di mentalità. Quali sono alcune delle lezioni chiave di quel periodo di sconvolgimento tecnologico che sono attuali anche oggi?

Greg Petroff: Sì, penso che ci siano alcune cose in corso. Penso che una sia che l'esperienza non sia necessariamente più preziosa come una volta. Abbiamo una sorta di struttura predittiva di come vediamo il mondo, e si basa sulla nostra esperienza.

E quando iniziamo a guardare al nostro lavoro, usiamo quella struttura per aiutarci a orientarci e fare le cose successive. Ed è utile quando le regole sono coerenti, ma nei momenti di cambiamento, le regole possono cambiare e potresti non accorgertene. E quindi la curiosità è un comportamento molto importante da coltivare proprio ora.

E penso che nell'era Dot-Com ci siano state molte aziende che sono rimaste in disparte e non hanno realmente capito di cosa si trattasse. E poi c'erano alcune persone che non capivano affatto, ma erano curiose e si sono semplicemente tuffate in quell'ambito. Hanno iniziato a creare, e penso che ci troviamo in un momento molto simile dove tutto si muove così velocemente che il modo in cui puoi riuscire a capire come potresti usare l'IA è usarla il più possibile.

Hannah Clark: Sì, con tutto che si sta spostando, questo mi fa anche pensare a come i ruoli tradizionali, quelli che ora percepiamo come tradizionali, in realtà non lo sono mai stati davvero. È tutto cambiato così rapidamente negli ultimi decenni.

Ma puoi approfondire come hai visto cambiare i confini dei ruoli e lo sviluppo del prodotto finora?

Greg Petroff: Ovviamente, dipende dalla situazione. Ogni azienda ha la sua cultura e i suoi punti di forza, come Google, che ha una forte cultura ingegneristica, e le altre discipline sono importanti, ma è l'ingegneria che guida l'azienda. In altre organizzazioni il design è più centrale, in altre ancora la gestione di prodotto.

Quindi, le organizzazioni culturalmente hanno delle abitudini. Inoltre, alcune organizzazioni sono molto ortodosse nelle definizioni dei ruoli e dicono: "questo è ciò che fai e non ti occupi di altro fuori da questo ambito". Questo è ciò che fa il tuo pari cross funzionale. E penso che abbia funzionato per un po'.

Non sono mai stato molto ortodosso. Sono sempre stato uno di quelli che ha superato i confini nella mia carriera. A volte sono stato accusato di essere un designer che fa product management o un product manager che fa design. Dal mio punto di vista si tratta di cultura di prodotto. Credo che una delle cose che sta succedendo ora sia che i tool che utilizziamo sono molto diversi da quelli di una volta.

Sono molto più veloci e più accessibili a un pubblico più ampio. Così, chi prima forse era in un silo, ora può iniziare a fare parte del lavoro che era competenza di un pari. La domanda è: dove si collocano quei confini? Quindi il diagramma di Venn si sta un po' restringendo su se stesso.

E penso che il futuro saranno team dove c’è il concetto di persone "a T": molto profonde in un’area ma capaci di muoversi anche orizzontalmente. E quasi mi sembra che diventerà una doppia T: troveremo questi ibridi, qualcuno che sa progettare e scrivere codice o un leader di prodotto che viene dal design, o un ingegnere appassionato di product management.

Quindi, l'importante è che in qualsiasi organizzazione ci si trovi ci sia una conversazione aperta sugli strumenti e ciò che abilitano, e su chi coordinerà certi aspetti del ciclo di vita dello sviluppo prodotto. E offre l’opportunità di passare da una cultura guidata dall’ingegneria o dal prodotto o dal design a una cultura degli outcome di prodotto, dove tutti contribuiscono in base alle abilità che portano sul tavolo.

Vedremo quindi organizzazioni ibride che potranno apparire molto diverse col tempo; nell'ambito della gestione progetti, la definizione di cosa costruire diventerà molto più importante perché realizzare cose è sempre più semplice. La mentalità incrementale dell’aggiungere funzionalità si può applicare, ma con lo stesso sforzo potresti creare molto più valore per utenti e clienti, e immaginare cose che prima sembravano impossibili.

Quello che mi interessa è come creare spazio perché queste partnership cross funzionali diventino più coraggiose in ciò che provano a realizzare, perché oggi effettivamente è più facile fare certe cose.

Hannah Clark: Oh, ok. Hai aperto tre filoni qui. Ci sono gli strumenti, i ruoli che cambiano ed evolvono e la leadership organizzativa. Abbiamo tre strade. Scelgo quella degli strumenti per prima e poi torniamo sulle altre.

Parliamo un po' di strumenti IA e sviluppo prodotto, visto che hai accennato che gli strumenti stanno cambiando, e qui si tratta di discernimento, perché abbiamo moltissimi strumenti disponibili e siamo in un bivio interessante, dobbiamo esercitare un buon giudizio su quali strumenti scegliere e come.

Hannah Clark: Come aiuti i team a sviluppare quel buon senso o istinto su quando e come usare gli strumenti IA?

Greg Petroff: E c’è anche una conseguenza rilevante nel discernimento. Quando usi uno strumento IA, credi alla risposta che ti dà? O hai la capacità di co-creare, di lavorare insieme all’IA in un modo in cui andrete insieme verso l’obiettivo? Penso che parte di tutto questo sia la sperimentazione. L’ambito si muove molto velocemente, ma ci sono aree che subito hanno senso. Penso nella product discovery.

Oggi esistono molti tool che ti permettono di creare modelli rag personalizzati sulle tue ricerche e, per organizzazioni con anni di ricerche alle spalle, puoi prendere tutte le trascrizioni e creare modelli da interrogare. È quasi avere una persona virtuale.

So che è controverso. E non la chiamerei una persona virtuale. È semplicemente rendere la base di conoscenze più accessibile, più facile da consultare. Quando inserisci nuovi membri nel team, li aiuti a crescere sulla conoscenza del dominio perché hanno a disposizione questo corpus così utile.

Non è semplice da fare, ma una volta fatto, l’ho sperimentato anch’io con amici. E il fatto che emerga conoscenza e insight che forse sono dati per scontati, ma magari non erano mai stati descritti in modo chiaro, è molto interessante. Sul lato design, parlando di strumenti, ci sono molte novità in area Figma, che è uno strumento nuovo, fino a 5 anni fa non esisteva, e ha cambiato il modo di lavorare.

Credo che i team stiano lavorando direttamente in alta fedeltà, e non sono sicuro sia sempre la scelta migliore, perché a volte la bassa fedeltà ti permette di vedere cose che altrimenti, osservando un prodotto "finito", non cogli. Ma è molto più veloce: i team possono iterare e produrre rapidamente, così che, quando il team design riesce a produrre più in fretta di quanto pensi, spesso è utile per i team di prodotto "produrre per pensare", non "pensare per produrre".

Quello che intendo è che le conversazioni e gli errori che fai mentre crei un artefatto ti danno informazioni sull'obiettivo e sul problema del cliente in modo molto più efficace che parlare e basta. Un’immagine vale più di mille parole. Stiamo vedendo che i team di design che lavorano con i team di prodotto molto presto e semplicemente iterano, senza creare il prodotto finale, ma soltanto provando, possono praticamente sostituire le PRD con un prototipo e validare questo prototipo, avendo così qualcosa di valore in tempi e costi ridottissimi rispetto a prima.

E questo è solo un esempio. Dal lato ingegneria, invece, si sperimenta con tool come Copilot e strumenti che permettono di andare più veloci. Siamo ancora agli inizi, perché molti ingegneri sono dubbiosi sulla loro utilità. Ma il fatto che porzioni di codice possano essere scritte insieme ti libera così da poterti concentrare su problemi più complessi. Tutto questo è disponibile e la domanda che dovremmo porci collettivamente è: come possiamo mettere in discussione il nostro lavoro? Molti di noi provano a integrare questi strumenti nei nostri prodotti, ma capiremmo meglio che risultati possono portare se li usassimo anche nei nostri processi produttivi quotidiani.

Hannah Clark: Sono d'accordo. Penso che ora stiamo esercitando il muscolo dell'uso degli strumenti IA come estensione della nostra esperienza e non come sostituto della conoscenza istituzionale, che resta fondamentale, come dicevamo prima. Siamo nella posizione di supervisionare strumenti IA che svolgono alcuni dei compiti che erano di nostra competenza e che ancora ci riguardano.

Questo si lega bene alla conversazione sul valore della conoscenza istituzionale, soprattutto nei team di ricerca. Penso che la ricerca sia un'area dove l'uso dell'IA è controverso. Come vedi evolversi il rapporto tra competenza umana e gestione della conoscenza alimentata dall'IA?

Greg Petroff: Sì, l’ho accennato prima. La maggior parte dei team di ricerca ha un corpus di contenuti, e anni fa era difficile condividere questa conoscenza. Facevi una ricerca, presentavi i risultati e poi nessuno ci si tornava più, finiva in archivio.

E la ricerca è anche temporale, può essere valida per un periodo e poi cambiano i comportamenti o arrivano nuove tecnologie ecc. Tuttavia, in grandi organizzazioni c’è tanto materiale ma pochi ci accedono.

Il team ricerca vorrebbe che più persone ne usufruissero perché porterebbe a migliori insight e quindi migliori risultati. Trovo interessante costruire grafi di conoscenza personalizzati sul corpus e permettere a chiunque di porre domande.

Questo non sostituisce la ricerca: consente solo di vedere quali insight sono emersi collettivamente. Condivide questa conoscenza tra più persone in azienda, non è solo del ricercatore. Democratizza l’accesso.

Aiuta tutti a capire chi stiamo servendo e perché. Il team ricerca continua intanto a svolgere il suo lavoro. Credo molto nella ricerca qualitativa e in metodi quantitativi dove si strumentalizza ecc., e non darei mai tutto questo all’IA.

La capacità di sintetizzare questa conoscenza e condividerla sarà cruciale. Ho sempre visto democratizzare la ricerca come qualcosa di positivo, anche se è un tema controverso. Quando ho visto che qualcosa diventa più accessibile, la richiesta di expertise cresce.

Intendo che più persone vedono gli insight, più li vogliono. E più sentono di avere bisogno di esperti sul team che sappiano condurre bene quelle attività. Quindi sono interessato a capire come tutti possano essere immersi nella conoscenza di chi servono, e sfruttare queste informazioni per creare prodotti migliori.

Hannah Clark: Abbiamo già trattato un po’ questo argomento, perché credo sia un’area davvero interessante in cui l’IA innova. Abbiamo avuto una puntata popolare sulla product discovery abilitata dalla Gen AI, con Craig Watson, fondatore di Arro, tempo fa; lì si è approfondito come questi strumenti aiutano davvero. Mi piace quello che hai detto sulla persona virtuale, perché non si tratta davvero di sostituire lo sviluppo della persona, ma più che altro di rendere quei dati interattivi; ciò che abbiamo sviluppato e imparato. Abbiamo fatto altre puntate sugli strumenti di analisi prodotto abilitati dalla Gen AI, come con Mo Hallaba (CEO di Datawisp) e Mario Ciabarra di Quantum Metric.

Come hanno spiegato, democratizzare i dati e renderli più disponibili e interattivi per chi non è data scientist è fondamentale. E sono d’accordo: quando i dati sono accessibili, qualsiasi stakeholder in azienda può capire davvero come quei risultati ci avvantaggiano e interagire con essi in modo rilevante per il proprio ruolo. Si apre così la porta a una vera cultura “data informed” se usiamo questi tool efficacemente. È un momento eccitante nel prodotto.

Greg Petroff: Sì, vedremo cosa succederà. L’expertise di dominio è molto rara e non è universale. Inoltre è gerarchica. In alcune aziende chi ha più expertise ha più influenza (non dico potere) su cosa accade. In un’organizzazione dove tutti hanno accesso a una comprensione più profonda di chi si sta servendo e perché, sarà interessante vedere cosa succede, e se rompe alcune convenzioni strutturali interne.

L’ultima cosa, mi cacciano a volte per questo, ma credo che il ruolo della ricerca sia de-rischiare le decisioni sul prodotto. Sì, dobbiamo capire ed empatizzare con gli utenti e i loro bisogni e ciò che conta per loro.

La leadership di prodotto fa assunzioni su quali funzionalità porteranno benefici agli utenti e creeranno un ottimo prodotto per cui pagheranno. Spesso queste ipotesi sono deboli, ma costose da realizzare, e non sono validate in modo da garantire un risultato atteso.

Ecco cosa dovrebbero fare i ricercatori: non solo dare la comprensione generale di chi stiamo servendo, ma anche trovare nella catena dello sviluppo le aree dove ci sono molte ipotesi poco validate e usare i loro punti di forza per dare certezze, così che la leadership possa fare scelte più sicure.

Hannah Clark: In realtà mi sorprende che dicendo questo ti mettano in discussione, ma non lo dirò a nessuno. Come show siamo davvero dalla parte dei ricercatori UX.

Crediamo portino un valore immenso. È sorprendente che, dovendo investire molti soldi in un prodotto, non si voglia essere assolutamente certi che piaccia al target. Non capisco perché non dovrebbe valere la pena di farlo.

Greg Petroff: Un’altra cosa interessante. Ora abbiamo accesso al cerchio completo, cosa che prima non era possibile. Abbiamo strumenti come Amplitude che—se ben integrati—danno ottime metriche di comportamento, metriche di successo del prodotto, insight sull’utilizzo delle funzionalità.

Per le aziende SaaS, tassi di rinnovo ed analisi di coorti per vedere quali clienti rinnovano con meno sforzo commerciale, ecc. Si possono mettere insieme tutti questi segnali che storicamente erano in mano a customer success, al team di prodotto, a corporate strategy o ai ricercatori.

Vedo un’opportunità per la ricerca di vedere davvero tutto a 360°. Si può così monitorare la salute dell’esperienza, del business, del comportamento dei clienti enz. Era quasi impossibile prima, non è banale neanche ora. Conosco solo pochi ricercatori che sono riusciti a farlo. L’IA può aiutare a unificare diversi set di dati (customer e user success) per ottenere una visione migliore sulla salute del prodotto e su cosa serve dopo.

Hannah Clark: Credo che uno dei maggiori benefici di questi modelli conversazionali sia poterli addestrare con output prima separati e renderli più fruibili: così possiamo porre domande più mirate che prima non era possibile. Come dici, vedremo come andrà, sono sicura che ci saranno errori e difficoltà.

Greg Petroff: Dico un’ultima cosa: quando poi arriva una risposta, un altro motivo per cui serve comunque un team di ricerca è che serve discernimento e bisogna sempre verificare, perché forse i dati non sono buoni e ottieni un insight non reale.

Hannah Clark: Già. Mi chiedo come, affidandoci sempre di più a questi modelli, la qualità dei dati diventerà centrale nella conversazione: i dati che inseriamo sono di alta qualità?

Greg Petroff: Non riesco a immaginare il momento in cui diremo: "la nostra IA pensa che tu ti comporti così. È vero o no?" (ride)

Hannah Clark: Hai toccato temi di adattamento e organizzazione. Mi piacerebbe approfondire la questione dell’incertezza dei ruoli che cambiano, delle competenze chiave che, come contributor o leader, portiamo in squadra, soprattutto quando altre persone arrivano a sovrapporsi a ciò che fai tu.

Ci sono anche tool IA che fanno parte di quei compiti. Come aiutiamo i team a navigare l’incertezza del cambiamento e al contempo mantenere competenze e valore, difendendo l’area di expertise individuale?

Greg Petroff: Metterei tra virgolette il “proteggere il territorio”.

Non so se intendessi proprio questo, però negli ultimi 25 anni credo di aver cambiato carriera 11 volte. Ho iniziato come architetto e facevo grafica 3D, poi media broadcast, poi nell’epoca Dot-Com architetto delle informazioni e interaction designer.

Poi sono diventato product leader, ricercatore. Poi di nuovo interaction designer, poi UX leader. E una cosa curiosa di questo momento è che negli ultimi 10 anni c’è stata stabilità dei ruoli. Molte persone sono cresciute in quest’epoca:

Hanno una definizione chiara del proprio valore, del chi sono, di cosa fanno. Non hanno ancora sperimentato la “terra che cambia sotto i piedi” per via di una nuova tecnologia o di una maniera di lavorare del tutto diversa. Chi come me è lì da abbastanza tempo sa che succede spesso e bisogna essere adattabili. L’expertise è fondamentale: devi sapere in cosa sei bravo. Ai miei coachati dico: punta sui tuoi punti di forza e valorizzali, ma non restare troppo ancorato alla definizione del tuo ruolo. Stiamo entrando in una fase dove contano l’outcome e la definizione del problema.

Nell’esecuzione ci sono molti modi di arrivarci; se difendi con ortodossia la posizione o il ruolo rischi solo di combattere controcorrente. Quindi: sii curioso, resta in evoluzione, impara costantemente e non rinunciare a ciò che ami o che sai fare bene, perché le squadre migliori sono fatte da persone davvero brave in qualcosa.

Ti faccio un esempio: da SAP, 15 anni fa, facevo parte di un team non di design, né di prodotto, né di ingegneria: eravamo "team innovazione". C’erano antropologi, ingegneri, product manager, designer. Ogni progetto assemblava il team, sempre eclettico, e insieme settavamo come avremmo lavorato sul problema. Penso che ci sarà sempre più questo tipo di comportamento in futuro.

Nelle grandi aziende serve una certa organizzazione, aiuta nella delivery, ma nelle piccole saremo molto più agili su strumenti e competenze. Se resti ortodosso su cosa fai rischi di ostacolarti da solo.

Hannah Clark: Hai aperto la porta all’uscita dall’ortodossia, voglio parlare di stili di leadership. Hai osservato che c'è un cambio generazionale negli stili di leadership di prodotto.

Ci stiamo allontanando dall’approccio comand-and-control, top-down, verso qualcosa di più collaborativo. Ora che siamo in vena di aneddoti, hai un esempio concreto di come un simile cambiamento abbia influenzato gli esiti di sviluppo prodotto che hai osservato?

Greg Petroff: Non so quale delle due modalità prevarrà o se coesisteranno, ma ce ne sono certamente due. C’è il modello del leader di prodotto forte che non è totalmente trasparente con l’organizzazione e prende decisioni in autonomia per far avanzare il progetto: un classico comando e controllo. Molte organizzazioni funzionano così. E in passato ci sono stati leader fortissimi che si sono fatti così la carriera, allora chi cresce guarda loro e dice "voglio essere come loro".

Quello che ho visto, soprattutto in grandi organizzazioni, è che in contesti di risorse limitate e incentivi spostati sulla delivery i leader di prodotto competono tra loro per accaparrarsi più risorse.

Se ottengono risultati, ottengono la promozione. Se però non c'è chiarezza su ciò che NON va fatto, tutti cercano di fare il possibile nel tempo che hanno. Non si accorgono però che questa strategia mette sotto pressione il sistema: le risorse sono finite e le impieghi meno efficientemente, con troppo lavoro inserito, si arriva al caos e si torna al comando e controllo per tentare di rimettere in riga il tutto.

Poi c’è l’altra modalità: leader che dicono "entriamo nel progetto, non so cosa faremo, non devo avere tutte le risposte ma metterò insieme un team che apprenderà insieme a me il più velocemente possibile, sperimentando e collaborando".

Questi leader ottengono di più: il team ha più chiarezza, c’è più visibilità, le persone sentono di avere autonomia e ruolo. È una mia osservazione, ma mi sembra che questa modalità sia più diffusa nei PM più giovani o all’inizio carriera. Forse perché sono nativi digitali e più abituati a lavorare con ottimo software e a creare spazio ai vari ruoli per collaborare.

Ho partecipato al Canadian Friends Conference l’autunno scorso e sentire i product leader parlare di come lavorano cross funzionalmente mi ha colpito molto in positivo: era una conversazione aperta, vulnerabile, in cui si ammetteva di non avere tutte le risposte ma si organizzava il team per trovarle. Diverso dal "devo avere sempre la risposta" a tutti i costi, e quindi barcamenarsi finché non si trova.

Ci sono queste due correnti nella comunità prodotto e mi chiedo se i risultati migliori arriveranno da una o dall’altra. Non ho grandi esempi pratici, mi baso su osservazioni di comportamento.

Hannah Clark: Anch'io penso che la cultura lavorativa sia diventata meno gerarchica e più collaborativa. È un cambiamento che apprezzo molto; l'inclusione di vulnerabilità e intelligenza emotiva tra i capi si sta consolidando e produce effetti positivi nel lavoro cross-funzionale. Permette a molti di dare il meglio.

Ma ora ti metto un po’ alla prova, visto che stiamo parlando di questo: sei un leader, un executive con lunga esperienza, hai gestito tanti team. Che strategie hai trovato efficaci per favorire curiosità, sperimentazione e al contempo mantenere standard elevati?

Greg Petroff: La chiarezza è il dono più grande che si possa fare a un team. Non puoi essere trasparente su tutto nella leadership e a volte non aiuta nemmeno, perché ci sono tante vicende aziendali complesse o incomprensibili. Se tutti ne parlassero nessuno sarebbe produttivo. Ma la chiarezza è fondamentale, e anche aiutare le persone a sentirsi proprietarie di quella chiarezza: così capiscono il loro ruolo e come contribuiscono all’insieme. È difficile per le organizzazioni dire NO a qualcosa, ma quelle che sanno chiaramente cosa NON si farà sono avvantaggiate: evitano comportamenti "iperattivi" dove ognuno aggiunge pet project, mentre invece va chiarito "questo non lo facciamo (ora)". Questo aiuta la chiarezza.

Dare feedback in modo cortese ma rigoroso è importante. Creare ambienti dove ci si sente sicuri è vitale, ma allo stesso tempo non devi rinunciare a dare feedback anche duro quando serve. Quando ero in Cisco, da Duo (una startup acquisita), riprendemmo un motto che adoravo: "Sii più gentile del necessario". Vuol dire che se hai un pezzo di spinacio tra i denti prima di una meeting, vuoi che qualcuno te lo dica. Non è personale, è solo un dato. Darsi feedback continuo e tenersi reciprocamente a standard alti, incentrando tutto sul lavoro e non sulla persona.

Così si impara ad ascoltare il feedback senza prenderla sul personale: è un modo per migliorare sé stessi o il lavoro del progetto. Quindi sono due cose che cerco di mettere sempre in pratica: essere il più chiaro possibile e dare il più feedback possibile.

Hannah Clark: Apprezzo molto queste riflessioni. Sono sicura che sei solo umile.

Grazie per essere stato con noi, Greg. È stata una conversazione interessante. Abbiamo toccato temi molto attuali. Spero che riceveremo qualche feedback interessante da chi ascolta. A proposito, dove possono seguirti o mettersi in contatto online?

Greg Petroff: Sono su LinkedIn, mi potete trovare lì. Ho anche una Substack chiamata Improbable Futures. Scrivo un po’ su idee e possibilità. Quindi potete trovarmi in questi due posti.

Hannah Clark: Perfetto. Grazie davvero per essere stato con noi.

Greg Petroff: Grazie a te.

Hannah Clark: Grazie per averci ascoltato. Per altri spunti, guide e recensioni di strumenti, iscriviti alla nostra newsletter su theproductmanager.com/subscribe. Puoi ascoltare altri episodi del CPO Club, ovunque ascolti i tuoi podcast.