|
Ascolta
|
Nel contesto aziendale attuale, riuscire a connettere le attività quotidiane dei team di prodotto con gli obiettivi strategici dell’organizzazione è diventato un elemento chiave per il successo. Tuttavia, molte aziende tendono ancora a focalizzarsi principalmente sulla quantità di output generati, trascurando una visione più ampia e una cultura realmente orientata al valore.
Come possiamo quindi garantire che ciò che realizziamo generi un valore concreto per gli utenti finali e per il business? E quali metriche possiamo adottare per misurarlo in modo efficace?
Per approfondire questi interrogativi, abbiamo parlato con Fabio Panzavolta, esperto Scrum Trainer e consulente di product management, con cui abbiamo esplorato i concetti fondamentali di output, outcome e impatto.
Benvenuto Fabio, per iniziare ti chiediamo di presentarti e di raccontarci il percorso che ti ha portato a diventare di Scrum Trainer
Mi sono laureato in scienze dell’informazione a Bologna nel 2001. Successivamente, ho cominciato ad occuparmi di sviluppo software perché il mio sogno era quello di realizzare videogiochi ed è un po’ anche il motivo che mi ha portato a scegliere scienze dell’informazione. Poi la realtà è stata un pochino diversa, infatti ho lavorato nell’ambito dello sviluppo software per 5- 6 anni e successivamente ho iniziato a fare il Project Manager.
Per circa 6-7 anni ho lavorato come Project Manager e poi come Program Manager, soprattutto in ambito bancario, logistica e trasporti. Ma a un certo punto mi sono reso conto che, nonostante l’impegno, non riuscivo a ottenere i risultati che speravo. E per me è fondamentale riuscire insieme al mio team. Così ho capito che il classico project management, soprattutto nel mondo IT, non mi dava più soddisfazione. Proprio in quel periodo, nel 2014, ho scoperto Scrum e ho iniziato ad applicarlo. All’inizio, però, il mio ruolo era un po’ ibrido: una via di mezzo tra Project Manager e Scrum Master.
Ho cominciato a studiare l’argomento, informandomi sulla piattaforma di Scrum.org. Poi, un po’ per caso ho preso la certificazione, e alla fine, un passo dopo l’altro, ho provato a candidarmi per diventare Professional Scrum Trainer, pensando che non avrei mai ottenuto quella posizione.
Alla fine, invece, hanno accettato la mia candidatura e sono entrato a far parte di Scrum.org nel 2018.
In tutto questo però un’esperienza fondamentale è stata lasciare l’Italia nel 2001. Un’esperienza che sicuramente mi ha arricchito, non solo dal punto di vista dei contesti aziendali nei quali ho avuto la possibilità di lavorare, ma anche nel contesto culturale che mi si è presentato davanti. Credo di aver lavorato praticamente con tutte le nazionalità del mondo.
In breve, posso riassumere il mio percorso dicendovi che la ragione che mi motiva ad alzarmi ogni mattina, come prima cosa, è aiutare gli altri. Al secondo posto c’è ottenere risultati in team, risultati che non potrei raggiungere da solo.
Guardando il tuosketch, come i concetti di output, outcome e impatto legano il lavoro quotidiano e perché è importante parlarne in ambito di prodotto?
Quando si sviluppa un prodotto, due aspetti fondamentali dovrebbero guidare il lavoro:
- Creare sinergia all’interno del team,
- Contribuire alla strategia aziendale.
La vera sfida nel lavorare in gruppo, però, è non perdere di vista il “perché” si sta collaborando. È altrettanto importante riconoscere che ogni attività che svolgiamo deve avere un senso e un impatto reale.
Avere ben chiaro il motivo per cui stiamo costruendo un determinato prodotto ci aiuta non solo a mantenerci motivati e proattivi, ma anche a evitare inutili sprechi di tempo ed energie su attività che non generano valore.
Come avrete intuito dalle mie precedenti considerazioni, il mio obiettivo principale è limitare gli sprechi. In molte delle aziende in cui ho lavorato, ho riscontrato un forte orientamento al progetto piuttosto che al prodotto.
Vi faccio un esempio: in una grande azienda in cui ho operato, uno dei nostri obiettivi era capire quanto ci stesse effettivamente costando lo sviluppo del prodotto. Questo significava che ogni attività veniva registrata e rendicontata in base ai progetti formali, spesso temporanei e scollegati dalla visione complessiva del prodotto.
Di conseguenza, per ottenere una stima attendibile dei costi reali del prodotto, abbiamo dovuto raccogliere e reinterpretare manualmente una mole enorme di dati frammentati, ricostruendo una mappatura tra le attività dei progetti.
Abbiamo identificato il contesto del tuo sketch, adesso quello che vorremmo fare è approfondire passo passo cosa hai rappresentato.
Lo sketch rappresenta idealmente un trittico che raffigura le tre categorie fondamentali coinvolte nella realizzazione di un prodotto:
- Da un lato ci sono le persone che lavorano quotidianamente per costruirlo,
- Al centro ci sono gli utenti finali, a cui il prodotto è destinato e che dovrebbero trarne un beneficio reale,
- Infine, c’è l’azienda, che ha un interesse diretto nel successo del prodotto.
Parlo di “trittico” perché queste tre componenti sono strettamente interconnesse.
Il nostro lavoro quotidiano genera output – funzionalità, soluzioni, miglioramenti – che devono puntare a creare valore concreto per gli utilizzatori.
Se ci riusciamo, miglioriamo la loro esperienza, semplifichiamo le loro attività o risolviamo un problema reale.
Quando un prodotto riesce davvero a fare la differenza nella vita delle persone, queste ne parleranno spontaneamente: e sappiamo bene che il passaparola è la forma di promozione più potente e autentica che esista.
Questo effetto positivo si riflette anche sull’azienda: più utenti soddisfatti significa maggiore visibilità, più clienti, maggiore fidelizzazione e quindi un impatto tangibile sul business.
La forma a trittico, quindi, aiuta a dare un significato più profondo al nostro lavoro:
gli output sono ciò che produciamo, gli outcome sono il valore che generiamo per gli utenti, e infine l’impatto è il beneficio concreto che ottiene l’azienda.
Spostandoci invece sul punto di vista dell’utilizzatore, cosa ci puoi dire relativamente al feedback?
Ovviamente è un aspetto molto importante per l’intero processo. Io quando lavoro con i Product Manager e i Product Owner, dico sempre “guardate, abbiamo sicuramente delle idee geniali, però bisogna che queste idee geniali siano convalidate dalle persone che utilizzeranno il nostro prodotto”.
Iniziamo a parlare di feedback loop che a mio avviso è super importante perché vuol dire che noi abbiamo la competenza non solo di produrre, ma di farlo velocemente. Il feedback loop, per essere efficace, deve essere alimentato, per questa ragione dobbiamo adattare in modo iterativo il prodotto. Dobbiamo proseguire con i cambiamenti fino a quando non riceviamo feedback positivi.
La fase di feedback successiva dopo aver ricevuto l’approvazione è più complessa da ottenere. Il secondo feedback loop potrebbe presentarsi nel momento in cui, ad esempio, creiamo outcome per le persone, ma non un impatto per l’azienda. Immaginiamo che l’azienda voglia ottenere un impatto di tipo economico, mentre invece le funzionalità creino un impatto di tipo immagine, che non era quello che l’azienda si aspettava, in questo caso il feedback loop a cosa ci serve? Ci serve per capire che effettivamente abbiamo fatto qualcosa di valido per l’utilizzatore, ma non un impatto per l’azienda, quindi in pratica questi feedback loop ci permettono di andare avanti, di convalidare questa idea che avevamo, e anche convalidare il fatto che per l’azienda stia avendo un impatto positivo. L’idea è quella di non avanzare in modo monolitico, ma di uno sviluppo iterativo vero e proprio che permetta di incrementare prodotti che vengono costantemente migliorati grazie a questi feedback loop.
Chi invece si addentra per la prima volta in questo tipo di approccio, a quali esempi può fare riferimento?Rimaniamo nel mondo informatico, dove gli output sono task quotidiani che portiamo a termine. Quindi, immaginiamo ad esempio che dobbiamo implementare l’autenticazione su un sito web. Abbiamo una serie di login da implementare ad ogni fine di uno sprint abbiamo implementato diversi modi per autenticarsi sul sito. Questo raggiungimento consiste in un output.
Per ora non abbiamo nessun tipo di idea se questi output, che abbiamo appena descritto, stanno creando valore per gli utilizzatori. Una funzionalità, perciò, non è un outcome, potrebbe esserlo certo, ma non è detto. Molto spesso un outcome consiste in un insieme di funzionalità. Ad esempio, io come utilizzatore odio dover fare login attraverso la digitazione della password, per questo uso molto le passkey. Fondamentalemente, ti puoi loggare su un sito mettendo l’impronta digitale o il face ID. Il semplice fatto di avere la possibilità di loggarmi sul sito con mail e password, per me non è un outcome, allora possiamo parlare di feedback loop? Io attraverso le mie azioni, mando il messaggio che loggarmi sul sito non mi dà valore, me ne darebbe di più, se potessi farlo mostrando la faccia o mettendo il dito con l’impronta digitale attraverso una passkey. A quel punto allora qual è il secondo output? Implementare la passkey. Questo processo per me consiste in un outcome, non è molto realistico, però sarei disposto a pagare questa funzionalità, di potermi loggare attraverso la passkey anche 50 centesimi, ogni volta che mi loggo. Sto generando un impatto per l’azienda perché ogni volta che mi loggo lascio 50 centesimi, quindi ho un impatto per l’azienda. Supponendo che l’azienda ricerchi un impatto di tipo economico.
Quando discutiamo con gli sviluppatori, gli possiamo far vedere il risultato che hanno ottenuto, dal punto di vista dell’applicazione, ci si rende conto che il fatto di avere implementato certe funzionalità non solo rende più felici gli utilizzatori, ma crea anche un impatto positivo per l’azienda.
Ricollegandoci a tutto quello che hai appena detto, dal punto di vista pratico, uno Scrum Team può integrare questi concetti nel suo lavoro. In quali momenti quindi riusciamo a fare inspecting e adapting?
Gli output in generale si vedono nell’incremento: ogni volta che si crea un nuovo incremento durante uno sprint, rendiamo visibile l’output.
Il problema si presenta nel momento in cui vogliamo identificare l’outcome, che sicuramente non è immediatamente visibile.
Molto spesso, dimostrare che si è creato un outcome è più complicato, ma può essere visibile sotto forma di feedback.
Ad esempio: installate un’app sul telefono e mettete le stelline nello Store.
Quelle stelline sono feedback che indicano il gradimento dell’utente.
Un metodo che possiamo utilizzare per definire meglio l’outcome ottenuto consiste nell’utilizzo dell’Evidence Based Management di Scrum.org.
Questo framework ci permette di pilotare il prodotto attraverso indicatori di valore.
Output e outcome seguono due linee temporali diverse.
- Misurare gli output è immediato.
- Misurare gli outcome richiede tempo, perché dobbiamo attendere che gli utilizzatori usino quello che abbiamo creato.
Inoltre, molte aziende temporeggiano nel rilascio in produzione perché non si sentono pronte.
Invece, rilasciare rapidamente è fondamentale per alimentare il feedback loop e raccogliere dati reali.
Misurare l’impatto richiede strumenti concreti: dobbiamo dimostrare che i ricavi aumentano, e non è sempre facile se si lavora solo a livello di progetti.
Vorrei approfondire meglio la questione relativa ai lag che hai appena riportato. Come possiamo orientarci verso lo sprint goal giusto se c’è bisogno di tempo per valutare gli outcome?
Ottima domanda; da letteratura lo sprint goal deve essere outcome-oriented. A livello generale, dovremmo essere capaci di sapere se lo sprint goal è stato raggiunto, perché parliamo del lavoro che facciamo in una/due settimane e riceviamo il feedback direttamente in sprint review. Un altro conto è relativamente al product goal [ndr. descrive uno stato futuro del prodotto, è l’obiettivo a lungo termine dello Scrum team] con cui io ho molta più difficoltà. Per me il raggiungimento del product goal si osserva quando il prodotto è sul mass market, perciò per valutarlo serve più tempo rispetto allo sprint goal. c’è poi chi sostiene che ogni sprint vada analizzato in funzione del product goal…ma questo è un altro discorso.
Output, outcome, e impatto sono delle tematiche che si possono spiegare alle persone, ma come ne trasmetti la cultura? Come riesci a farne capire l’importanza affinché diventino parte del lavoro di ognuno all’interno dell’azienda?
Riporto semplicemente tutto in obiettivi. Quello che provo a fare è far entrare nella mentalità che dobbiamo risolvere un problema. In generale cerco di riportare il focus su qual è il problema che stiamo cercando di risolvere o qual è l’opportunità che stiamo cercando di accogliere. Quello che cerco sempre di trasmettere è che non bisogna partire subito a testa bassa, mettendosi a sviluppare o a fare cose a caso. Prima di tutto, è importante fermarsi un attimo e capire davvero qual è il problema e come possiamo risolverlo nel modo più efficace. Quindi in realtà il percorso che applico è un processo iterativo fatto di feedback. Come primo focus abbiamo il problema, secondo gli indicatori e i dati di valore, tenendo sempre presente che questi dati ci dicono che stiamo risolvendo il problema e possiamo utilizzarli per le retrospettive, quindi sfruttare quei meccanismi che ci offre Scrum per il miglioramento continuo.
In che modo definisci il valore con i clienti? E come rispondi nel momento in cui viene ad esempio sottovalutato il feedback loop?
In genere, le aziende mi contattano quando si stanno avvicinando per la prima volta al mondo dell’agilità. In questi contesti, gli unici indicatori disponibili sono spesso quelli classici legati all’output di progetto: costi, tempi previsti, rispetto del budget. La mia prima domanda, però, è molto semplice: “Gli utilizzatori del prodotto sono soddisfatti?” E nella maggior parte dei casi la risposta è un incerto “boh”. A quel punto, si organizza una riunione con qualche dipartimento per cercare di capirlo. Naturalmente, sto un po’ esagerando per rendere l’idea, ma questo tipo di dinamica è piuttosto frequente, soprattutto nelle realtà aziendali di grandi dimensioni.
In altri casi, invece, ricevo risposte più concrete: magari si tratta di prodotti digitali più semplici, come siti web, per i quali è possibile raccogliere feedback quasi in tempo reale. In situazioni come queste, la conversazione diventa più interessante e costruttiva. A quel punto, pongo una nuova domanda: “Quali indicatori potremmo utilizzare per misurare il valore generato?” Ma ci tengo sempre a chiarire che non spetta a me scegliere questi indicatori: non conoscendo a fondo il prodotto, non sono la persona più adatta per farlo. Il mio ruolo è facilitare la discussione e aiutare il team a definire metriche che abbiano davvero senso per il contesto specifico.
Affinché questi indicatori diventino realmente utili nel tempo, è fondamentale organizzarli in modo che possano essere raccolti e monitorati in modo automatizzato, riducendo il carico operativo. E ovviamente, in tutto questo, un approccio basato sull’Evidence-Based Management gioca un ruolo centrale: partiamo da lì, spieghiamo i concetti chiave, attiviamo i feedback loop… e da lì comincia un percorso strutturato e continuo di miglioramento.
Dal punto di vista di ownership invece, chi definisce le scadenze e chi concretizza gli impatti a livello strategico? Chi definisce e monitora gli output, outcome e impatto?
L’output è qualcosa che si definisce all’interno del team di prodotto o dello Scrum Team. È il risultato di un lavoro collaborativo: ci si allinea su uno Sprint Goal e si selezionano, dal Product Backlog, le attività da portare avanti. È, a tutti gli effetti, un impegno condiviso del team.
L’outcome, invece, è responsabilità del Product Owner o del Product Manager. È il risultato che ci si propone di ottenere grazie agli output, ed è legato al raggiungimento del Product Goal. Chi guida il prodotto deve orientarsi attraverso indicatori di valore, che permettano di capire se si sta andando nella direzione giusta. Quando faccio coaching ai Product Owner, uno degli aspetti su cui insisto di più è proprio questo: devono comprendere a fondo questa distinzione e avere una dashboard con metriche chiare per monitorare l’andamento del prodotto.
Infine, c’è l’impatto, che si concretizza attraverso dati misurabili, spesso espressi in cifre. È su questo livello che il Product Owner si confronta con il management e gli stakeholder aziendali. L’impatto è strettamente connesso agli obiettivi di business e viene analizzato attraverso strumenti come il Business Model Canvas, con il supporto di figure come i Product Sales o i Marketing Product Owner, a seconda della struttura aziendale.
L’impatto è più a livello di persone che definiscono la strategia aziendale. Che poi la riverberano sui team che la perseguono attraverso i prodotti giusto?
Esatto, spesso siamo abituati a vedere la strategia definita “dall’alto”, magari con un grande discorso del top management valido per un intero anno. Tuttavia, sentiamo sempre più l’esigenza di avere momenti di allineamento più frequenti, in cui sia possibile confrontarsi sugli indicatori e verificarli con maggiore regolarità. Questo permetterebbe di mantenere viva la connessione tra strategia e operatività, e di adattare tempestivamente il lavoro dei team rispetto agli obiettivi aziendali.
Terminiamo con la nostra domanda di rito. “Se avessi una bacchetta magica, cosa cambieresti riguardo all’approccio e alla cultura su output, outcome e impatto? “
Mi piacerebbe cambiare la mentalità delle persone verso un approccio al lavoro che si focalizzi di più sui problemi da risolvere piuttosto che su una lista di richieste da implementare.
Takeaway
- Misurare gli outcome è più complicato a causa del tempo necessario per raccogliere feedback e valutarli: per questo è importante rilasciare in produzione il più possibile, anche piccoli cambiamenti.
- Integrare le metriche di outcome con quelle di output già in uso può facilitare il cambiamento di approccio.
- L’utilizzatore è al centro: creare tante feature senza valore è inutile e dannoso.
- Il feedback loop è necessario per garantire che output, outcome e impatto siano allineati agli obiettivi aziendali.
- Sottovalutare le iterazioni aumenta il rischio di sprecare risorse su prodotti poco apprezzati dagli utenti e non generare né outcome né impatto.
Bio: Fabio Panzavolta è un Professional Scrum Trainer certificato da Scrum.org (organizzazione del co-creatore di Scrum) e fondatore di Collective Genius società che si occupa di formazione e consulenza Agile con focus sul prodotto. Dopo numerose esperienze come ingegnere software e project manager si avvicina al mondo Agile e inizia a supportare le aziende durante il loro percorso di trasformazione. Ad oggi ha formato più di 400 persone e ha lavorato con numerose realtà di business in diversi settori con l’obiettivo, tra gli altri, di diffondere una cultura di prodotto che permetta di sviluppare servizi e prodotti complessi attraverso un framework semplice.
