Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio qua sul nostro bar degli sviluppatori ancora un'altra settimana e noi ritorniamo sulle vostre orecchie per rompervi le balle parlando di sviluppo e non solo e oggi andiamo ad affrontare quella parte che riguarda il non solo che però ha un'importanza fondamentale in quello che facciamo tutti i giorni prima di svelarvi l'argomento e come nostra consuetudine prima di svelarvi il nostro ospite di oggi il mio ruolo è quello di ricordarvi i nostri contatti info@gitbar.it o @brainrepo è il modo classico per contattarci abbiamo però anche il nostro gruppo telegram se non l'avete ancora fatto mi raccomando iscrivetevi e basta non 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 [Musica] L'ospite di oggi è un product manager con i 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 produtt owner Ed è un king sull'argomento e infatti oggi abbiamo con noi Marco Loche Product manager a Hootsuite.Ciao Marco! Ciao Mario grazie per l'intro Ho dimenticato qualcosa perché so che fai 70.000 cose in realtà No, diciamo che la cosa principale sono papà di tre bambini e poi sì, product manager a Woodsvit con un grande impegno, mi prende tutto l'impegno lavorativo, bell'esperienza.Con Alessio abbiamo lavorato diversi anni insieme e grazie a 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 di produtt owner.La prima cosa che ti voglio chiedere però è questa, io so che tu hai un passato da software engineer.Sì esatto, infatti dall'intro di Gitpar mi sono sentito di nuovo a casa.Esatto.Sono laureato in ingegneria informatica, ho sviluppato per 15 anni, fino a 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 poi a un certo punto sono tornato, 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 ancora oggi continuo a esistere, non faccio più direttamente parte, sono sempre socio, ma società che sviluppa corsi learning, ma appunto è 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' un 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 te ne, 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 si conosce, 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 Woodsfit, e prima di Woodsfit Adespresso, che è la startup che è stata acquistata da Woodsfit, 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'è quel lato 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 mio focus.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 che quando inizi a parlare con i clienti inizi a capire che a volte ci sono soluzioni che tu puoi fornire senza neanche dover 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 dover sviluppare una soluzione software.Quante volte c'è capitato 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 sul lato cliente, ho detto processo tipo sette volte, vabbè, perdonatemi, ma avrebbe evitato magari mesi e mesi di lavoro su una feature che alla fine...Sì, quello sono...sì, sicuramente succede più nel mondo del consulting, no? Quando tu devi andare da un cliente a risolvere un problema specifico.In Utsu insieme a SaaS, quindi siamo una piattaforma self-serve, 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 self-serve, quindi non abbiamo clienti che arrivano e ci richiedono di costruire un software per loro, il nostro software è quello che vendiamo, quindi dobbiamo fare in modo che segua le richieste e le esigenze, 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 quindi di dare più un ruolo di staff o di profili più elevati di architettura, poi la carriera manageriale.Beh, idem per il product manager.Chiaramente quando inizi il ruolo produttore, l'associate pre-em, 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 nel giorno.Poi ovviamente con l'esperienza ci si muove sempre più su un lato strategico quindi andare veramente ad approfondire quali sono le problematiche dei vari stakeholder, interagirsi con tante figure, che è un altro aspetto molto interessante del ruolo di 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 engineering che magari può venire con richieste di debito tecnico da risolvere, che devi priorizzare perché magari hanno un impatto sui clienti.Quindi spesso ci sono giornate in cui sei tutto il giorno a parlare con persone, quindi raccogli informazioni, cosa che di solito, almeno i miei team di sviluppo, odiavano le quindi penso che non sto attirando la attenzione di questo pubblico di oggi, di molte persone nel ruolo, però in realtà c'è sviluppato interessante perché poi da lì devi raccogliere tante informazioni, andare a interagire, capire qual è la cosa più importante da fare come prossimo step.- Scusami, vai! - Vai, vai, vai! - No, no, no, fai pure! - No, sto dicendo, certo, poi, se invece vogliamo parlare di qualcuno che è più integrato nei flussi di sviluppo, quindi nel day to day, col team di sviluppo, pensiamo al product owner, a qualcuno che...Noi non seguiamo metodologie specifiche con Dev Manager con cui lavoro, di solito cerchiamo di orientarci, di prendere, di adattare, di adattare le 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 lì multidisciplinari, non parlo solo di sviluppatori, mi fa parte veramente del team ristretto anche il design quindi che si occupa della user experience, seguire il 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 del product manager è quello di avere ed alimentare la visione del prodotto, avere una product vision.Come fai tu oggi, 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, al priori 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 WoodSuite, recuperi un prodotto che esiste, lo intervieni, lo recuperi come responsabilità, lo devi portare avanti o siamo in un prodotto magari in cui va fatta la madness.Parliamo di un nuovo prodotto, il nuovo prodotto prima di tutto va fatto un business case, devi capire un'opportunità, se c'è un'opportunità precisa per l'azienda e per i lavori, quindi fai 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 i clienti, è quel ruolo di collezione di tutti i feedback, di input che arrivano dai vari stakeholder che ti permette di creare e di generare nuove idee che poi idealmente dovresti andare a validare in modo rapido sul mercato.Quindi ti faccio una domanda, il ruolo del product manager è anche quello di farsi il il suo bel canvas, andare alla ricerca del valore.Questo è del product manager o ci sono altri ruoli con cui condivide questo tipo di responsabilità? Io penso che dipende un po' dalla dimensione dell'azienda, un po' dalla 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 tutte varie metodologie, framework di definizione di product discovery di valutazione, perché poi alla fine della fiera ha identificato un problema che vuoi risolvere, che fa parte del tuo segmento di mercato.Vuoi risolvere un problema di un cliente che hai identificato in qualche modo, vuoi perché i sales siano fatto parte di una feature gap rispetto ai competitor, vuoi perché facendo interviste con i clienti che ti fanno notare che manca una parte.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 potenziale ha, quali sono gli outcome che vuoi risolvere, quale valore aggiunto darai al cliente nel risolvere quel problema, che è poi una parte centrale nella costruzione del prodotto, ma ancora prima di tutto questo devi fare una dictazione di business, cioè 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.In questi stakeholders possiamo distinguere varie categorie.Il stakeholder con cui devo interagire ad hoc perché ho una certa problematica, quindi parlo dei stakeholders con cui interagisco meno frequentemente.Nel nostro caso abbiamo i PI esterni, 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 questa roba.Quindi questi sono i stakeholders attuali.Ci sono stakeholder, come dire, board of director in cui noi, product manager, almeno in Utsuite, abbiamo comunque delle sessioni di planning trimestrale quindi con questi stakeholder viene un'interazione 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 con un sacco di persone magari inquadrati con del lavoro preparatorio.E poi c'è il day to day, come dici tu, è il team, il team più stretto il team di portfolio, perché magari in un prodotto come WoodSuite 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 è una ventina di sviluppatori che poi andranno a sviluppare.Lì abbiamo vari modi, ci sono tutte le cerimonie simil-scrum, simil-agile, quindi riunioni ricorrenti dove ti interfacci e fai modo che se io ho la riunione in cui dobbiamo discutere della prossima funzionalità ci sono sia i dev manager, sia i designer, la triade come chiamiamo internamente e ci interfacciamo e fai in modo che le cose vengano fluide.Se c'è un blocker, di solito mi adopero perché venga affrontato.Gli ingegneri, gli sviluppatori vengono e ci dicono "ragazzi, qui abbiamo un problema con queste piagge, bisogna chiamare il partner" e lì parte 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 prodotto owner in capo al prodotto owner c'è la decisione su una feature o un'altra da implementare è la priorità spesso attorno al prodotto manager e al prodotto owner c'è un certo ignoto no? Quindi come fa questa figura a prendere delle decisioni senza fare un guessing game troppo grande? Non c'è magia, c'è tanta razionalità.Da una parte tu hai 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ù vago per fra due anni.Hai una direzione che stai andando, stai validando, stai facendo user request, 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é nelle sorprese ci sono sempre, l'intoppo arriva e lo fai facendo trade off.Lo fai facendo trade off, quando sono trasparenti, comunicati e condivisi dall'inizio è sempre meglio perché magari poi hai il design controparte e magari tutti si mettono di mezzo, perché magari tu vuoi andare live, ma loro sono i guardiani dell'esperienza e vogliono essere sicuri.Quindi spesso quello che io faccio quando parliamo di 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 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 negozia all'inizio in queste discussioni che fanno parte dell'iteratività, del planning, della condivisione della roadmap e insomma questa è una tipologia di funzionalità abbastanza straightforward poi ci stanno da un'altra parte la necessità di gestire bug perché i bug ci sono, arrivano dal supporto, arriva il ticket, 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%, diventa una priorità e passa davanti a tutto, fai spring planning e la porti per prima davanti, non puoi perdere clienti.Quindi non c'è una legge assoluta, ci sono aspetti per cui la priorizzazione sulle nuove funzionalità è una priorizzazione che è posata così.Ho degli obiettivi, soprattutto quando inizi a avere accanto tra gli stakeholder 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 trad off e decidi che il minimo con cui si andrà live è quello.Se poi non si va live non è la fine del mondo, si cambia di piani, si comunica e si ferma il marketing.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 soddisfare in tempo.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 davanti, c'è una sessione e vai davanti ai stakeholder, 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 assorbire nel nostro processo il fatto che ci possa essere cambiamento e quindi andare e accettare che ci sono cose imponderabili.Poi noi lavoriamo con i social network, in un suito abbiamo API, abbiamo social network che dall'oggi al domani ti cambiano le API facendo finta di comunicarti ma poi fanno altri cambiamenti senza dirti niente, roba che si spacca così dal giorno all'indomani, piani che saltano e quindi si affrontano queste situazioni di criticità.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? 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.Cerchi di pianificare i prossimi più o meno due mesi di capacità perché devi allocare un progetto prioritario dell'azienda quindi devo allocare tempo sul team, su queste user stories, 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 Chaos Time.Il Chaos Time sono 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 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 non stimabile? Più o meno conosci...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 affulmina il cerseneno, 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 la partnership sei lì.Quindi questo tipo di caos no, non è gestibile e là entra tutto il change manager, quel processo se ti dicevo in cui tu fai risalire "sto bloccando tutto, non si rilascia più niente, dobbiamo risolvere prima questo incendio, spegniamo l'incendio e poi si ritornano a normale".Causa 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 il DPI diventa tutto un po' più sotto controllo, riesci a pianificare.Sai che 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".Sì.Qua 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 appunto quello che si potrà realizzare è fondamentale per poter poi interagire in organizzazioni complesse dove tu poi hai marketing, devi andare a svolgere attività magari appunto 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 far girare tutto il meccanismo intorno.Il meccanismo deve saper controllare le situazioni di eccezione, 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 avere.Però poi ti...facciamo un'altra puntata magari con il mio dev manager di fiducia abbiamo lavorato per anni su come ottimizzare e cercare di essere più predittivi nel valore rilasciato 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 rilasciato del valore concreto piccoli mattoncini che poi alla fine faranno, costituiranno magari una funzionalità abbastanza strutturata da poter essere lasciata.Chiaro, 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 averceli sotto mano 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, no? Che è quello con cui deve lottare tutti i giorni il buon Marco.Però a quel punto c'è un elemento di comunicazione nel quale poi 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 è importante che ci si senta parlare è importante che ci si senta partecipi del successo del prodotto che si costruisce e coinvolti e per fare questo poi c'è 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 e ci si può adattare al cambiamento, all'imprevisto, a 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 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, ma perché è 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 di 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 quell'MVP e sei contento e quindi dici ok adesso adesso abbiamo magari altro da fare, adesso c'è questo aspetto tecnico per cui abbiamo queste API che rispondono in tempi non accettabili, 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 perché c'è una nuova funzionalità oppure ti devi adattare alla nuova priorità e seguirla.Dopodiché, ecco una critica che posso fare se no sembra che siamo una società idillica garantire in modo costante spazio per manutenzione per far evolvere una funzionalità che dimostra di avere potenziale è assolutamente importante.Spesso, come dici te, si rincorre l'ultima shiny thing, l'ultima cosa brillante che arriva e ti metti tutti in corsa a fare quella cosa lì, tutta la società diventa focalizzata su lì, arriva il mandate dall'exec o dal business, cioè sono metriche che vengono prese in considerazione, con le metriche di business che diventano quelle principali e quindi ti devi adattare su quelle e quindi magari appunto quel backlog viene sacrificato perché 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 mantenere una funzionalità che ti porta a una buona fetta di revenue.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 prese.L'unico strumento che hai è dimostrare con dati, dimostrare magari valore che stanno rischiando di perdere.E a loro l'ultima parola però.Eh, 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? Una metrica specifica non avrebbe senso? No, di solito è un processo un po' top down, hai degli obiettivi aziendali che possono essere crescita delle fezioni, risoluzioni di problemi, di conversione, che possono essere metriche di business o semplicemente crescita 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 un ciclo di vita del prodotto intendo metriche che riguardano quante persone hanno scoperto quella 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 discoverability della funzionalità che ho sviluppato, perché penso che è quello che li convincerà a diventare abbonati.Quindi quell'azione specifica è in capo comunque al prodotto manager? Si, al prodotto manager a vari livelli, quindi poi ti agganci alle metriche, alle KPI aziendali, cerchi di farle a cascata corrispondere con la funzionalità, di solito tu hai deciso, stiamo parlando di una nuova funzionalità, oppure di risolvere un problema di prodotto, perché le persone non si stanno iscrivendo al sito? Non si stanno iscrivendo al sito perché ho un problema sul forum? Questo magari lo dai analizzando un funnel.Poi hai metriche più di utilizzazione del prodotto che quelle diventano 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 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 ad analizzare, magari c'è un bug scoprindo guarda Mauro, ci sei? sì sì ci sei, sei andato offline ho crashato di brutto così, ho schermato una mia neural dicevi...Sì, quindi diciamo che stai creando una nuova linea di prodotto.Devo lanciare, adesso sto facendo un business case per riposizionare un prodotto.Lì stiamo facendo proiezioni di business, ci agganciamo a delle metriche, dobbiamo ottenere delle nuove revenue, stiamo facendo proiezioni di quante revenue, come faccio a trovare le revenue, sto poi modellando.dovrò modellare poi le metriche di successo, quindi come misurerò il fatto che le persone stanno stanno adottando il prodotto che vado a creare.Ed è importante che il prodotto che vado a creare sia tracciabile nella sua utilizzazione, perché, come dicevo prima, invece sono altre metriche, più a basso livello, più vicine proprio al prodotto stesso, che mi permettono poi, in fase di evoluzione o di maintenance, 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 informazioni, e non riesco a implementare quel form che magari deve avere dei widget complessi, perché sono, come diciamo prima, il throughput è finito e ho potuto fare 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 fichissimi che ci siamo immaginati, che non vuole usare nessuno, l'ho salvato.Quindi, per tornare alla priorizzazione, un po' dipende sempre dalle funzionalità.Sto valutando del backlog di feature che magari sono rimaste indietro, ma servono veramente le metriche di prodotto, di utilizzazione, di adoption e mi servono a fare decisioni lì.Sto lanciando un nuovo prodotto, devo pensare alla prossima epica da sviluppare, vado magari più ad allinearmi sulle metriche di business e magari con andarli ad associare una metrica di product life cycle e valutare qual è la prossima epica da fare per essere allineati col business.Spero sia chiaro, non so quanto...sì no no è più che chiaro la mia domanda è per quanto riguarda i metri che 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 o poi per prendere delle decisioni in merito al prodotto? All'impatto immediato sono dati anonimi, ma alla fine sono dati quantitativi.quindi sai, non vaia.Finché gli utenti poi sono registrati, quando si servono dei dati non anonimizzati, sono utenti, quindi abbiamo possibilità poi, se dobbiamo andare a vedere una feature, magari uno gli estrae le loro informazioni e se hanno dato il consenso magari riesce anche a intervistarli, quindi a contattarli.Non penso che sia, a livello di product analysis, c'è stato un grande impatto, mi immagino sia più pesante per chi fa marketing, per chi fa advertising, retargeting, tutti questi aspetti dell'advertising moderno legati al social network, ai motori di ricerca.Lì probabilmente GDPR ha un impatto molto più importante.A livello aziendale sicuramente ha avuto un impatto, ci sono costi di gestione, etc., quindi 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.Dal punto di vista mio non penso di aver perso qualcosa, nulla di essenziale, quello che invece è essenziale è avere una strategia di tracciamento dati strutturata bene, fatta in modo opportuno, sapendo utilizzare la piattaforma di tracciamento in tutte le sue funzionalità, perché poi il problema che abbiamo è che Spesso i dati sono...non sfruttiamo tutta la potenza delle piattaforme che abbiamo perché non c'è stato abbastanza lavoro di progettazione, di convenzioni.Diventa difficile perché poi ogni team in passato aveva creato eventi, per esempio non seguendo sempre le stesse convenzioni.dove creare vocabolari o riconciliare.Insomma, è 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 chiare 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, fa parte della fase di progettazione, abbiamo un momento in cui mi occupo di definire il piano di tracciamento dati, quindi il cosa e il perché stiamo tracciando, quali informazioni di corredo vogliamo associare, e questo poi in realtà è fondamentale che avvenga anche in 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 developer, del designer, aiutano il product manager.Il product manager non può fare tutto, ha bisogno di tutti gli stakeholders, fa tutto e non fa niente.Il product manager è 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.Hai parlato di team, il ruolo del product manager è quello di fare da ponte tra i vari stakeholder, è uno dei suoi ruoli più importanti.Abbiamo anche parlato di di KPI e di obiettivi di prodotto.Come fai a costruire la comunicazione tra il team, tra te che sei un product 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, stiamo parlando di progetti, stiamo facendo un progetto che durerà magari un paio di mesi, parlavamo prima di planning trimestrale, di una revisione più o meno trimestrale o semestrale, lanciamo un progetto e di solito viene fatto un kick off, viene introdotto il progetto, viene dato il contesto di business, perché stiamo facendo quella 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 il design, con il developer, insieme.Però abbiamo un contesto generale di...inquadriamo nel business, inquadriamo lo use case, questa funzionalità è la top request che è arrivata tramite il supporto, dobbiamo duemila 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 delle iniziative, questo parecchio prima, perché poi parte una fase di studio, di analisi, 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 a un'esigenza di business validata da numeri che avrà questo impatto quindi porterà tot, tot sold, tot 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 e 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 e 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 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 idee vengono perché poi magari lo sviluppatore è quello che tocca con mano l'API del partner e sa esattamente quale informazioni ne condivide magari la documentazione.Leggo anche io le API, leggo la documentazione, però poi magari lavorandoci dentro c'è un'idea che viene da ognuno per le sue responsabilità.Il designer per esempio avrà da digerirsi una serie di informazioni che vengono comunque tolte in queste riunioni e poi sarà lui a immaginarsi l'esperienza, come sarà il senior developer immaginarsi magari un'architettura che serve per rispondere a quella cosa, però tutti insieme si può vivere.Diciamo che il mio ruolo è, dal business abbiamo identificato, dal business, dagli stakeholder 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 reattivo 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, il team di prodotto che magari affigure come tu puoi avere il junior developer che si occupa magari soltanto di sviluppare magari un widget e dietro hai lo senior che costruisce invece tutta l'API dietro e tutta l'infrastruttura e 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, no? Abbiamo questo blocker e quindi lì tu devi essere con il team, abbiamo il product manager, questo 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 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ì è accascato.a chi anche lui.Guarda ogni risposta che mi dai mi triggeri subito 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 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 definiti dal board, priorità.La priorità può essere "il business scopre che quella linea di prodotto ha una redditività maggiore e ci si focalizza su quella soluzione, quella soluzione diventa importante, ci sono discussioni di priorizzazione".Di linea guida che dà al board ci si riunisce e si dice "ok, questa parte deve essere prioritizzata, ci dobbiamo orientare più su questa fascia di clienti che possono essere clienti di un certo piano piuttosto che un altro perché sono più redditizi o perché in quel momento c'è una patente.Quindi viene data un'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 più di piattaforma, magari tu hai dei servizi core che ti gestiscono l'autenticazione o la gestione delle utenze o la gestione del billing, 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 io voglio fare è allineata con questa particolare indicazione del business e porterà tot alla company e mi dovete far fare questo lavoro, però lo E sei continuamente messo alla prova immagino? Dopodiché è un lavoro che non è improvvisato, si sei 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 Sì, spero che sia stato chiaro, però gli elementi, le metriche sono quello che ti aiutano, c'è pianificazione che viene fatta, c'è una continua ricerca, una continua validazione di quello che è stato rilasciato e quello che non è stato fatto va rimesso in discussione prima di poterlo digerire solo perché stanno in backlog.Quindi è un'analisi continua, non è che c'è una cosa più prioritaria perché ci piace a noi o perché il design è figo.Se poi scopro che… 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 intuitivo? con il crescere della seniority nel tuo lavoro? L'intuizione viene da...viene sinceramente da...non lo so, sono forse troppo empirico, non ce la faccio, ma viene dall'esperienza, raccogli dati, voglio dire, 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 mi viene un'idea, o proprio intellettualmente.Analizzando tutti i scontri, vieni a conoscenza di situazioni.L'esperienza sicuramente ti permette di non essere banale nell'ideazione dei requisiti e nell'identificazione della problematica da risolvere.Tutto sa cosa voglio risolvere.L'intuizione è capire, 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 tu hai queste relazioni continue.L'intuizione dal tuo punto di vista, era una domanda del cazzo, perdona.L'intuizione poi se ce l'hai ben venga, devi avere il coraggio di partire su quell'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, 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 "ad minchiam", 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, devi prendere delle decisioni dove fermarti, perché devi andare, non puoi avere il prodotto perfetto.A un certo punto dici "ok, questo è abbastanza lì".In base a questi feedback, in base all'outcome che tu aveva già, fai comunque una scommessa, penso che è una scommessa che devi fare a un certo punto e ti prendi.Questa è una delle parti più toste, di prendere le decisioni di dire "ok, così possiamo...e ci metti la faccia, ci metti la faccia anche con tutte queste cose, questo possiamo andare...andiamo così e poi scopriremo, scopriremo se abbiamo toppato o no, cioè non avrai mai la scienza, 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...potevi lanciare molto prima, no? Con una cosa veramente minima.Ho visto piattaforme con delle interfacce penose 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.E per fortuna non sono mai entrato in quel mondo.Per fortuna da quello che sento non sono mai entrato in quel mondo.Guarda io ci sto lavorando questi giorni 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 no, noi ne abbiamo fatte tantissime perché a parte l'API dei social network facendo advertising abbiamo tutte le API, CRM vari avevamo un prodotto che faceva sincronizzazione con i CRM e c'erano le API e poi, dai, se non mi vuole di nuovo non farò nomi però, insomma, che grossi attori che avevano cose abbreganti ma, guarda, io ho visto cose API che trasformavano le virgole in slash senza senso, però beh...perché avevano deciso così, di standard assolutamente, mamma mia che...guarda, c'ho il terrore la notte quando mi addormento voglio gli incubi no, è un lavoro interessante tra l'altro mi viene da chiederti cosa porti la tua esperienza da sviluppatore nel tuo lavoro tutti i giorni? Dopo qualche anno quello che 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, il 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, abbiamo 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 dover rinunciare a delle cose perché vuoi andare in produzione, perché serve andare, perché voglio validare.E lì sono discussioni del tipo "dei mettere sul piatto, ok, avremo debito tecnico, è un rischio che devo accettare e me ne prendo la responsabilità".Però dovete accettarlo anche come sviluppatori 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 mesi a sviluppare una cosa e quella cosa è un fallimento, io ho perso tempo tutti.Te faccio una domanda che mi viene proprio da una discussione che avevo con mia moglie oggi.Ci sono dei contesti dove tu, 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 un sviluppatore.So che è quello che dice.Nel contempo il software engineer sta mergiando del codice monnezza a sua firma e ha una percezione di simile denigratoria, dice "prima o poi qualcuno leggerà questa codebase e io sarò trattato come il coglione che ha scritto queste cose aberranti".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...Prima 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 e abbiamo un backlog di debito tecnico io sarò sempre quello che lotterà per avere spazio per consolidare, perché sono il primo a sapere che se quel debito tecnico non viene risolto mi si rivolgerà contro.Non puoi più stimare niente? A parte i casi in cui tu ti trovi con una codebase che è una nondezza 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 buon padre di famiglia 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 l'Steam e 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 tu te lo allocchi già allo slot per fare il refactoring o lo postponi, nel senso mi porrò il problema se la cosa funziona allora, quello che di solito chiede è che venga documentata quindi che sia nello subbanco che quella è stata una decisione.Allocare qualcosa per risolvere un problema che non sappiamo se poi in realtà vale la pena risolverlo? No, quello che abbiamo è una banda dedicata a gestire, Idealmente bisogna difendere questa banda dedicata a gestire il debito tecnico, come gestire anche i bug, che magari ci sono bug prioritari, altri meno, miglioramenti dell'esperienza.Torniamo al primo discorso del backlog, ma quando facciamo attività di pianificazione di solito cerchiamo di riservare una banda al...- E quindi poi...- Dopodiché appunto...- ...gestisce una priorità anche in quello, no? - Dopodiché appunto arrivano...poi arrivano i 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 successivo e quindi magari viene parcheggiata e si porta quel debito, però poi è una decisione di 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.Chiaro, è 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 o un limite o andare a spiegare al designer che quel flusso strafico che ha pensato sarà limitato.Come per fare questa cardina che vola in giro per la pagina.E 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.Sai che farei con tutti, ma là si vede la tua parte da software ingineere.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 poi io capisco che il lato prodotto, perché sono una persona molto produttiva, centrica, 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 la 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, il 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 vintuto è il concorso, 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 il prodotto.Cioè, 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 a 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 la definizione di priorità, perché hai degli obiettivi molto precisi.Quindi andassi 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, conferenze più importanti nell'ambito del product management.ci sono i product tank che sono conferenze locali a cui, probabilmente, 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 empatizzare con le problematiche di priorizzazione del prodotto e avere un buon approccio mentale a come immaginarsi le soluzioni.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 si chiama? Come riso, RISE, che sta per Rich 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 generale? penso di aumentare il revenue di tot per cento.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 devono poter stampare il pdf e la dashboard.Lì ho una confidenza alta, 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 diventa, è una cosa di autovalutazione.non so se ti è mai capitata, ma i professori ti chiamano "autovalutati", no, non devi imbrogliare, devi avere fatti, 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 interazione, dove hai già iniziato a parlare con i developer, con il designer, ti fai un'idea di massimo quanto potrebbe volerci.Noi usiamo dei fattori moltiplicativi, per esempio su quanto potrebbe volerci, lo stiamo facendo senza conoscere benissimo la soluzione, quindi aggiungiamo un fattore di rischio.È un framework che può aiutare a definire la priorizzazione a più alto livello, non delle singole storie, ma magari di epiche, o un gruppo di epiche che ha un problema di business.Sono due spunti, poi framework di prodotto, la letteratura come tutto, anche con i processi, non amo l'ortodossia, amo contaminarmi di idee e adeguarle alle esigenze della azienda, team, del modo di lavorare, di essere di ognuna.Chiaro, altrimenti il silver bullet non esiste, quindi più...fondamentalmente la metodologia è il bignamino di un'esperienza, no? O di più esperienze.Quindi se tu prendi tanti i bignamini di più esperienze li metti insieme gli orchestri e hai un toolkit da utilizzare vedo che Marco è di nuovo caduto eccoti qua Ecco di qua.Anche 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 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 e ce ne ha mostrato le problematiche perché spesso il rischio è quello di subirlo il produtt manager invece con questo tuo racconto diciamo hai abbiamo fatto un passo verso l'empatia verso il produtt manager e noi sviluppatori sappiamo che non siamo esseri molto empatici quindi per questo ti ringraziamo Marco, ti ringraziamo di cuore a nome è 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, che quando capisci che cosa, quale problema stai risolvendo, uno magari hai un'idea anche 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.Ha un impatto sull'ownership e quindi viene assolutamente meglio.Io declino tutte le risponse.Quando hai detto "rompete le scatole ai vostri prodotti manager", io declino tutte le risponse, caro sindacato dei product manager non sono stato io e Mario fate challenge, invece va fatta challenge, siamo sicuri di aver coperto tutte le, siamo sicuri no? Mettiamo la sicurezza, dategli però tempo di rispondere, non vi aspettate senti la risposta immediata, questo sì, perché magari serve un periodo di riapprofondimento, di rivalitazione.Io...Cioè questo, no? Esatto! Lei? Arrafficando tutti i dispi...no, scherzo adesso.Siamo entrati in modalità cazzeggio e con la modalità cazzeggio io ringraziando Marco vi do A.Grazie ancora.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 Bar, 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 e di strumenti immancabili nella cassetta degli attrezzi dei Fullstack Dev.[Musica]
