Come Scegliere Strumenti che il Tuo Team di Prodotto Userà Davvero

Leggi la Trascrizione:

Stiamo provando a trascrivere i nostri podcast usando un programma software. Ti preghiamo di perdonare eventuali errori di battitura, dato che il bot non è sempre accurato al 100%.

Hannah Clark: Rapido, senza contare: riesci a dire quanti login usi attualmente al lavoro in una settimana? Se non lo sai, metti in pausa e prova a contare. Scommetto che il numero ti sorprenderà. Infatti, un rapporto CloudZero del 2024 ha rilevato che, in media, ogni dipendente utilizza 36 servizi cloud al giorno e i team di ingegneria ne usano il doppio.

Incredibile, vero? Ed ecco un'altra cosa assurda che probabilmente non ti sorprenderà. Secondo uno studio di CloudZero del 2023, oltre il 53% delle licenze SaaS rimane inutilizzato. In altre parole, nonostante le nostre organizzazioni abbiano un costante bisogno di strumenti per supportare le operazioni uniche, sprechiamo un sacco di soldi in strumenti che, per vari motivi, semplicemente non fanno al caso nostro.

Il mio ospite di oggi è Moshe Mikanovsky, fondatore e principale coach di prodotto presso Products for Good e co-conduttore del Product for Product podcast. Moshe lavora nel settore prodotto e ingegneria del software dal 1989 e, negli ultimi anni, si è concentrato soprattutto nell’aiutare i team di prodotto a prendere decisioni più consapevoli sugli strumenti da adottare.

Va sottolineato che Moshe ha sviluppato un quadro completo per aiutare le organizzazioni a scegliere gli strumenti giusti per le proprie necessità, aumentando così l’adozione e la produttività e riducendo gli sprechi. Discutiamo insieme alcuni punti chiave di questo quadro che possono aiutarti a scegliere meglio già da oggi. Iniziamo subito.

Bentornati al podcast The CPO Club. Oggi sono qui con Moshe Mikanovsky, fondatore e principal product coach di Products for Good.

Moshe, grazie mille per essere qui con noi oggi.

Moshe Mikanovsky: Grazie a voi per l’invito, Hannah.

Hannah Clark: Partiamo come sempre. Raccontaci un po’ del tuo percorso e di come sei arrivato dove sei ora.

Moshe Mikanovsky: Sì, ho iniziato come sviluppatore software molti anni fa. Per i primi 20 anni della mia carriera ho lavorato dal lato dell’ingegneria, in piccole organizzazioni oppure sul campo, collaborando direttamente con clienti e utenti. Questo mi ha aiutato a sviluppare empatia verso le loro esigenze.

Poi, dopo 20 anni, ho deciso di passare al product management. È quello che faccio da circa 14-15 anni. Lo adoro. Mi piace parlare di product management. Amo aiutare le persone a costruire prodotti e vedere che cosa funziona, cosa no, imparare nuove metodologie.

Tutto quello che riguarda il prodotto è parte di ciò che mi fa alzare la mattina.

Hannah Clark: Sei in buona compagnia qui.

Oggi parleremo di un argomento interessante per tutti: gli strumenti. Come i team di prodotto possono prendere decisioni migliori nella scelta degli strumenti per la propria organizzazione. Un tema sempre attuale e anche uno dei tuoi grandi ambiti di competenza. Cosa ti ha ispirato inizialmente a creare il tuo framework di selezione degli strumenti di cui parleremo tra poco?

Moshe Mikanovsky: Sì. Ho un podcast che co-conduco da quattro anni con il mio amico Matt Green. Si chiama The Product for Product.

Nel podcast parliamo essenzialmente di strumenti utilizzati da chi lavora nel prodotto. Da sempre entrambi siamo molto interessati a questi argomenti, ma con approcci diversi: Matt quando è passato al product management, e io per aver provato tanti prodotti diversi in passato, scegliendoli spesso di persona perché nessun altro lo faceva al posto mio.

Vedere quello che esiste sul mercato è sempre molto stimolante. Da queste esperienze mi sono reso conto, registrando episodi su varie tematiche e prodotti a tema, che ci sono alcuni elementi comuni che spiegano perché le persone usano certi prodotti, cosa apprezzano e cosa invece non va bene.

Spesso intervistiamo gli stessi utenti dei prodotti, a meno che non si tratti di startup dove magari non ci sono ancora molti utenti, allora intervistiamo il fondatore. Ma di solito sentiamo chi ha già esperienza e conoscenze su come vengono effettivamente usati, su cosa funziona e cosa no. Da qui ho raccolto molti ragionamenti e punti da tenere a mente, che poi ho riunito in un unico framework che mi piace condividere con le persone.

Hannah Clark: Secondo la tua esperienza, se vogliamo parlare degli errori che si fanno prima di scoprire il modo giusto di scegliere gli strumenti o un quadro metodologico adatto alla propria organizzazione, quali sono gli sbagli più frequenti commessi dai team prodotto quando scelgono nuovi strumenti e a quali conseguenze portano?

Moshe Mikanovsky: Penso che tutto ruoti principalmente intorno al modo in cui vengono scelti gli strumenti, senza focalizzarsi su quanto siano davvero adatti all’organizzazione. Questo è il punto centrale del framework, ma c’è anche il rischio di non comprendere adeguatamente uno strumento prima di sceglierlo. Capita spesso.

Ci entusiasmiamo per un nuovo strumento, guardiamo le sue caratteristiche, pensiamo che sia quello giusto per noi, ma quando iniziamo ad implementarlo ci accorgiamo che non è esattamente ciò che pensavamo. Magari ci siamo lasciati abbagliare dal marketing del venditore o dalle demo che non raccontano tutto, oppure emergono “trappole” che scopriamo solo strada facendo. Insomma, ciò che vedo spesso è una scelta non adatta all’organizzazione e una conoscenza insufficiente su come il prodotto funzionerà realmente.

Hannah Clark: Sì, ha senso.

Bene, allora guidaci attraverso il tuo processo di selezione. Nel tuo framework, il primo passo è identificare i problemi, poi si passa alla priorità e alla selezione di una shortlist e solo dopo si confrontano gli strumenti. C’è quindi parecchio lavoro a monte prima di arrivare alla fase di confronto vero e proprio.

Perché questo lavoro preliminare è così importante prima di lanciarsi a valutare le funzionalità?

Moshe Mikanovsky: Credo sia proprio come per qualsiasi altro prodotto. Da persona che si occupa di prodotto da tanti anni, affronto ogni cosa con lo stesso spirito. Anche qui, è fondamentale capire qual è il vero problema che vogliamo risolvere.

Non vogliamo aggiungere funzionalità a una soluzione che poi nessuno userà. Allo stesso modo, non ci servono funzionalità specifiche se non c’è un problema reale da risolvere. Non bisogna seguire ciecamente quello che fanno tutti gli altri o pensare che il loro modo si adatti automaticamente al nostro contesto.

Quindi, la vera fase preliminare, prima ancora di vedere tutte le funzionalità, è comprendere quali sono i reali problemi da risolvere, cos’è il lavoro che deve svolgere il tuo team di prodotto e quindi di quali strumenti ha davvero bisogno. Poi si passa alle priorità tra queste esigenze.

A volte non possiamo acquistare subito tutti gli strumenti di cui avremmo bisogno. A volte anche solo ottenere il budget per un prodotto è un’impresa. Quindi bisogna capire qual è davvero il problema più rilevante, oppure, se non è proprio un problema, qual è la cosa che ci porta via più tempo o crea più confusione e va sistemata.

A partire da lì va stabilita la priorità e si crea quasi una roadmap per la scelta e l’implementazione degli strumenti nel tempo.

Hannah Clark: Vorrei ora farti una domanda su un aspetto particolare del tuo processo di confronto degli strumenti: la filosofia del prodotto. Questo è il primo criterio.

Che cosa intendi per filosofia del prodotto e perché è così importante? In cosa consistono le differenze filosofiche e in che modo ciò impatta sulla scelta dello strumento più adatto a un’organizzazione?

Moshe Mikanovsky: Una delle cose che mi è capitato di notare parlando con tante persone – ed è stata anche la mia esperienza e quella del mio co-conduttore Matt – è che abbiamo tutti modi diversi di lavorare, comunicare e di concentrarci su certi aspetti rispetto ad altri.

Tutto ciò rientra in quello che chiamo “filosofia”. Ad esempio, alcuni vogliono avere un unico prodotto che risolva qualsiasi esigenza, con dentro tutte le funzionalità che servono, senza il bisogno di integrare altro. Sappiamo però che strumenti di questo tipo spesso sono molto ampi ma poco approfonditi su singole funzioni.

Altri, invece, preferiscono “il meglio del meglio” per ogni singolo problema e vogliono che tutto sia integrato e comunichi perfettamente: soluzione potente ma anche più complessa da gestire. Questa è già una differenza filosofica: che tipo di realtà è la tua organizzazione?

Non sempre è facile definirlo se non si conosce bene il proprio modo di lavorare o chi prende le decisioni, ma è importante chiarirlo: così si delinea rapidamente una short list più adatta. Un’altra questione filosofica è se desideri uno strumento flessibile o “deterministico”.

Alcuni prodotti permettono totale libertà nella creazione di flussi di lavoro e campi: sono generici ma flessibili. Ogni realtà li implementa quindi a modo suo. Altri prodotti – nella stessa categoria – sono molto più deterministici e ti dicono: funziona così e basta. Non c’è un giusto o uno sbagliato, talvolta dipende dallo stadio di maturità dell’organizzazione: se non si conosce a fondo un processo (tipo fare sprint, grooming backlog ecc.), uno strumento deterministico può “insegnare” un metodo, ma sarà uno solo tra i tanti possibili. Man mano che aumenta la maturità, si passerà più facilmente a prodotti più flessibili.

Questi sono alcuni elementi che considero nel framework, che servono proprio a valutare – prima ancora delle funzioni – la cultura e la filosofia più adatta ai tuoi strumenti.

Hannah Clark: A proposito di flessibilità, c’è un altro criterio che vorrei approfondire: la quantità di ingegnerizzazione richiesta nel tempo. È un aspetto interessante. Come si dovrebbero valutare le risorse tecniche necessarie per integrare diversi strumenti e come questo aspetto influenza il successo a lungo termine del prodotto acquistato?

Moshe Mikanovsky: Anche questo rientra nella filosofia: la mia idea generale, per la mia azienda o per quelle che seguo come consulente, è che gli sviluppatori dovrebbero concentrarsi sul valore aggiunto e non reinventare la ruota con cose che milioni di altri hanno già costruito.

Quando aggiungo feature al mio prodotto – come la messaggistica in-app o l’analisi prodotto, che sono già disponibili in strumenti ad hoc – non voglio che i miei sviluppatori se ne occupino, preferisco ci sia un’integrazione semplice e poi basta, lasciando quindi a product manager e altri la possibilità di configurare tutto il resto.

Alcuni strumenti, però, richiedono comunque il lavoro continuo degli sviluppatori: bisogna configurare eventi, personalizzare la grafica della messaggistica e altro ancora. Per quanto mi riguarda (ma è una preferenza personale, non dico sia giusto o sbagliato), considero questa attività una perdita di tempo: preferisco che il valore specifico sia creato da chi può davvero portare qualcosa di unico al nostro business.

Hannah Clark: Parlando di valori aziendali e aspetti più intangibili, hai chiarito che anche fattori culturali come i valori e gli stili di comunicazione impattano sulla scelta degli strumenti. Hai una storia concreta su come questi elementi meno tangibili abbiano influenzato il successo di uno strumento?

Moshe Mikanovsky: Certamente, ti faccio un esempio. In un'azienda dove ho lavorato, abbiamo avuto grosse difficoltà con la comunicazione asincrona. Era piuttosto frustrante per me, anche perché lavoravamo da remoto e uno penserebbe che l’asincrono migliori la collaborazione e riduca riunioni, invece no: eravamo costantemente in meeting per far “avanzare” il lavoro.

Usavamo un sistema di backlog (credo fosse Jira, ma vale per ognuno), documentazione su Confluence, racconti utenti con criteri di accettazione… Dovresti aspettarti che le persone leggano, collaborino aggiungendo commenti, lavorando in modo asincrono. Ma non funzionava. Ogni volta la scusa era: "Non l’ho visto", oppure si tornava tutto a voce in riunione.

Era evidentemente una questione culturale che limitava l’efficacia degli strumenti. A volte mi sembrava di “remare contro”: perfino dopo una sessione formativa su cosa sia la comunicazione asincrona e perché sia importante — non so nemmeno se abbia aiutato!

Ecco di cosa parlo: prima di tutto bisogna comprendere le caratteristiche della propria organizzazione. Uno strumento non aggiusterà la cultura, ma può aiutare solo se viene effettivamente usato nel modo giusto e se la cultura ci va a braccetto. Solitamente, uno strumento non cambia la mentalità, anche se può favorire certi cambiamenti. Bisogna sempre considerare i vincoli culturali e poi trovare lo strumento adatto.

Hannah Clark: È molto più chiaro così.

Torniamo ora al confronto delle funzionalità: abbiamo visto l’importanza del lavoro preliminare e delle considerazioni più “soft”. Molti team partono invece dal confronto diretto delle funzionalità e dal prezzo. Perché questi aspetti arrivano così tardi nel tuo framework?

Moshe Mikanovsky: Principalmente perché preferisco che le persone si focalizzino sugli output di ciò che possono ottenere usando uno strumento, piuttosto che su ciò che possono “fare” immediatamente.

Le funzionalità sono più facili da confrontare, e spesso le aziende propongono la lista di feature. Ma guardando nei dettagli – che a volte sono pubblici, a volte no – capisci se davvero sono quelle che ti servivano. Spesso cambiano i nomi delle cose, variano i prezzi per singole funzioni, il che va anche bene, ma poi sta a noi fare l’analisi e selezionare il prodotto davvero giusto per noi.

Però il punto più importante è che la selezione deve essere guidata dagli outcome, dunque dai risultati desiderati, non solo dagli output disponibili. Non si tratta di “questo strumento può fare questo o quello, quindi è il migliore”, ma di quale strumento veramente conduce agli effetti desiderati.

Hannah Clark: Parliamo ora forse della parte più frustrante nell’implementare uno strumento nuovo: farlo adottare da tutti e assicurarsi che venga usato davvero, e nello stesso modo, in tutta l’organizzazione.

Soprattutto dopo un processo così lungo per scegliere, adattare e personalizzare lo strumento, spesso è ancora difficile ottenere adozione diffusa e coerente. Quali sono alcune strategie chiave per assicurarsi una buona adozione trasversale nel team?

Moshe Mikanovsky: Il primo passo è scegliere lo strumento giusto, oppure almeno quello meno inadatto (perché qualcosa da sistemare ci sarà sempre). Il secondo è il processo di selezione stesso: non è uno step facile e molto dipende da chi lo gestisce, dalla governance e dal processo di decisione.

Potresti avere contrari già in questa fase – non esiste una regola d’oro, ci sto ancora lavorando e arricchirò il framework con i suggerimenti di altri in futuro. Coinvolgere molte persone nel processo di selezione può allungare i tempi e rendere più difficile arrivare a un consenso. Alcune culture organizzative puntano sul consenso, altre sulla decisione a maggioranza. È anche importante definire chi è il vero “owner” dello strumento, non solo nella scelta e implementazione, ma anche nell’adozione effettiva.

Tradizionalmente, questo ruolo era dell’IT (che intallava il software sui computer) ma spesso non seguiva davvero il successo dell’adozione. Serve quindi un vero "campione" che porti avanti anche la fase di implementazione.

Oggi, con il product ops, in alcune realtà è più facile perché si può collocare tutto lì, soprattutto se si vuole standardizzare l’uso degli strumenti. Il product ops può capirne le esigenze trasversali e specifiche, le difficoltà, le differenze tra team, i problemi personali e progettuali…

Come per ogni prodotto (specie nel B2B, che è il contesto qui affrontato) serve tanto lavoro di “evangelizzazione”, formazione, iterazione e ascolto. Non bisogna implementare tutto subito: è meglio procedere per iterazioni, come per qualsiasi prodotto.

Hannah Clark: Sì, ha senso. Un processo di onboarding graduale permette anche di ascoltare gli utenti strada facendo. Almeno in questo caso puoi avere più contatto diretto con chi utilizza lo strumento, il che è certo un vantaggio.

Moshe, grazie davvero per essere stato con noi oggi. È stato molto istruttivo. Credo davvero che queste indicazioni siano utili a chiunque si trovi a scegliere e implementare nuovi strumenti – sappiamo che può essere un percorso. Grazie per la tua guida! Dove si può trovare il tuo framework di selezione strumenti e come entrare in contatto con te online?

Moshe Mikanovsky: Grazie ancora a voi. Potete trovarmi su LinkedIn cercando il mio cognome, Mikanovsky, oppure sul mio sito productsforgood.co. Il framework è pubblicato come board su Miroverse: c’è il link sul mio sito nella sezione risorse.

Volentieri ti passo il link per inserirlo nella descrizione della puntata così chiunque può usarlo e copiarlo: ci sono spiegazioni, risorse aggiuntive come una tabella Airtable con l’elenco dei prodotti per categoria. È un lavoro in corso, perché continuo a scoprire novità, quindi se mancasse qualcosa scrivetemi pure su LinkedIn: mi farà piacere sentirvi.

Hannah Clark: Ci farà molto piacere condividerlo e grazie mille di tutte le risorse e del tuo tempo.

Moshe Mikanovsky: Un piacere. Grazie mille, Hannah.

Hannah Clark: Grazie per l’ascolto. Per altri approfondimenti, guide pratiche e recensioni di strumenti, iscriviti alla nostra newsletter su theproductmanager.com/subscribe. Puoi ascoltare altre conversazioni come questa abbonandoti a The CPO Club ovunque ascolti i tuoi podcast.