Quando pensi al Canada, una fonte di cose può venire in mente.

Ma sapevi che quando scegli il Canada per propulsare le tue affare, scegli anche di far beneficiare la tua compagnia da uno dei più bassi costi di G7? Non importa dove si trovi la tua compagnia, ci faciliterà il suo sviluppo qui.

Investisci al Canada, il tuo secondo casa.

Dicovri altri vantaggi su investircanada.ca.de Sottotitoli e revisione a cura di QTSS vi dico altro se non vi siete iscritti ancora mi rendete triste detto questo io direi che è arrivato il momento di presentarvi l'ospite di oggi benvenuti su GITBAR il podcast dedicato al mondo dei full stack developer i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo l'ospite di oggi è un product manager coi fiocchi prima però di svelarvi il nome vi racconto quello che è successo e come sono arrivato a questa persona che poi andremo a svelare oggi.

In realtà sono arrivata a questa persona tramite Alessio l'altro giorno un po di giorni fa insomma gli ho chiesto Ale ho bisogno di una persona che sia king di prodotti digitali che sappia come si gestisce un prodotto sappia come si parla con gli stakeholder conosca insomma questo argomento e che ci possa insomma venire a raccontare ce lo possa venire a raccontare qua su github.

Lui mi ha detto fermo Mauro c'ho io la persona giusta che fa il caso nostro era il mio vecchio product owner ed è un king sull'argomento infatti oggi abbiamo con noi Marco Loche product manager a Hootsuite ciao Marco ciao Mauro grazie per l'intro ho dimenticato qualcosa perché so che fai 70.000 cose in realtà diciamo che la cosa principale sono papà di tre bambini e poi si product manager a Hootsuite con un grande impegno mi prende l'impegno lavorativo bell'esperienza con Alessio abbiamo lavorato diversi anni insieme grazie Alessio per averci messo in contatto sono molto contento che mi abbiate invitato.

Ringraziamo il nostro buon Dr.

Blaster che oggi ha anche compiuto gli anni e l'ho visto un po' triste in realtà dice sto invecchiando sto invecchiando tranquillo quando arrivi a 40 poi non li conti più però oggi vogliamo parlare un attimo del ruolo di product manager e di product owner la prima cosa che ti voglio chiedere però è questa io so che tu hai un passato da software engineer si esatto, infatti dall'intro di Gitpar mi sono sentito di nuovo a casa sono laureato in ingegneria informatica ho sviluppato per 15 anni fino a qualche qualche anno fa full stack sviluppavo appunto sia server side sia le ultime cose che ho sviluppato era un React.js e niente sì quindi ero poi a un certo punto sono tornato perché dico tornato perché in realtà mentre negli anni di esperienza di sviluppatore in realtà in parallelo ho creato un paio di società di cui uno che oggi continua a esistere non faccio più direttamente parte sono sempre socio ma società che sviluppa corsi learning ma appunto è lì e lì dove ho fatto le prime armi nella gestione di prodotto lancio di prodotto e di azione eccetera e quindi product management era un po' una del secondo cappello che avevo e in Utsuit mi hanno dato la possibilità di ritornare a fare quell'attività.

Ti faccio una domanda se è troppo personale glissa tranquillamente frega tene ma venendo da un passato da sviluppatore cosa hai messo nella bilancia quando hai fatto la scelta e hai detto mi sposto più sul prodotto quando hai fatto questo tipo di valutazione? Comunque quando si è conosciuto diciamo che all'inizio in una piccola realtà essendo stato un freelance alla fine scelte di prodotto le facevo facendo anche lo sviluppatore.

Quando entri in una società come Utsuit e prima di Utsuit ad espresso che è la startup che è stata acquistata da Utsuit inizi a capire quanto è importante strutturare pianificare e crescere anche nel ruolo di prodotto per andare a capire poi i tuoi utenti, i tuoi clienti e quindi la parte veramente che trovo affascinante del product management è avere questa visione strettamente legata al business, strettamente legata a risolvere problemi che poi era quello che mi appassionava come ingegnere risolvere problemi, creare soluzioni però c'è un c'è quel lato veramente di focalizzarsi sul problema che vuoi risolvere e andarlo a analizzare trovare la validazione necessaria per poi essere sicuro che quella sia la giusta strada per poter portare avanti il business.

Quindi spostare il focus da come lo stai facendo a cosa stai facendo no? Sì, esatto e anche perché a volte quel cosa può essere non richiedere sviluppo a volte in realtà quando da product manager tiro in quando inizi a parlare con i clienti inizi a capire che a volte ci sono soluzioni che tu puoi fornire senza neanche dove sviluppare, sto pensando che a volte puoi pensare di aiutarli fornendo materiale educativo quindi magari nel tuo prodotto fornire tutto quello che è knowledge base, blog post che gli aiuta a risolvere problemi quotidiani senza per forza dove sviluppare una soluzione software.

Quante volte c'è capitato no di sviluppare in funzione di un processo del cliente e poi renderci conto che alla fine il processo stesso era over ingegnerizzato per il cliente quando magari un'analisi più dettagliata del processo lato cliente ho detto processo tipo sette volte va beh perdonatemi ma avrebbe evitato magari mesi e mesi di lavoro su una feature che alla fine.

Sì quello sicuramente succede più nel mondo del consulting quando tu devi andare da un cliente a risolvere un problema specifico in Utsu insieme a SAS quindi siamo una piattaforma sul server abbiamo un prodotto vero e proprio è il nostro prodotto che risponde a esigenze dei clienti quindi bisogna capire quali sono i loro problemi però siamo una soluzione sul server quindi non abbiamo clienti che arrivano e ci richiedono di costruire un software per loro il nostro software è quello che impendiamo e quindi dobbiamo fare in modo che segua le richieste e le esigenze e risolva problemi reali delle persone che dovranno poi comprare.

Nel day by day qual è il vero ruolo fattivo cioè ti alzi la mattina vai in ufficio se vai in ufficio stai a casa se sei remote e cosa fai tutti i giorni in qualità di product manager? Allora product management ricopre anche lì c'è una crescita personale di carriera di ruolo quindi dipende un po' dalla seniority un po' come hai dei junior dev che poi diventeranno mid senior per poi decidere se fare una carriera più legata agli aspetti magari di architettura del software e quindi diventare più dei ruolo di staff o di profili più elevati di architettura poi la carriera manageriale ed è per il product manager chiaramente quando inizi il ruolo produttore associate preem come lo chiamiamo in i primi ruoli junior è un'attività molto legata anche al team il famoso backlog grooming tenere in forma le priorità quello che c'è nell'immediato in alcuni casi aiutare il team nella definizione di problematiche che magari sono emerse del giorno poi ovviamente con l'esperienza ci si muove sempre più su un lato strategico quindi andare a veramente ad approfondire quali sono le problematiche dei vari stakeholder interagirsi con tante figure che è un altro aspetto molto interessante del ruolo del product manager quello che devi sei un po' sei un single contributor quindi product manager in realtà di manager fino a un certo livello fino a un po' di esperienza non hai persone da gestire sei te stesso hai tanti stakeholder da gestire che possono essere dai sales dal supporto la stessa stessa engineering che magari può venire con richieste di debito tecnico da risolvere che devi priorizzare perché magari hanno un impatto un impatto sui sui clienti e quindi spesso ci sono giornate in cui sei tutto il giorno a parlare con persone quindi raccogli raccogli informazioni cosa che di solito appunto nel team almeno nei miei team di solito di sviluppo odiavano le limiti quindi penso che non sto facendo una non sto attirando penso nel questo pubblico di oggi molte persone nel ruolo però in realtà c'è sviluppati interessanti perché poi da lì devi raccogliere devi raccogliere tante informazioni andare interagire capire di cosa qual è la cosa più importante da fare come prossimo step.

Se voi ci vogliamo parlare di qualcuno che è più integrato nei flussi di sviluppo quindi nel day to day col team di sviluppo pensiamo al prodotto prodotto owner a qualcuno che noi non seguiamo metodologie specifiche con con dev manager con cui lavoro di solito cerchiamo di orientarci di prendere di adattare di adattare varie metodologie che abbiamo scrum piuttosto che magari un kanban piuttosto che altro però essere per me a livello di produttore l'importante essere vicino al team e il team è composto da anche limiti disciplinari non parlo solo di sviluppatori per me fa parte veramente del team ristretto anche il design quindi che si occupa della user experience seguire seguire giorno per giorno dare la disponibilità sbloccare le situazioni di criticità che magari emergono e assicurarsi che tutto vada fluido nel ciclo di sviluppo.

Parliamo di prodotto uno dei ruoli del prodotto manager è quello di avere ed alimentare la visione del prodotto avere una prodotto vision come come fai tu oggi ad avere cioè quali metodologie utilizzi per cercare di chiarificare e di avere una visione più chiara possibile nel medio e lungo periodo rispetto al prodotto? Allora qui dipende un po' del tutto dalla maturità del prodotto stiamo lanciando un nuovo prodotto stiamo in una fase di espansione di un prodotto che già stato lanciato come può succedere in mood suite recuperi un prodotto che esiste intervieni lo recuperi come responsabilità lo devi portare avanti o siamo in un prodotto magari in cui va fatto la marketing.

Parliamo di un nuovo prodotto il nuovo prodotto prima di tutto va capito va fatto un business case devi costruire devi capire un'opportunità se c'è un'opportunità precisa per l'azienda per i lavori quindi fare un'analisi di opportunità rispetto a magari una nicchia di mercato che non ancora coperta oppure in cui hai feedback dai sales che perdono magari dei contratti perché sei più debole rispetto ai competitor oppure discutendo parlando con con i clienti vieni a...

è quel ruolo di collezione di tutti i feedback di input che arrivano dai vari stakeholder che ti permette di creare di generare nuove idee che poi idealmente dovresti andare a validare in modo rapido sul mercato.

Quindi ti faccio una domanda il ruolo del del produtt manager è anche quello di farsi il suo bel canvas andare alla ricerca del valore questo è del produtt manager o ci sono degli altri ruoli con cui condivide questo tipo di risposta? Io questo penso dipende un po' dalla dimensione dell'azienda un po' di dimensione del ruolo di un product manager di una seniority abbastanza avanzata si identifica una necessità di mercato e un senior PM un director of product può essere sponsor di un'attività di sviluppo non stiamo parlando magari di startup come può succedere invece una startup sarà poi il founder che ha la sua idea e ha trovato una nicchia e allo stesso modo però può succedere nelle grandi aziende.

Ci sono poi ci sono vari ci sono poi tutte le varie metodologie framework di definizione di definizione di product discovery di definizione di valutazione perché poi alla fine della fiera identificato magari un problema che vuoi risolvere che fa parte del tuo segmento di mercato vuoi risolvere un problema di un cliente che è identificato in qualche modo vuoi perché appunto i sales siano fatto parte di una feature gap rispetto ai competitor vuoi perché facendo interviste con i clienti che hai ti fanno notare che manca una parte o fai analisi di mercato e c'è una tecnologia un aspetto emergente ci trovi un'opportunità dopodiché devi costruire un business case quindi valutare l'impatto quanto quanto potenziale ha quali sono appunto outcome che vuoi risolvere quale quale valore aggiunto darai al cliente nel risolvere quel problema che poi una parte centrale nella costruzione poi della del prodotto ma ancora prima di tutto questo dei fare una votazione di business quanto quanti dollari riporterò all'azienda facendo quell'attività e allora lì poi entra tutta una fase di business analisi dove fai magari delle proiezioni basate su dati che hai della tua visione.

Tu hai detto prima quindi questa era più la parte relativa alla visione quella che abbiamo affrontato ma tu hai detto che nel lavoro day to day tu comunque devi gestire una serie di stakeholder o quantomeno fare da connessione da collante tra una serie di stakeholder tra questi stakeholder ci sono ci possono essere i clienti o il management board of directors o ci può essere il dev team come si costruisce un rapporto di comunicazione sano con gli stakeholder ti faccio questa domanda anche perché ho servito la risposta dalla prospettiva del dev dalla prospettiva del reparto tecnico che ho.

Allora chiaramente ci sono in questi stakeholder possiamo distinguere varie categorie stakeholder che con cui devi interagire ad hoc perché c'è una certa problematica quindi parlo dei stakeholder con cui interagisco meno frequentemente nel nostro caso abbiamo abbiamo abbiamo api esterne per esempio abbiamo tutta una parte dell'azienda che si occupa delle partnership e quindi quando per esempio per una certa funzionalità serve di dover andare a consumare un api e queste persone qui c'è un problema specifico devi dargli motivazioni ci serve capire sta roba.

Questi sono già i stakeholder attuali.

Ci sono stakeholder come dire board of director in cui noi product manager nello sui abbiamo comunque delle sessioni di planning trimestrale quindi con questi stakeholder viene un'interazione diciamo mensile per cui vengono date delle direzioni di business dove dobbiamo interfacciarci con loro per dare priorità alla nostra visione che si deve allineare poi con le linee guida e quindi questo è un tipo di stakeholder magari ci sono grandi meeting un sacco di persone magari inquadrati con del lavoro preparatorio e poi c'è il day to day come dici tu, è il team più stretto il team di portfolio magari perché magari un prodotto come Woodstreet tu hai 3-4 team di sviluppo e quindi ci sono 2-3 product owner, un product manager, vari designer, una ventina di sviluppatori ogni team e che è appunto una ventina di sviluppatori che prendono a sviluppare.

Lì abbiamo vari modi ci sono appunto tutte le cerimonie simil scram, simil agile quindi riunioni ricorrenti dove ti interfacci e fai modo che se io ho la riunione in cui dobbiamo discutere la prossima funzionalità ci sono sia i dev manager sia i designer, la triade come chiamiamo internamente e ci interfacciamo e fai modo che appunto le cose vengano fluide quindi se poi c'è un blocker di solito poi mi adopero perché venga affrontato.

Gli ingegneri vengono, i sviluppatori vengono e ci dicono ragazzi qui abbiamo un problema con queste piagge, bisogna chiamare il partner e gli parte magari il meeting con chi gestisce la partner e eventualmente il fornitore.

Spostiamoci un attimo nel lavoro day to day, io credo che uno dei ruoli del product manager forse un po' più verso product owner che come alcuni amici che si occupano di agile mi dicono product owner è un ruolo non è un job, product manager è un job mi hanno fatto una capa tanta spiegandomi questa cosa però spostandoci più per l'attività del product owner in capo al product owner c'è la decisione su una feature o un'altra da implementare è la priorità.

Spesso attorno al product manager e al product owner c'è un certo ignoto no? Quindi come fa questa figura a prendere delle decisioni senza fare un guessing game troppo grande? Allora, non c'è magia, c'è secondo me tanta razionalità, da una parte tu hai almeno come gestisco il lavoro una parte c'è una roadmap di funzionalità abbiamo parlato di visione prima in qualche modo che sia tu che sia il tuo prodotto il tuo superiore nella gerarchia di prodotto che ha stabilito una strategia, hai un piano, una roadmap magari con una certa confidenza sui prossimi mesi un po' meno di confidenza sul prossimo anno e magari qualcosa di un po' più un po' più vago per tra due anni, hai una direzione che stai andando, stai validando, stai magari facendo gli user research, però nell'immediato sai più o meno che ci sono delle cose che farai e le cose le farai ti dovrai adattare poi al cambiamento perché nel nostro, le sorprese ci sono sempre, l'intoppo arriva e lo fai facendo trade off, lo fai facendo trade off quando sono trasparenti, comunicati e condivisi fanno dall'inizio è sempre meglio perché magari fai il design controparte che magari tu ti metti di mezzo perché magari tu vuoi andare live ma ci sono, loro sono i guardiani dell'esperienza e vogliono essere sicuri, quindi spesso quello che io faccio quando parliamo di appunto nuove funzionalità con un backlog di valore da deliverare è condiviso anche che cosa è strettamente necessario fino ad arrivare a chiamiamola MVP, un minimum viable product per quel problema che hai identificato, quindi una serie magari di user story core che sono imprecedibili senza di quelle salta la release, se non si va live la funzionalità salta e quindi queste le negozi all'inizio in queste discussioni che fanno parte dell'iteratività del planning della condivisione della roadmap, insomma questa è una tipologia di funzionalità abbastanza semplice, poi ci stanno da un'altra parte hai la necessità di gestire bug, che bug ci sono, arrivano dal supporto, arriva il ticket, c'è l'utente è riuscito a trovare un flusso che spacca tutto e quindi lo devi gestire, se quell'utente non è da solo ma sono 100, il 20 per cento, diventa una priorità e passa davanti a tutto, fai sprint planning e la porti per prima davanti, non puoi non puoi perdere clienti, quindi ci vuole tanta, non c'è una legge assoluta, ci sono ci sono aspetti per cui la priorizzazione sulle nuove funzionalità ecco di solito una priorizzazione che è basata così, o degli obiettivi soprattutto, quando inizi a avere poi accanto tra gli stakeholders c'è tutta la parte di marketing, quindi tu hai una sorta di roadmap, hai un'idea di qualcosa che rilascerai, intanto il marketing sta preparando le campagne, la roba per spingere quello che stai costruendo con il team, non hai la sfera di cristallo però appunto arrivi trade off e decidi che il minimo con cui si andrà live è quello, se poi non si va live non è la fine del mondo, si cambiano i piani, si comunica e si ferma in macro.

Però nel contempo ci sono gli stakeholder di business che hanno e maturano una serie di aspettative, quindi come gestisci per esempio nel caso critico in cui è appena detto non si va live, come gestisci le aspettative di questi stakeholder, sia nel momento in cui possano essere fulfillate e sia nel momento in cui non vada a niente, non riesce a portare a sottesfarlo.

Posso dire che sono fortunato, abbiamo un'organizzazione che è grande, siamo un migliaio di persone ed è capace di assorbire queste situazioni perché accetta che tramite la comunicazione interna, quindi ci metti la faccia, vai, c'è una sessione e vai davanti ai stakeholder, comunichi le problematiche, le motivi e non muore nessuno, si accetta, ci si adatta al cambiamento, nello sviluppo software è abbastanza...

purtroppo non tutte le organizzazioni accettano questa cosa, da noi siamo riusciti a fare, ad assorbire nel nostro processo il fatto che ci possa essere cambiamento e quindi andare e accettare che se ci sono cose imponderabili.

Poi noi lavoriamo con i social network, in Utsuit abbiamo API, abbiamo social network che da oggi a domani ti cambiano le API facendo finta di comunicarti ma poi fanno altri cambiamenti senza dirti niente, roba che si spacca così dal giorno al domani, piani che saltano e quindi si affrontano queste situazioni criticitarie.

In un contesto così mutevole, perché comunque si fa affidamento su un layer sottostante di partnership che in realtà può cambiare nel tempo anche più prossimo, come si gestisce questo continuo a evolversi nell'ottica del backlog? Cioè cosa cambia nella lista di domanda? Come lo gestisci? Lo gestisci semplicemente prevedendo quello che chiamiamo caos time, ci sono social network che avevano per esempio API neanche versionate e lì diventa complicatissimo, tu sai durante, cerchi di pianificare i prossimi più o meno due mesi di capacità perché ti devo allocare c'è un progetto prioritario dell'azienda quindi devo allocare tempo sul team, su queste user story perché vengono direttamente da una priorità che è stata decisa a livello di business, ho i miei progetti di sviluppo, delle mie funzionalità, c'è tempo per i miei bug e poi abbiamo un'allocazione per il caos time, il caos time su tutti questi imprevisti che a fine mese, a fine del quarter è tempo che poi se non è utilizzato viene magari utilizzato per smaltire un backlog di debito tecnico, però si fa in parole, insomma, proprio del risk management, alla fine devi gestire come come il rischio e quindi allocare risorse temporali della tua capacità a prevedere e anticipare.

Ma con l'esperienza sei riuscito anche ad avere delle stime di questo caos e non stimabile? No, beh dipende molto, no, non è, ci sono situazioni di caos non stimabili, ci sono incidenti, ci stanno richieste che magari arrivano da aspetti legali, magari che a full meaning accesso e neno, la partnership ci si accorge che c'è un cavillo o va rispettata una GDPR, un cavillo piccolo, esatto, e ti chiamano e ti dicono ragazzi quello che state facendo non va dentro, domani dovete implementare questa roba e lì ti salta tutto il quarter, diventa la cosa prioritaria perché se poi ti chiudono appunto la partnership sei lì.

Questo tipo di caos no, non è gestibile e là entra tutto il change management, quella quella processo che ti dicevo in cui tu fai risalire, sto bloccando tutto, non si rilascia più niente, dobbiamo risolvere prima questo questo incendio, spegniamo l'incendio e poi si ritornano a normale.

Caos un po' più normale si impara con gli anni, inizi a conoscere il tuo partner, come lavora e per fortuna a molti poi quando hai del versioning delle piaie diventa tutto più, un po' più sotto controllo, riesci a pianificare, sai che passando, dovrai passare alla versione, alla major successiva, riesci a pianificare magari in anticipo coinvolgi i sviluppatori che ti analizziamo e riusciamo a stimare, lì ritorni nella normalità, il caos è controllato.

Hai detto la parolaccia, stimare, potremmo aprire un capitolo, prenditi una birra perché potrebbe essere molto lungo.

No, prima domanda molto da squadra di calcio, tu sei per estimation o no estimate? Io ho bisogno di avere un'idea del tempo necessario e della complessità di quello che affrontiamo, non sono queste cose, abbiamo preso, non vengono mai, come ho detto prima, abbiamo strumenti per poter reagire, però avere un'idea dei tempi necessari è necessario per pianificare una serie di attività, andare a capire tutto, quello che si potrà realizzare è fondamentale per poter poi interagire in organizzazioni complesse dove tu poi hai marketing, devi andare a svolgere attività, magari con le partnership validare che non ci sono bloccher sull'API di tipo di compliance legali eccetera, hai bisogno di fare queste analisi a monte.

Come dicevo prima, secondo me queste stime non sono contrattuali, non muore nessuno se in corso d'opera ci si rende conto che la complessità era superiore alle aspettative, ma per un business sano comunque ci sono una serie di attività che devono andare in parallelo e quindi per questa informazione è necessario per far girare tutto il meccanismo intorno, il meccanismo deve saper controllare le situazioni di eccezione, le situazioni di caos, complessità non previste, stima sbagliata o no.

Dopodiché se vuoi parliamo di come pianificavamo negli anni di sprint, siamo passati da valutare temporalmente, usare sizing, usare story point fino ad avere un miscuglio di parametri che consideriamo.

Però poi ti chiedo, facciamo un'altra puntata magari con il mio dev manager di fiducia con cui abbiamo lavorato per anni su come ottimizzare appunto e cercare di essere più predittivi nel valore lasciato in ogni sprint, perché poi focalizzarsi, la cosa poi che cerchiamo di avere che infine quello che ci interessa è che alla fine di uno sprint abbiamo lasciato del valore concreto, piccoli mattoncini che poi alla fine faranno, costituiranno magari una funzionalità abbastanza strutturata da poter essere lasciata.

Io dico sempre, se in qualche modo, riporto la visione dello sviluppatore, se non sei tu a stimare, anche per quanto grossolanamente si può stimare, sapi che c'è qualcuno che stima per te e che poi ti dà il ritmo, perché il cliente ha delle aspettative e queste aspettative hanno un frame e tu devi star dentro, quindi almeno avere una visione più o meno dettagliata di costi e tempi se stai realizzando un prodotto e sei concreto e non vivi nel mondo dell'astrato come molti di noi fanno, beh a quel punto devi averci il sottomano, perché altrimenti Marco come si muoverà nel suo contesto, che rassicurazioni darà al business in modo che ti possano dare del tempo per smaltire del backlog, per appianare il debito tecnico, cioè sono uno strumento, poi abituarsi non devono essere perfette, perché non possono esserlo, molto semplicemente perché c'è sempre l'elemento di incertezza, che è quello con cui deve lottare tutti i giorni il buon Marco, però a quel punto c'è un elemento di comunicazione nel quale puoi strutturare il tutto.

Ci deve essere la serenità del sapere che se tu fai una valutazione, vogliamo chiamarla, non vogliamo dire stima, una valutazione della complessità del lavoro che stai affrontando, questa è utile, è necessaria per tutti, perché alla fine poi è importante che ci si senta partecipi del successo del prodotto che si costruisce e coinvolti, e per fare questo poi appunto c'è tutta una serie di aspetti che devono essere gestiti e non c'è nulla di catastrofico se si scopre che è mancato un pezzo e che si può reagire, ci si può adattare al cambiamento, all'imprevisto, ad aver sottovalutato magari la complessità di una cosa.

Assolutamente sì, e tra l'altro io ho un'altra domanda che in qualche modo si inquadra nella questione della gestione del tempo, che è uno dei problemi più grandi, perché è una delle risorse limitate che hai con cui devi fare i conti tutti i giorni, come gestisci il backlog? Solitamente il backlog è un imbutto, quello che gli stakeholder chiedono è mediamente di più di quello che è il throughput del dev team.

A quel punto nel tempo all'interno del backlog si accumula una serie di ticket, di stories, che possono essere dei tech ticket, possono essere qualunque cosa, però si accumulano e il backlog cresce, cresce, cresce, cresce, sedimenta e si stratifica.

Allora come fai a fare backlog gardening, cioè tenere l'orticello del backlog sempre aggiornato, specie in un contesto come il tuo, dove tutto è mutevole e in modo così rapido? Allora devi accettare a un certo punto che alcune cose non si faranno, non si faranno perché hai evidenza che non hanno impatto.

Non appena una cosa che tu hai nel backlog hai evidenza che è un blocker principale per magari una delle metriche di controllo che hai sul successo del tuo prodotto.

Qui parliamo poi tutto un aspetto di cui non abbiamo parlato, ma poi come garantisco io che è fondamentale nella vita del prodotto avere degli indicatori oggettivi di quello che stai fornendo ai tuoi clienti.

Se poi non misuri quello che hai deliberato stiamo parlando di nulla.

Questi indicatori ti aiutano nel decidere sì o no.

Ho rilasciato una feature che magari al 60% se va bene di quello che eravamo arrivati come soluzione con designer che si è immaginato una cosa strafiga e tutto quanto.

Bellissima però poi comunque come dici te il throughput è quello che mi permette di avere un po' più magari dell'MVP che io ho deciso che è il minimo con cui si va live e poi fai interviste con i clienti magari vai a parlarci, l'hai rilasciato, ti confronti con loro, ti confronti con loro problemi, a volte scopri che sono ultra soddisfatto già di quel MVP e sei contento e quindi dici ok adesso abbiamo magari altro da fare.

Adesso c'è questo c'è quest'aspetto tecnico per cui abbiamo questa questa API che risponde in tempi non accettabili e allora lì è importante tra l'altro degli stakeholder quindi deve essere una cosa fondamentale andare a documentare numericamente con dati alla mano le esigenze di debito tecnico che sfido qualsiasi product manager che ha alla mano dei dati magari tecnici che dimostrano che magari una funzionalità sta andando male perché si può migliorare l'algoritmo si deve migliorare l'API a fare pushback perché l'esperienza si è poi coinvolta quindi i dati sicuramente sono l'elemento fondamentale per cui poi tu fai le decisioni i dati e feedback feedback diretto e quindi sì queste funzionalità vanno live non sono il massimo che ti aspettavi e hai decisioni da prendere lì o fai nuove iterazioni perché devi fare expansion o perché c'è una funzionalità oppure ti devi adattare alla nuova priorità e seguirla dopodiché ecco una critica che posso fare se no poi sembra che siamo una società idillica garantire garantire in modo costante spazio per manutenzione per per far evolvere la funzionalità che ha che dimostra di avere potenziale è assolutamente è assolutamente importante spesso come dici te si poi si rincorre l'ultima shiny things l'ultima cosa brillante che arriva e ti metti tutti tutti di corsa a fare quella cosa lì tutta la società diventa focalizzata sull'I arriva con il mandate da dall'exec o dal business cioè sono metriche che vengono prese in considerazioni come metriche di business che diventano quelle principali e quindi ti devi adattare su quelle quindi magari appunto quel backlog è dire sacrificato perché arriva arriva alla fine non è un mondo democratico non è che ci sta il business ci sta il board prendono delle decisioni se le linee di business sono quelle o fai come sta offrendo proprio in questi giorni o vai a dimostrare che se ti sposti completamente ti scordi di continuare a mantenere una funzionalità che ti porta a vari diciamo una buona fetta di di di revenue e lo vai a dimostrare con numeri solo così puoi andare se no se il board decide se la product leadership decide che la direzione è quella poi diventa difficile ma sono giustamente scelte che vengono vengono prese l'unico strumento che hai è dimostrare con dati dimostrare magari valore che stanno rischiando di perdere e allora l'ultima parola però sono loro che decidono alla fine numeri metriche mi ero ripromesso di chiederti come fai a capire se il prodotto sta facendo centro specie nel contesto di un prodotto digitale se no questa domanda è tutto o niente allora o almeno qual è il processo che usi per la definizione delle metriche perché ci sono una metrica specifica non avrebbe senso no di solito allora è un processo un po top down hai degli obiettivi aziendali che possono essere crescita delle delle sezioni risoluzioni di problemi di conversione che possono essere semetriche di business o semplicemente crescita del del revenue su cui ti puoi agganciare con metriche classiche del ciclo di vita del prodotto quindi le fai magari a cascata le fai coincidere quindi se stiamo parlando con con un ciclo di vita del prodotto intendo metriche che riguardano quante persone hanno scoperto per la funzionalità quante persone l'hanno adottata quante persone stanno facendo churn la stanno lasciando non la stanno più usando a seconda di dove vuoi agire a livello di business quindi voglio incrementare le conversioni dei nuovi iscritti mi vado a concentrare magari sulla la discoverability della funzionalità che ho sviluppato perché penso che è quello che li convincerà a diventare abbonati quindi l'azione specifica è in capo comunque al prodotto al prodotto manager è in capo sia il prodotto manager a vari livelli quindi poi ti agganci ti agganci alle metriche alle che piazza aziendali cerchi di farle a cascata corrispondere con la funzionalità di solito tu hai deciso appunto stiamo parlando una nuova funzionalità di risolvere un problema di prodotto perché le persone non mi stanno non si stanno iscrivendo al sito non si stanno iscrivendo al sito perché un problema sul forum questo magari analizzando funnel per i metriche più di utilizzazione del prodotto che quelli diventano come dire input su che cosa fare perché se io ho tracciato gli eventi del mio prodotto ho costruito il live site quindi so che magari sto creando una una funzionalità di reporting e quindi l'utente deve arrivare nella dashboard crearsi il report e poi schedulare magari il report mensilmente mi posso chiedere perché non stanno schedulando e lì posso andare a analizzare magari c'è un bug scopri la maura ci sei sì sì ci sei se è andato offline ho cresciato di brutto così da schermato non era dicevi diciamo stai stai creando un nuovo una nuova linea di prodotto devo lanciare sto facendo una business case per riposizionare un prodotto e li stiamo facendo proiezioni di business ci agganciamo a delle metriche e dobbiamo ottenere della delle nuove revenue stiamo facendo le proiezioni quante revenue come faccio a trovare le revenue adesso modellando dovrò modellare poi le metriche di successo quindi come misurerò il fatto che le persone stanno si stanno stanno adottando il prodotto che crea e vada a creare ed è importante che il prodotto vada a creare sia sia tracciabile nella sua utilizzazione perché come dicevo prima invece sono altre metriche più basso livello più vicine proprio alla al prodotto stesso che mi permettono poi in fase magari di evoluzione di mannaggia di priorizzare o meno una funzionalità se io decido di creare un form che mi permette di modificare una certa cosa che magari ci sono 20 20 informazioni e non riesco a implementare quel form che magari deve avere dei widget complessi perché sono come diciamo prima il truck boot è finito e ho potuto farte soltanto le informazioni principali se scopro che poi nessuno fa l'edit ho guadagnato solo tempo il mio backlog lo pulisco tutto quell'extra lavoro di widget magari fichissimi che ci siamo immaginati che non vuole usare nessuno ho salvato quindi per tornare alla priorizzazione un po dipende sempre dalle funzionalità sto sto valutando delle del backlog di di feature che magari sono rimaste indietro ma servono veramente le metriche mi servono risposta metriche di prodotto di utili di utilizzazione di adoption e di mi servono a fare decisioni lì sto lanciando un nuovo prodotto devo pensare la prossima epica da sviluppare vado magari più ad allinearmi su sulle metriche di business e magari con andarli ad associare una metrica di di prodotto ex cycle quindi e valutare qual è la prossima la prossima epica da fare per essere allineati col business spero sia chiaro non so quanto si si no no è più che chiaro la mia domanda è per quanto riguarda le metriche da un po di anni a questa parte abbiamo zio gdpr che impatto ha avuto il gdpr con i suoi vincoli nei dati che avete indietro poi per prendere delle decisioni in merito al prodotto non so io allora l'impatto immediato certo sono dati anonimi poi alla fine è quello che quando quando guardi questi son dati quantitativi sai non vaia finché gli utenti poi sono sono registrati quando si servono dei dati non anonimi zati sono utenti quindi abbiamo possibilità poi se dobbiamo andare a vedere una fisio magari uno gli è stai stra i loro informazioni e se hanno dato il consenso magari riesce anche intervistare quindi a contattarli non penso che sia a livello di prodotto analisi non penso ci sia stato un grande impatto mi immagino sia più più pesante per chi fa marketing per chi fa advertising retargeting tutti questi aspetti dell'advertising legati in social network motore di ricerca probabilmente gdpr ha un impatto molto più importante a livello aziendale sicuramente ha avuto un impatto ci sono costi di gestione eccetera sicuramente considerazioni da fare sto utilizzando dati privati o no ma a livello del tracciamento dati le piattaforme di tracciamento ormai sono praticamente tutte anonimizzate poi ecco non non dal punto di vista mio non penso di aver perso qualcosa no nulla di essenziale non avere no quello che invece è essenziale è avere una strategia di tracciamento dati strutturata bene fatta in modo in modo opportuno sapendo utilizzare la piattaforma di tracciamento nei suoi in tutte le sue funzionalità perché poi è appunto il problema che abbiamo è che spesso i dati sono non abbiamo non sfruttiamo tutta la potenza di piattaforme che abbiamo perché c'è stato non c'è stato abbastanza lavoro di progettazione esatto di convenzioni anche di diventa difficile perché poi ogni ogni team in passato aveva creato eventi per esempio non seguendo sempre le stesse convenzioni dove creare vocabolari o riconciliare insomma ma è tutto un altro capitolo questo sì assolutamente però una cosa importante che è quella è una mia considerazione corregimi se sbaglio ma il raccogliere dati a babbo così come capita probabilmente non porta da nessuna parte avere chiari gli obiettivi di prodotto le kpi trasforma i dati che raccogli in qualcosa di actionable e quindi in azioni concrete che poi ti vanno a finire nel backlog sia in fase di aggiunta nuovi ticket o di eliminazione di vecchi ma che comunque corrispondono a una certa azione che alla fine rende utile quella misurazione assolutamente come diceva parte fa parte della parte della fase di nella fase di progettazione abbiamo un momento in cui mi occupo di definire il piano di tracciamento data quindi il perché il cosa il perché stiamo tracciando quali informazioni di corredo vogliamo associare e questo poi in realtà è fondamentale che abbia anche questi momenti condivisi con il team perché poi quello a cui io tengo molto è che tutto questo sia fatto in modo trasparente condiviso perché poi è fondamentale l'apporto del del parere del developer il parere del designer aiutano aiutano aiutano il prodotto manager non può fare tutto ha bisogno ha bisogno di tutti gli stakeholder fa tutto e non fa niente il prodotto manager esatto è un direttore è un direttore d'orchestra è colui che da solo non suona ma insieme al suo staff suo team riesce a comporre dei capolavori a suonare dei capolavori e hai parlato di team ok e il ruolo del prodotto manager è quello di fare da ponte no tra i vari stakeholder è uno dei suoi ruoli più importanti e abbiamo anche parlato di kpi e di obiettivi di prodotto come fai a costruire la comunicazione tra il team tra te che sei un prodotto manager e il team per far passare gli obiettivi di prodotto al team di sviluppo cioè hai delle metodologie come ti poni con loro come costruisci la struttura della comunicazione? allora in progetti stiamo parlando di progetti quando stiamo facendo un progetto che durerà magari un paio di mesi no? parlavamo prima di planning trimestrale, di una revisione più o meno trimestrale o semestrale di lanciamo un progetto e di solito di solito viene fatto un kick off viene introdotto il progetto viene dato il contesto di business perché stiamo facendo quella cosa perché stiamo risolvendo qual è il problema dei clienti che vogliamo affrontare dal problema dovremmo analizzare spesso prima del kick off non abbiamo la soluzione, la soluzione la costruiamo con il team, con design, con developer insieme però abbiamo un contesto generale di inquadriamo nel business inquadriamo in use case questa funzionalità è la top request che è arrivata tramite il supporto abbiamo 2000 ticket di persone che non aspettano altro di fare questo dobbiamo capire come risolvere questo loro problema quindi un contesto normalmente viene fatto un kick off dell'iniziativa e questo parecchio prima poi perché poi parte una fase di studio di analisi valutazione, valutazione tecnica, valutazione della soluzione qual è la soluzione più opportuna e questo va fatto in modo condiviso quindi per me importante poi che io sto portando il problema del cliente che risponde all'esigenza di business validata da numeri che avrà questo impatto quindi porterà tot, tot sold, revenue alla company però poi il come lo costruiamo, lo costruiamo insieme con un processo che chiamiamo planning iterativo su cui andiamo prima a fare una prima valutazione che poi piano piano si raffina perché magari nella prima analisi si inizia a fare un wireframe di una possibile esperienza per cui ci sarà bisogno di comunicare con un API quindi si parte magari il supporto dei developer a analizzare l'API ci fornisce tutto quello che serve costruire magari un'infrastruttura nuova tutte domande che vengono poi stilate a cui rispondiamo insieme con le varie responsabilità e quindi si introduce si va ad analizzare il problema e si approfondisce fino a definire una soluzione, una soluzione appunto magari anche quella pensata in modo iterativo quindi la soluzione core che andrà a risolvere immediatamente il problema che magari non sarà super raffinata e poi vari raffinamenti successivi.

Quindi comunque nel tuo approccio la richiesta del business, l'esigenza, tocca direttamente il team di sviluppo? Assolutamente, non solo e molte idee vengono direttamente dagli sviluppatori cioè adesso sto lavorando su una nuova funzionalità e tante tante idee vengono perché poi magari lo sviluppatore quello che tocca con mano l'API del partner e sa esattamente quale informazione magari ne sa, ne condivide magari la documentazione, leggo anche io le API, leggo la documentazione però poi magari lavorandoci dentro c'è un'idea che viene dalla, ognuno per le sue responsabilità, il designer per esempio andrà a digerirsi una serie di informazioni che vengono comunque tolte in queste riunioni e poi sarà lui a immaginarsi l'esperienza come sarà il senior level o per immaginarsi magari un'architettura che serve per rispondere a quella cosa però tutti insieme si può dividere.

Diciamo che il mio ruolo è dal business abbiamo identificato, dal business, dagli secondary abbiamo identificato questa nuova funzionalità da affrontare e poi però con il team pensiamo alla soluzione.

Eppure il tuo ruolo è un sacco complicato perché devi avere la visione ma nel contempo devi gestire anche il day to day e allora come fai a equilibrare questa cosa di creativo e proattivo? Infatti qui entriamo in un altro problema nel senso che idealmente un senior product manager, un product director non è nel quotidiano del team, lì si viene a costituire il team di prodotto e il team di prodotto che magari ha figure come tu puoi avere il junior developer che si occupa magari soltanto di sviluppare magari un widget e dietro hai il senior che costruisce invece tutta l'API dietro e tutta l'infrastruttura, anche lì tu hai il product owner, il junior product manager che è nel day to day che vive alla giornata perché prioritizzare sono anche cose che emergono magari allo stand up, abbiamo questo blocker e quindi lì tu devi essere con il team, abbiamo il product manager che spesso aiuta a sbloccare situazioni già dallo stand up.

Però questo è un product manager a livello junior, quindi sta, vive nel team, poi piano piano ti muovi sempre più verso una visione strategica fino ad arrivare a livello magari di un director of product che è vicino veramente al board e deve orchestrare lui più prodotti in parallelo che rispondono poi a un portfolio di prodotti che corrisponde a una, quando hai un'azienda complessa magari tu hai più soluzioni quindi ha una visione a livello di soluzione globale e così a cascata, c'è una gerarchia.

Guarda ogni risposta che mi dai mi triggeri subito con una domanda successiva perché questa è una cosa che mi interessa un sacco nell'otica del product manager, tanti product manager sotto di loro ed eventuali product owner che possono essere inglobati col product manager.

Comunque in un contesto dove all'interno dell'azienda ci sono più prodotti, in realtà io per esempio ho lavorato in un'azienda dove il prodotto era uno però le feature importanti erano due, c'erano due team con due team di prodotto dedicati.

Come se lo si fa ma come si orchestra la comunicazione tra product manager di due dipartimenti separati? Io non lo so se lo facciamo bene però abbiamo degli eventi appunto perché parliamo di trimestre? Perché trimestralmente abbiamo introdotto gli OKR da un paio d'anni, ci sono degli obiettivi appunto definiti dal board, priorità.

Priorità può essere voglio, il business scopre che quella linea di prodotto ha una redditività maggiore, ci si focalizza su quella soluzione, quella soluzione diventa importante, ci sono discussioni di priorizzazione di linee guida che dal board ci si riunisce e si dice ok questa parte deve essere priorizzata, ci dobbiamo orientare magari più su questa fascia di clienti che possono essere magari che orienti più su clienti di un certo piano piuttosto che un altro perché sono più redditizi o perché in quel momento c'è un appetito.

Quindi viene data una indicazione generale, vengono dati dei temi generali, ci si allinea su quei temi, ci riuniamo, è un processo che dura un paio di settimane, ci sono vari eventi di gestione di queste interazioni e dipendenze perché poi in una grossa organizzazione magari c'è dei team che sono magari più di piattaforma, che si gestiscono, magari tu hai dei servizi core che ti gestiscono l'autenticazione o la gestione delle utenze o la gestione semplicemente del billing e dei vari piani e delle funzionalità, quindi tu hai delle dipendenze interne di piattaforma, questi momenti sono in base a queste linee guida, ci si fa questa pianificazione e si condivide ed è per questo che poi è bisogno di difendere la capacità perché tu devi andare lì e dire questa cosa che voglio fare è allineata con questa particolare indicazione del business e porterà tot alla company e mi dovete far fare questo lavoro, però lo devi andare a dimostrare.

E se è continuamente messo alla prova immagino? Dopodiché è un lavoro che non è improvvisato, se è messo alla prova, ma poi quando hai dati e quando hai le cifre riesci a orientare, poi certo se la linea di business cambia completamente radicalmente, sono decisioni che comunque poi vengono in modo gerarchico, i numeri possono esserci però se poi si decide che quella linea di business non è più rentabile e che il tuo prodotto non è più la priorità, ti adegui e ti metti a disposizione.

O al contrario, provi a dimostrare il contrario e devi portare dei numeri per poter andare a dimostrare il contrario.

Ultima domanda perché vedo che il tempo sta volando, ma penso che hai già risposto fondamentalmente che era come evitare lo scope creep all'interno del prodotto, il feature creep dell'inserire tanti elementi tutti insieme che probabilmente non generano valore, ma che ormai mi hai disposto.

Spero che sia stato chiaro, però gli elementi, le metriche sono quello che ti aiutano, c'è pianificazione che viene fatta, c'è un continua ricerca, continua validazione di quello che è stato rilasciato e quello che non è stato fatto va rimesso in discussione prima di poterlo digerire solo perché sta nel backlog.

Quindi è un'analisi continua, non è che c'è una cosa più prioritaria perché ci piace a noi o perché il design è figo.

Sei super razionale e questa cosa mi piace tantissimo, però per un attimo fai finta che non ci stia ascoltando nessuno, perché siamo solo io e te.

E ti chiedo, ma quanto c'è, sincero però, mi raccomando, quanto c'è di intuizione col crescere della seniority nel tuo lavoro? Ma l'intuizione viene da...

Sinceramente da...

non lo so, sono forse troppo empirico, non ce la faccio, ma viene dall'esperienza, raccogli dati, parli con i clienti.

Dopodiché ecco, se domani un'intuizione di un nuovo prodotto, come ho lanciato vent'anni fa per una nuova startup, magari torno a fare startup e mi viene un'idea, o proprio, o letteralmente.

Però insomma, analizzando tu ti scontri, vieni a conoscenza di situazioni, l'esperienza sicuramente ti permette magari di non essere banale nell'ideazione dei requisiti e nell'identificazione della problematica da risolvere.

Tutto sa cosa voglio risolvere, cioè l'intuizione è capire, appunto parlando con le persone, che in quello che ti dicono dietro sotto c'è un potenziale prodotto, che magari loro non se ne rendono conto.

È importante fare le interviste, perché quando tu parli con un cliente o quando gli fai proprio...

ti metti semplicemente con lui e gli fai usare il prodotto e magari ti dice quelle due o tre cose che a te accendono una lampadina e lì viene l'intuizione, ma indotta dal fatto che tu hai queste relazioni continue.

Chiaro, quindi l'intuizione dal tuo punto di vista...

era una domanda del cazzo, perdona.

L'intuizione però, appunto, l'intuizione poi ce la puoi avere, se ce l'hai benvenga, devi avere poi il coraggio di partire su quella intuizione e farci magari il tuo prodotto, la tua startup.

Però mi hai dato una risposta che mi è piaciuta tantissimo tra le righe, cioè quello che mi hai detto con l'esempio che hai fatto, secondo me ha un valore importantissimo nell'otica di...

quando tu raccogli un botto di dati e hai una metodologia stringente nel fare quell'azione, definita, precisa, non vai a dminchiam, cosa fai? L'intuizione si manifesta sotto forma di dubbio.

Quello che tu mi hai detto, quando io intervisto una persona, lui mi dice tre cose e mi accendono le lampadine, mi si accendono le lampadine, è perché fondamentalmente quello che lui ti sta dicendo triggera una serie di elementi che anche a livello subconscio tu colleghi e ti inizi a fare le domande.

Quindi l'intuizione c'è, pur essendo un essere fortemente nazionale come hai appena dimostrato, però si manifesta dal mio punto di vista in quel modo.

Esatto e c'è un altro aspetto su cui devi per forza, quando parlavamo di minimo valore, puoi farti un'idea a un certo punto, però devi decidere, prendere delle decisioni dove fermarti perché devi andare, non puoi avere il prodotto perfetto.

A un certo punto dici ok, questo è abbastanza.

In base a questi feedback, in base all'outcome che tu aveva ragione, fai comunque una scommessa, penso che questa è una scommessa che devi fare a un certo punto e ti prendi questa è una grossa, forse è una delle parti più toste, di prendere le decisioni di dire ok, così possiamo, e ci metti la faccia con tutte queste cose.

Andiamo così e poi scopriremo, scopriremo se abbiamo toppato o no.

Non avrai mai la scelta, non saprai mai se quello che stai per lanciare è il prodotto che sarà sufficiente, sarà over-ingegnerizzato perché magari poi fai troppo, magari ti rendi conto che è speso, quindi potevi lanciare molto prima, con una cosa veramente minima.

Ho visto piattaforme con delle interfacce pennose che vanno avanti da anni, la gente è contentissima perché fanno quella piccola cosa che la fanno bene e quello è un successo.

C'è gente che usa ancora SAP.

Per fortuna non sono mai entrato in quel mondo, per fortuna da quello che sento non sono mai entrati in quel mondo.

Guarda io ci sto lavorando questi giorni, mi sto sviluppando l'integrazione, ci dobbiamo interfacciare ed è un bagno di sangue.

No ma è vero, in certi ambiti quella roba funziona.

Sì, dobbiamo integrare la nostra piattaforma a un SAP.

No, noi ne abbiamo fatte tantissime perché a parte l'API dei social network, facendo advertising abbiamo tutte le API, si era in vari...

avevamo un prodotto che faceva sincronizzazione con CRM e c'erano le API.

E poi non farò nomi, però sono anche grossi attori che hanno cose a beccare.

Ma guarda io ho visto cose, API che trasformavano le virgoline in slash, senza senso.

Che avevano deciso così, di standard.

Assolutamente, mamma mia.

Guarda, c'ho il terrore la notte, quando mi addormento voglio gli incubi.

È un lavoro interessante, tra l'altro mi viene da chiederti cosa porti della tua esperienza da sviluppatore nel tuo lavoro tutti i giorni.

Quello che dopo qualche anno cerco di fare è non portare nulla, perché voglio rispettare assolutamente i sviluppatori.

Di certo mi aiuta, di certo mi aiuta, perché puoi andare a leggere un API se dobbiamo parlare di problematiche tecniche, capisco i limiti, ho un linguaggio...

abbiamo lo stesso linguaggio, al contesto so che se...

anche se ho perso un po' la mano, quindi certamente ho totale fiducia dei miei dev manager, perché loro sono gli esperti, il senior che mi parla.

Però, insomma, posso fare challenge, cercare di capire se abbiamo se abbiamo modi per fare scorciatoie, proprio per arrivare a...

ma non per...

cioè poi il problema, qui apriamo tutto un discorso del fatto che spesso queste scorciatoie che si cercano magari sono a decrimento della qualità, no? Però alla fine c'è sempre il problema da product manager che hai la responsabilità di validare il prima possibile che quella tua intuizione porterà soldi, quindi...

sei obbligato a volte di metterti il cappellino di quello che ti chiede di fare magari un hack, di fare...

di dover rinunciare a delle cose perché vuoi andare in produzione, perché serve andare, perché voglio validare.

E lì son discussioni del tipo, devi mettere sul piatto, ok, cercheremo, dobbiamo, avremo debito tecnico, è un rischio che devo accettare e me ne prendo la responsabilità.

Però dovete accettarlo anche come sviluppatore che il debito tecnico serve a volte a poter validare immediatamente, ma è un discorso che poi serve anche essere rispettosi del tempo dello sviluppatore, perché se poi passiamo un mese a sviluppare una cosa e quella cosa è un fallimento, io ho perso tempo tutti, no? Ti faccio una domanda che mi viene proprio da una discussione che avevo con mia moglie oggi.

Ci sono dei contesti dove giustamente in qualità di product manager devi dire, oh raga, anche se il codice è una monnezza, deployiamo.

Me ne prendo io le responsabilità, molti product manager fanno così.

E mi piange il cuore perché sono sviluppatore.

So quello che vuol dire, che dice, cosa vuol dire deployare.

Nel contempo il software engineer sta mergiando del codice mondezza a sua firma e ha una percezione di simile denigratoria, no? Cioè dice, prima o poi qualcuno leggerà questa codebase e io sarò trattato come il coglione che ha scritto queste cose abberranti.

In questo caso la psychological safety, la zona di comfort psicologica è importante.

Da product manager come la gestisci questa patata bollente? C'è poco da gestire, devo far accettare il fatto che dobbiamo validare.

Il discorso appunto, il primo di tutto è sulla reputazione.

Nelle discussioni di priorizzazione dimostrare che però ho una feature in produzione che ha avuto successo e per quale abbiamo fatto dei compromessi.

Abbiamo un backlog di debito tecnico, io sarò sempre quello che lotterà per avere la spazio per consolidare, perché sono il primo a sapere che se quel debito tecnico non viene risolto mi si rivolgerà contro a un debito.

Non puoi più stimare niente perché non sai com'è.

A parte appunto qua, a parte i casi proprio in cui tu ti trovi con una codebase che è una mondezza totale, non ti puoi muovere se sei ingessato, ma lo stesso fatto di poter crescere.

Io cerco di gestirla con una gentleman's agreement.

Sappiamo che facciamo questa cosa, se abbiamo successo con questa funzionalità stiamo mettendo questo debito e da buppa dei famigli la voglio ripagare e lo ripagheremo.

Però solo se ha successo perché se è un fallimento in realtà non sei un coglione, sei uno che ha a cuore il business e il tuo tempo da sviluppatore non l'hai perso con una cosa su cui abbiamo preso una toppa e come abbiamo toppato le stime, abbiamo fatto change management, possiamo anche toppare una feature e tornarci sopra e decidere di ucciderla perché abbiamo sbagliato ad analizzare il problema o abbiamo sbagliato la soluzione e ci sta i prodotti a un certo punto vanno chiusi.

Chiaro, fa parte del ciclo di vita ovvio.

Dimmi una cosa, ma tu in quel caso quando stai lanciando una nuova feature che devi misurare, te lo allocchi già allo slot per fare il refactoring o lo postponi, nel senso mi porrò il problema se la cosa funziona.

Quello che di solito chiede che venga documentata, quindi che sia nello suo banco che quella è stata una decisione.

Allocare qualcosa per risolvere un problema che non sappiamo se poi in realtà vale la pena risolverlo.

Quello che abbiamo è una banda dedicata a gestire, idealmente bisogna difendere questa banda dedicata a gestire debito tecnico come gestire anche in un certo modo i bug che magari ci sono prioritari altrimenti miglioramenti anche dell'esperienza.

Torniamo altrima al discorso del backlog, ma quando facciamo attività di pianificazione di solito cerchiamo di riservare una banda.

Dopodiché se il progetto gestisce una priorità anche in quello.

Dopodiché poi arrivano le cambiamenti di direzione aziendali e si passa su altro.

La funzionalità funziona, sta andando abbastanza bene però non riesce a dimostrarne la sua importanza magari in un contesto successivo e quindi magari viene parcheggiata e si porta quel debito.

Però poi è una decisione del business, vuol dire che in generale il business ha deciso di non investire più su quella cosa e ci sta che tu non ci hai speso più da te.

Intanto l'hai portata online.

È un lavoro di equilibrio molto complesso.

Molto diplomatico, per non parlare dell'empatia appunto nelle varie discussioni perché chiaramente è difficile affrontare discussioni di debito tecnico con i developer come è difficile affrontare una discussione magari con un supporto e fargli accettare che devono spiegare nei ticket magari un workaround per superare un bug, un limite o andare a spiegare al designer che quel flusso strafico che ha pensato sarà limitato.

Quattro mesi per fare questa cardina che vola in giro per la pagina.

Quindi accettare un po' tutti i limiti.

Come il product manager dovrà accettare che capacità del suo quarter dovrà essere dedicata appunto a debito tecnico.

E dovrà difenderlo come hai promesso e sai che farei con tutti.

Ma là si vede la tua parte da software ingegnere.

No però credo che anche la delicatezza con cui si affrontano queste cose da parte del dev manager ma anche dal product manager se interagisce direttamente è importante perché in realtà quello che lo sviluppatore mette là è il suo artefatto, fa parte di sé.

Poi io capisco che il lato prodotto, perché sono una persona molto produccentrica, che tu puoi creare il quadro più bello del mondo ma se non c'è un gallerista che te lo espone te lo metti in bagno e quando sei seduto sulla tazza te lo guardi.

Probabilmente è anche fonte di ispirazione ma insomma oltre là non va.

Marco guardavo l'orologio, vedo che si è fatto anche abbastanza tardi quindi io direi che il momento tipico e topico nel nostro podcast è arrivato, è il momento del Paese dei Balocchi, momento in cui sia i nostri host che i nostri guest condividono, mettono sul tavolo un libro un talk, un qualcosa abbia catturato la loro attenzione.

Quindi la mia domanda è ad oggi, hai qualcosa da condividere con la nostra community? E conduco nel Paese dei Balocchi.

Ah, il Paese dei Balocchi.

Allora quello che hai venduto, abbiamo parlato molto appunto di scoperta, del valore, del focus sul cliente, di ragionare appunto sul problema ma soprattutto qual è il risultato che vogliamo ottenere per il cliente, qual è l'outcome che vogliamo fornire al cliente utilizzando un prodotto? C'è una serie di letterature intorno al concetto di job to be done, che è il concetto su cui focalizzare in fase di product discovery.

Sto analizzando una problematica precisa qual è l'obiettivo finale del mio utente che deve ottenere, perché quando tu hai chiaro qual è l'outcome a cui vuoi far arrivare il tuo user, diventa anche tutto più facile definizione priorità perché hai degli obiettivi molto precisi e quindi andarsi a cercare talk vari o anche articoli sul job to be done è una buona, come dire, sono dei buoni, un buon concetto da esplorare, che sia un talk magari andate su Mind the Product, è uno dei canali, delle organizzazioni e conferenze più importanti nell'ambito del product management.

Ci sono i product 10 che sono conferenze locali a cui proveniente in queste due città più importanti ci sono, il sito è mindtheproduct.com sicuramente un riferimento nell'ambito del product management e lì andare a approfondire i concetti relativi al job to be done può essere un buono spunto per andare a imparare a empatizzare con le problematiche di priorizzazione del prodotto e avere un buon approccio mentale a come immaginarsi le soluzioni.

Questa è una cosa, non so, siamo in un studio, siamo RISE, che è un framework per decidere appunto dare un modello di score per dare priorità alle iniziative, quindi magari un aspetto come RISE, che sta per Reach, Impact, Confidence, and Effort, quindi è una formuletta magica, non si applica sempre, può essere adattata, può essere declinata magari al vostro ambito ma sostanzialmente si prende in considerazione quanti utenti andrò a coprire nella mia user base con questa funzionalità, qual è l'impatto di business che penso poter generare? Penso di aumentare il revenue di tot per cento, quale confidenza ho? Che questa sia esattamente la soluzione giusta? Per confidenza entra in gioco un aspetto importante che la confidenza deve essere basata di nuovo su dati empirici, numeri, interviste, numero di ticket, ho fatto dei questionari e il 90% dei clienti mi ha risposto che devono poter stampare il pdf e la dashboard, e lì ho una confidenza alta, ho un riscontro importante, non fa parte del feeling, dell'intuizione pura, perché mi sono svegliato stamattina e ho deciso che avere il bottone blu in basso a destra è la cosa più importante.

Confidence è una cosa di autovalutazione, non so se ti è mai capitata, ma i professori ti dicono di autovalutarti, non devi imbrogliare, devi avere parti, devi avere una tua scala, anche lì ci sono vari modi per valutare il livello di confidenza e in tutto questo poi c'è il livello effort, dove arriva magari il lavoro di primo livello di iterazione, dove hai già iniziato a parlare con i developer, con il design e ti fai un'idea di massimo quanto potrebbe volerci.

Noi usiamo dei fattori moltiplicazioni, per esempio sull'add in ovo, su quanto potrebbe volerci, lo stiamo facendo senza conoscere molto benissimo la soluzione, quindi aggiungiamo un fattore di rischio.

E' un framework che può aiutare a definire la priorizzazione a più alto livello, non delle singole storie, ma magari di epiche, un gruppo di epiche riletti a un problema di business.

Sono due spunti, poi il framework di prodotto, la letteratura come tutto, anche con i processi.

Non amo l'ortodossia, amo contaminarmi di idee e adeguarle alle esigenze dell'azienda, del team, del modo di lavorare, di essere in ognuna.

Il silver bullet non esiste, quindi fondamentalmente la metodologia è il bignamino di un'esperienza o di più esperienze, quindi se tu prendi tanti bignamini di più esperienze, li metti insieme, li orchestri e hai un toolkit da utilizzare.

Vedo che Marco è di nuovo caduto...

Eccoti qua! Non ho arrivato, devo aprire un ticket.

Anch'io ho un balocco.

Per chi sviluppa con TypeScript, ho beccato sta roba.

In realtà che sto provando e sembra molto figa.

Io ho utilizzato per un mio site Project Prisma, che è un ORM molto molto interessante, e la cosa che mi è piaciuta di Prisma è avere praticamente i tipi direttamente dal database out of the box, quindi io ho praticamente la codebase abbastanza type safe, rispettando i dati che mi vengono dal database.

Una libreria che ho trovato molto figa, che trasla questo concetto verso l'API, si chiama TRCP ed è figa perché in realtà tu definisci la tua API TRCP nel server, importi i tipi direttamente nel client e utilizzando appunto il TRCP client, le risposte saranno già type safe e praticamente l'editor ti suggerirà praticamente quello che ti arriva dall'API in modo molto molto chiaro.

Provatelo, io l'ho raccontato malissimo con la zappa come mio solito, comunque se siete javascriptari o per meglio dire typescriptari, questo potrebbe essere il balocco che fa per voi.

Marco, il tempo è volato e la chiacchierata con te è stata super interessante perché in realtà ci ha portato a vedere quello che facciamo da un'altra prospettiva e ce ne ha mostrato le problematiche, perché spesso il rischio è quello di subirlo il product manager invece con questo tuo racconto diciamo abbiamo fatto un passo verso l'empatia verso il product manager e noi sviluppatori sappiamo che non siamo esseri molto empatici quindi per questo ti ringraziamo Marco, ti ringraziamo di cuore a nome.

Ma è stato un piacere, l'empatia si è fondamentale ma è fondamentale appunto sentirsi coinvolti perché poi non subire le decisioni, anche aspettarsi che vengano, non esitate a mettere alle corde il product manager, il vostro product manager chiedendo perché stiamo facendo una cosa e quando capisci che cosa, quale problema stai risolvendo, uno magari hai un'idea che è più figa del tuo product manager e il prodotto avrà ancora più successo e due quando sei coinvolto e ti senti coinvolto secondo me viene tutto meglio.

E' un impatto sull'ownership e quindi viene assolutamente meglio.

Io declino tutte le risponse, quando hai detto rompete le scatole ai vostri product manager, io declino tutte le risponse.

Caro sindacato dei product manager non sono stato io e Marco.

Fate challenge, invece va fatta challenge per dire così.

Siamo sicuri di aver coperto tutte le, siamo sicuri, aumentiamo la sicurezza.

Dategli però tempo di rispondere, non vi aspettate sempre la risposta immediata perché magari serve un periodo di riapprofondimento, di rivalitazione.

Io...

Cioè questo, non mi interessa.

Esatto, arrampicandoci di spina, scherzo adesso.

Siamo entrati in modalità cazzeggio e con la modalità cazzeggio io ringraziando Marco vi do A.

Grazie ancora.

Grazie, grazie davvero a te per essere venuto e per averci portato questa nuova prospettiva.

Io vi do appuntamento la prossima settimana sempre qua su Gitbar.

Ciao ciao! Ciao a tutti! Gitbar, il circolo dei fullstack developer.

Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie ed strumenti immancabili nella cassetta degli attrezzi dei fullstack dev..