Lavorare All’Incontrario Per Andare Avanti (con Jeff Gothelf di Gothelf.co)

Leggi la trascrizione:

Stiamo provando a trascrivere i nostri podcast utilizzando un software. Perdonaci eventuali errori di battitura: il bot non è corretto al 100% delle volte.

Ben Aston:

Essere onesti. I tuoi progetti riescono mai davvero a consegnare ciò che speravi? Potrebbero o dovrebbero? E perché no? Forse perché non hai pianificato? O perché non hai gestito bene il tuo team? O magari perché hai avuto difficoltà a gestire e coinvolgere gli stakeholder? Forse tutte le risposte sono valide. Forse è perché non eravate tutti completamente allineati sull'obiettivo finale e sulla visione del progetto. Quindi continua ad ascoltare il podcast di oggi. Se vuoi imparare come puoi lavorare all’incontrario per andare avanti con più fiducia e meno rischi sui progetti, ridurre le probabilità di fallimento e aumentare le chance di successo.

Grazie per essere sintonizzato. Sono Ben Aston, fondatore di Digital Project Manager. Benvenuto al podcast DPM. Siamo in missione per aiutare i project manager a ottenere grandi risultati, per aiutare chi gestisce progetti a consegnare meglio. Siamo qui per aiutarti a portare il tuo gioco progettuale al livello successivo.

Vai su thedigitalprojectmanager.com per scoprire i nostri corsi e risorse che offriamo attraverso il nostro abbonamento. Questo podcast è offerto da Clarizen, leader nei software di Gestione Progetti e Portfolio a livello enterprise. Visita Clarizen.com per saperne di più.

Oggi sono con Jeff Gothelf. Jeff insegna a dirigenti e team tramite consulenza e coaching da remoto, workshop, keynote e libri a concentrarsi sui clienti, imparare dagli errori e creare una cultura agile che migliori continuamente prodotti, servizi e le modalità di lavoro.

È coautore di diversi libri che probabilmente hai letto o almeno sentito nominare: Sense and Respond; Lean UX è sicuramente il più famoso. Lean vs agile vs design thinking. Di recente ha co-fondato Sense and Respond Press, una casa editrice che pubblica libri sul business della trasformazione moderna. Ciao Jeff, grazie per essere qui con noi oggi.

Jeff Gothelf:

Ciao Ben, grazie per avermi invitato al programma.

Ben Aston:

Vorrei iniziare parlando di progetti, e so che tu hai una forte orientazione a prodotto, ma per noi PM gestire i progetti spesso significa lavorare in programmi più ampi o su una roadmap di prodotto.

Sono curioso di sapere come pensi che noi come leader di progetto possiamo orientare noi stessi e i nostri team verso un approccio più iterativo. So che hai appena scritto un post sulle 10 principali obiezioni al fatto che Agile sia fantastico, ma non funzionerà qui. Quindi voglio parlare di alcune delle sfide che noi digital project manager affrontiamo e del perché.

Fondamentalmente penso che i clienti e tutti gli stakeholder con cui lavoriamo gradiscano l’idea di lavorare in modalità agile. Possiamo discutere cosa significa “agile”, se come framework di consegna o più come un mindset. Parliamo dell’approccio mentale all’agile.

Penso che una delle sfide, ne voglio elencare tre. Primo, la sfiducia del cliente; secondo, requisiti troppo dettagliati; terzo, mancanza di budget e tempo. Quindi clienti che vogliono essere agili, ma senza budget o tempo adeguato.

Clienti con requisiti dettagliatissimi e la sfiducia verso l’agenzia o il team: non si fidano abbastanza per lasciare andare e fidarsi davvero del processo. Quindi, tre sfide. Da dove vuoi iniziare?

Jeff Gothelf:

Parliamo prima del cambio di mentalità. Perché quella è la cosa più importante, specialmente per i digital project manager. Se vogliamo costruire buoni team, prodotti, servizi, aziende e clienti di successo, è importante capire la differenza fondamentale nello sviluppo di prodotto digitale di oggi.

La differenza rispetto a 10-15 anni fa è che oggi il software è continuo. Non andiamo più a comprare una scatola con dentro un software. Ci abbonaimo, lo installiamo e si aggiorna automaticamente.

Continua a migliorare nel tempo. Non vai a comprare la versione nuova di Facebook o Pinterest o Amazon: si migliora e cambia nel tempo. Ed è questa la differenza tra pensiero progettuale e pensiero di prodotto. Oggi costruiamo sistemi continui: ogni ciclo – che si chiami sprint o iterazione – possiamo decidere come migliorare il sistema. Aggiungiamo funzionalità? Ottimizziamo quelle esistenti? Togliamo qualcosa?

Si può fare di tutto, ma queste sono le tre macro-categorie. La cosa più importante è che questi processi non finiscono a una data certa: gestire un progetto fino al lancio è solo l’inizio della conversazione con il pubblico target, non la fine del prodotto.

Ben Aston:

Esattamente. Come digital PM, una delle difficoltà nel dialogare coi clienti per un lavoro più agile è spiegare: “Pagaci un team dedicato per un periodo così lavoriamo insieme.” Ad esempio: lanci il sito web, poi lo iteriamo.

Proprio come nel software che aggiorni continuamente. Ma qui serve fiducia: chi paga deve credere che ne ricaverà valore. Come project manager, come guidiamo i clienti attraverso quel gap di sfiducia, quando i deliverable sono incerti?

Jeff Gothelf:

C’è molto su cui riflettere. Cominciamo dalla base: che business fai? Devi chiedertelo, sia come fornitore che come cliente.

Vuoi davvero aiutare i tuoi clienti a ottenere risultati, oppure a consegnare una lista di requisiti? Perché, come dicevi, c’è incompatibilità tra “ecco i requisiti ma sii agile nel realizzarli”.

Questo non funziona. Esiste uno spettro, imparato dal mio collega Jeff Patton, che aiuta molto: da un lato c’è il dottore, dall’altro il cameriere.

Sfido le aziende di servizi a capire dove si posizionano. Se sei cameriere, porti esattamente ciò che ti viene richiesto.

Ben Aston:

Certo.

Jeff Gothelf:

E se non lo mangi, o non ti piace, non è un mio problema. Hai chiesto bistecca, insalata e Coca: voilà. Ci sono tante aziende così: mi dai 100mila, io ti costruisco l’arca. All’altro estremo, il dottore.

Al dottore non dici quali medicine prescrivere, lui lavora come consulente per migliorarti, per raggiungere i tuoi KPI, metriche, risultati.

Quindi: dove sei su questo spettro? Essere agili è molto più facile dal lato dottore. Le metriche di successo sono completamente diverse. Lato cameriere: il successo è l’output: “Hai consegnato ciò che ti ho chiesto nei tempi e budget? Sì? Ottimo.” Non c’è agilità in questo. Lato dottore: il successo è l’outcome, il cambiamento nel comportamento del cliente.

Hai portato i clienti a comprare di più? Passare più tempo? Parlare di te? È qui che l’agile brilla, quando c’è incertezza e non si sa quale soluzione produrrà il risultato voluto.

Quindi, se lavori come dottore, l’agilità ha valore. E non puoi portare agilità a meno di allontanarti dal ruolo di cameriere e avvicinarti a quello di dottore.

Ben Aston:

Quindi si tratta di far fare ai clienti/stakeholder un passo oltre il controllo e la fiducia. Quando alleni le aziende, come le aiuti a guardare oltre i requisiti e ad accettare l’incertezza? A valorizzare il mindset agile?

Jeff Gothelf:

In modo rispettoso, devi chiedere “perché?”. Se un cliente ti chiede: “Voglio queste 10 funzionalità per venerdì, quanto costa?” tu devi saper chiedere, con rispetto: “Perché le vuoi?”

Devi portare i clienti a trasformare quei requisiti in una dichiarazione di problema. Ad esempio: “Voglio l’app mobile entro venerdì.” Chiedi: “Perché?” – “Perché i nostri numeri di commercio su mobile sono bassi e dobbiamo aumentarli.” Allora il vero problema è incrementare le vendite da mobile del 15%. Ecco come si passa da “sviluppa app mobile” a “aumenta vendite mobile del 15%”.

Così togli il requisito rigido e forzi l’agilità: testare, sperimentare, migliorare, iterare, fino a raggiungere il risultato. Questo è il vero successo, non semplicemente “rilasciare l’app”.

Puoi essere il miglior manager del mondo, ma in media un bravo product manager ha ragione il 30% delle volte! Quindi non conviene seguire ciecamente le richieste, ma usare un processo che scopra quale soluzione ti avvicina davvero al risultato.

Ben Aston:

Certo, ribaltare la richiesta da elenco di funzionalità a problemi da risolvere consente di esplorare, testare e iterare, gestendo perfino quei requisiti troppo dettagliati che dicevo prima. Sull’ultimo punto: secondo te la mancanza di budget e tempo è una ragione valida per cui l’agile non funziona?

Jeff Gothelf:

C’è un grosso fraintendimento: l’agile non riguarda il budget, ma la mitigazione del rischio. Significa imparare in fretta se stiamo seguendo la strada giusta, e se necessario cambiare rotta quanto prima. Quindi, se il team si adatta ai feedback di mercato, quello è agile, e non dipende dal budget. L’alternativa è spendere 75.000 per una app in un mese. Funzionerà? Chi lo sa! Se non funziona, hai sprecato tempo e denaro. Questo è il rischio di un approccio waterfall predittivo.

Ben Aston:

Ma tutto dipende da chi fa la richiesta. Se voglio bistecca, insalata e Coca per 30 dollari, anche se non è la cosa giusta per me, è quello che voglio, punto.

Jeff Gothelf:

Certo, ecco perché vai dal cameriere. Il dottore, invece, tiene ai tuoi KPI, se gli chiedi bistecca, insalata e Coca, lui ti dirà di no, il suo obiettivo non è servirti ma farti stare meglio.

È una questione di modello di business. L’agile richiede cambiare il modello e non tutte le aziende sono pronte a capirlo.

Ben Aston:

Richiede maturità da parte di chi riceve il lavoro. È una vera sfida per noi PM in agenzia: bisogna ribaltare la richiesta, mettersi il cappello del dottore e togliersi quello da cameriere. Tu hai scritto un ottimo post sulla centralità del cliente e la tecnica del press release del futuro, derivata dal “working backward” di Amazon e focalizzata sugli outcome.

Serve per gestire il rischio, collaborare, e non voglio spoilerare il post ma, secondo la tua esperienza, questa tecnica come aiuta davvero? Che differenza fa nella pratica scrivere un comunicato stampa del futuro?

Jeff Gothelf:

Prima di tutto ti costringe a immaginare un futuro in cui hai avuto successo, ti fa riflettere su cosa ti ha portato quel successo. La variazione che propongo nel mio articolo mette al centro il cliente e non solo “abbiamo lanciato una novità e fatto soldi”.

Si tratta di: l’abbiamo lanciata, questo è stato il cambiamento nei comportamenti dei clienti, questi sono stati gli outcome. Per arrivarci abbiamo dovuto pensare anche a come portare valore al cliente e coinvolgere tutta l’azienda.

La domanda è: facendo una specie di “premortem”, quando lanceremo questa cosa e sarà un successo, come lo sapremo? Quali ostacoli avremo dovuto superare?

Una conversazione rara a inizio progetto: di solito si lavora per consegnare in tempo e budget. Qui invece il successo è un processo che fa crescere i clienti e quindi l’azienda. Se usi questa tecnica, puoi filtrare le decisioni: “questa cosa ci porta a quell’obiettivo?” Se no, non la facciamo.

Ben Aston:

Per chi non conosce il post: si tratta di immaginare il futuro e indagare il product-market fit, la desiderabilità, la fattibilità, la sostenibilità del business model. È uno strumento di valutazione del rischio potentissimo. Ma mi chiedo: una volta scritto questo comunicato, come puoi validarlo? Tanto più che come dicevi, spesso abbiamo ragione solo nel 30% dei casi!

Jeff Gothelf:

Serve come aspirazione e obiettivo. Stiamo provando a prevedere il futuro, quindi inevitabilmente sbaglieremo qualcosa. Ma si tratta di predire cosa significa successo, ostacoli e come li supereremo. Poi dobbiamo perseguire quella storia, e se cambierà sarà per motivi validi e oggettivi. Restano il nostro riferimento fino a quando non avremo evidenza dal mercato che quei criteri non funzionano. A quel punto, cambiamo.

Ben Aston:

Possono esserci limiti a questa tecnica? Può limitare la creatività del team?

Jeff Gothelf:

Il problema più grosso che vedo è che i team non sono abbastanza creativi o ambiziosi. Rendono il documento troppo “sicuro”, mirano basso. Il rischio vero è non anticipare i problemi più grandi, non puntare in alto negli obiettivi. Ho modificato la tecnica di Amazon con due cambiamenti: uno, l’originale non era focalizzato sugli outcome – cioè cambiamenti misurabili nei comportamenti dei clienti. Due, non considerava le sfide collaborative: nessun prodotto viene lanciato senza passare da legale, finanza, marketing, operations, compliance eccetera. Per centrare l’obiettivo, serve il coinvolgimento di tutti questi reparti molto prima del rilascio. Questo spesso manca e voglio che i team ci riflettano.

Ben Aston:

È potente: non solo outcome, ma anche processo e collaborazione. Spesso il problema non è negli obiettivi ma nella comunicazione. Vai a leggere il post di Jeff su “working backward”.

Vorrei ora parlare un po’ dei processi. Hai lavorato nella consulenza, in startup, agenzie, e ora per conto tuo. Come hai visto evolvere processi e metodi per la delivery?

Ovviamente abbiamo l’evoluzione dell’agile, ma ci sono lean, design thinking, service design… Come vedi il futuro di queste tecniche?

Jeff Gothelf:

Secondo me, col tempo l’agilità (con la “a” minuscola) diventerà la norma ovunque. La pandemia sta accelerando questo trend: le aziende già agili sopravviveranno, quelle “monolitiche” no. Solo gestendo team semi-autonomi che imparano e si adattano, condividono il sapere e agiscono sulla base delle evidenze sei in grado di reagire alle crisi e sopravvivere. Magari fra 20 anni parleremo di altri nomi, ma non vedo un futuro di successo senza centralità del cliente, apprendimento e miglioramento continui. Queste sono le filosofie chiave dell’agilità.

Ben Aston:

Parlando di framework: sei molto legato a Lean, ma ora ci sono tecniche specifiche come design thinking, service design, ecc. Alcune sono assai prescrittive. Da praticante, servono davvero tutte? Come vedi l’integrazione?

Jeff Gothelf:

Nel mio libro breve “Lean vs Agile vs Design Thinking” la tesi centrale è che sono brand diversi della stessa filosofia di fondo. Cambia il nome, il ritmo, magari le attività, ma alla base sono molto simili. Bisogna trovare una ricetta che funziona per la propria organizzazione, non seguire una ricetta ciecamente. L’obiettivo non è implementare una ricetta, ma aumentare l’agilità organizzativa. Detto in metafora culinaria: da principiante segui le ricette, poi impari, personalizzi, aggiungi ingredienti, e infine diventi chef, cioè sai muoverti in qualsiasi contesto. Così un team maturo diventa agile di default, sa scegliere le tecniche corrette e non si preoccupa della “ricetta”. Se ti leghi a una sola metodologia, rischi il fallimento: la ricetta non è la destinazione, ma solo il primo passo verso l’agilità.

Ben Aston:

Assolutamente. È per questo che è preoccupante sentire qualcuno dire “ma qui il manuale prevede…”: il processo deve essere soggetto a iterazione e miglioramento.

Ora, dal tuo libro Sense and Respond e dalle tecniche adottate dalle organizzazioni, ci sono pratiche che vedi efficaci nelle aziende, specialmente nel mondo COVID?

Jeff Gothelf:

Il vero pezzo mancante spesso è la struttura di incentivazione. Puoi seguire tutte le ricette che vuoi, ma se le persone sono pagate per consegnare feature (non per raggiungere outcomes), consegneranno feature. Come misuri il successo di una persona? Se non misuri e incentivi curiosità, apprendimento, miglioramento, tutto il resto non avverrà mai. Serve attribuire parte della valutazione alle performance (OKR) e legarla all’incentivo. Solo così la trasformazione è reale.

Ben Aston:

Quindi parli di collegare incentivi agli OKR? O più in generale?

Jeff Gothelf:

Proprio così: gli OKR diventano la misura del successo di team e individui, parte della revisione performance e dei bonus. “Hai raggiunto i tuoi OKR? Allora vieni premiato così.”

Ben Aston:

Ho visto un approccio interessante: usare “scorecard” di ruolo invece che job description, in modo da dare chiare metriche a ognuno. Scegliere le metriche giuste può essere difficile, a volte si realizzano metriche che sembrano buone ma poi non portano il risultato sperato.

Tuttavia, rimanendo concentrati sui risultati si mantengono orientati all’outcome. Parliamo del tuo corso Scrum: hai sviluppato un corso su UX all’interno dello Scrum. Spesso chi lavora in agenzia fatica a integrare ricerca UX in Scrum, che sembra pensato solo per sviluppo. Come vedi tu la collaborazione tra design e scrum?

Jeff Gothelf:

Questa è proprio la sfida che il corso “Professional Scrum with UX” (PSU) affronta. Guardiamo in modo pragmatico a cosa è Scrum oggi, e come va adattato per sostenere pratiche, come design e ricerca, non considerate quando Scrum è nato ma oggi fondamentali. Nel corso affrontiamo: cosa inserire nel backlog, come scrivere storie, chi fa cosa, che succede durante lo sprint, quanto sprint dedicare all’apprendimento rispetto alla consegna, ecc. In sintesi, serve una collaborazione cross-funzionale: i designer devono essere membri full-time del team; la scoperta vale quanto la delivery; e spesso la scoperta e la ricerca devono essere fatte anche da non-designer. E questo deve andare bene a tutti. Questo è il senso alto del corso.

Ben Aston:

Da sempre contesto la prescrittività di Scrum: è solo una cornice, uno starting point. Che ne pensi del partecipare a framework così prescrittivi pur sapendo che vanno adattati?

Jeff Gothelf:

Lavorando con scrum.org, loro erano disposti a cambiare posizione — già un risultato. Con altri non c’era margine: “Questo è Scrum, punto”. Mentre qui c’è stata flessibilità e questo conta. In secondo luogo, questa è una ricetta: se non sai da dove partire, inizia con questa, poi modifica per il tuo contesto unico. Modifica, migliora, personalizza, ma inizia da qui: ha funzionato per noi.

Ben Aston:

Giusto. Capire che le framework servono come base flessibile, non come dogma. Alla fine, non verrai giudicato su quanto hai seguito il framework, ma su quanto hai raggiunto gli outcome desiderati: questo è il tema di oggi.

Jeff Gothelf:

Piacere mio, Ben. È stato un piacere. Grazie dell’invito.

Ben Aston:

E voi? Quali sono i vostri consigli e trucchi per portare valore? Avete già provato la tecnica del comunicato stampa futuro? Scriveteci nei commenti con i vostri fallimenti e successi!

Se volete imparare di più e far crescere la vostra carriera, unitevi alla nostra community DPM Membership su thedigitalprojectmanager.com/membership dove accederete a Slack, template, workshop, AMA, office hour, ebook e tanto altro. Se il podcast vi è piaciuto, iscrivetevi e restate in contatto su thedigitalprojectmanager.com. Alla prossima, grazie per averci ascoltato.