Gennaio 9, 2023 - di Angelo Barone and Geanina Andriesanu
Quante volte ci siamo chiesti quale sia la differenza tra questi due ruoli, quello del Product Owner e del Product Manager?
Considerando, soprattutto, che in Italia si fa ancora parecchia confusione, e raramente si sa cosa siano entrambi esattamente. Spesso infatti li si confonde con la figura del Project Manager. Vi dirò: anche leggere gli annunci di lavoro non aiuta a fare chiarezza.
La verità è che capire i confini esatti e le responsabilità di un Product Owner non è una cosa assolutamente scontata.
Il PO, in alcune aziende, ha forti sovrapposizioni con il Product Manager, a prescindere da come viene chiamato. In altre ancora, il PO ha un ruolo ben distinto, con responsabilità e seniority diversa. Avevamo già parlato della differenza tra Product Owner e Product Manager chiedendo aiuto alla nostra community di Product Heroes e sentendo pareri di diversi PM.
Ma è arrivato il momento di fare un po’ di chiarezza. SPOILER: ”Forse”.
Riusciremo a farla attraverso questo articolo? SPOILER: “Impossibile 😂”.
Scherzi a parte, quello che però vogliamo fare oggi è cercare di portare la nostra esperienza da Product Owner, maturata all’interno di due aziende italiane molto diverse, e fornirvi ulteriori elementi di valutazione per meglio comprendere le responsabilità del PO e la sua relazione con il PM.
Prima lo farò io, Angelo Barone, Product Manager in Jobtech, e poi Geanina Andriesanu, Product Lead in Telepass (ed ex Product Owner); vedremo insieme il ruolo del PO e la sua definizione, sia all’interno di una startup che in una grande corporate italiana. Ma non solo!
Cosa troverete in questo articolo:
Partiamo innanzitutto col dire che la figura del Product Owner nasce all’interno della metodologia Agile e nel framework Scrum. Il Product Owner infatti, è un ruolo che vive all’interno dello Scrum Team (composto da un PO, Scrum Master e Developer), team senza il quale il PO non può esistere e dove
Il Product Owner ha la responsabilità di massimizzare il valore del prodotto e del lavoro svolto dal Team di Sviluppo.
Scrum Guide 2020
“The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team” – Scrum Guide 2020.
All’interno dello Scrum Team non ci sono sottogruppi o gerarchie e tutti sono concentrati su un unico obiettivo alla volta, il Product Goal. Il team è quindi cross-functional, ovvero i membri del team hanno tutte le competenze necessarie per creare valore a ogni Sprint.
Abbiamo detto che è una figura che nasce all’interno della metodologia Agile, motivo per cui c’è chi sostiene che “il PO non è altro che un Product Manager all’interno dello Scrum Team”. Ma è davvero così? Continuate nella lettura dell’articolo perché sul tema torneremo più avanti.
Se abbiamo capito quale ruolo riveste all’interno del Team, sappiamo chi è un Product Owner? Qual è la sua storia e la sua formazione? Anche in questo caso non esiste una risposta sola. Esistono PO che vengono dal mondo dello sviluppo software, PO con un forte background nel Design, nel Marketing e così via…
Tutti però hanno una buona conoscenza dell’Agile, anche con background e preparazioni diverse, che in alcuni casi risultano essere vincenti.
Immaginiamo un prodotto utilizzato internamente da un’azienda di sviluppo software per il miglioramento “della pulizia del codice”. Un PO con un passato da programmatore si sentirà sicuramente più a suo agio di uno che viene dal mondo del Marketing, che al contrario si potrà sentire molto più a suo agio in prodotti che fanno della crescita la loro North Star Metric.
Questo non significa però che un PO “forte in un determinato dominio” sia preferibile in assoluto, perché non essere dei massimi esperti a volte aiuta ad avere una prospettiva più ampia e a non cadere in bias.
All’inizio del mio percorso lavorativo, ho iniziato a lavorare in Scrum con Designer e Developer al mio fianco. Condivido con voi un contenuto che mi ha aiutato a districarmi in questa prima fase e che in pochi minuti racchiude l’essenza della figura del PO.
Più avanti vedremo nel dettaglio le responsabilità del PO, ma iniziamo con il dire che il Product Owner è anche responsabile della gestione del Product Backlog, che include il saper:
Se vi serve un ripassino, avevamo già parlato del Product Backlog, significato, esempio e template, per mostrarvi come può essere per voi una risorsa fondamentale nella gestione dei prodotti.
Il Product Owner può infatti esprimere la volontà di diversi stakeholder nel Product Backlog.
Ecco, avete presente la Moleskine che nell’iconografica gli artisti portano sempre con sè? Bene, per il PO il Backlog è questo e molto di più.
Rappresenta la tela bianca sulla quale “crea la sua arte”, ma è anche un “giardino da curare”, perché il backlog è vivo: oltre ad aggiungere nuovi sviluppi al suo interno, dobbiamo essere pronti a “estirpare le erbacce” se ci accorgiamo che ci sono attività che non generano più valore per gli utenti.
Sul Product Backlog infatti, vengono rappresentati i bisogni di tutti gli stakeholders, e se questi bisogni cambiano, di conseguenza e in accordo con il PO, anche il backlog varierà.
Il calendario di un PO è costellato da quelle che in Scrum si chiamano cerimonie. Vediamole insieme rapidamente. Prima, però, se vi serve date una letta alle due metodologie al servizio delle aziende, Agile e Lean, in cui abbiamo parlato di prodotto, di come risolvere i problemi giusti e di come farlo in contesti che mutano velocemente e che richiedono un’elevata adattabilità e cambi continui di rotta.
Quindi un PO fa “solo” questo? La risposta è NO, e molto dipende dal contesto nel quale lavora e dall’organizzazione. In base al tipo di azienda infatti, i compiti di un Product Owner possono variare di molto.
Provando a generalizzare, possiamo dire che le attività alle quali è chiamato a rispondere sono:
Quello che spesso si vede in aziende più giovani e meno strutturate, e in piccole Startup, è la coincidenza tra la figura del PO con quella del PM e viceversa. Su prodotti invece molto complessi, può capitare che ci sia un Product Manager e diversi Product Owner, ognuno focalizzato su un’area funzionale specifica del prodotto.
Nella mia attuale azienda le due figure coincidono.
Il Team di Prodotto è composto da: Designer sia UX che UI, Sviluppatori Front End e Back End, Data Analyst e Content owner (sia copy che visual).
Il Product Owner, nel nostro setup, si occupa anche della parte riguardante la strategia e il problem space. Sì, perché oltre a sviluppare e deliverare nel migliore dei modi, deve anche capire quali sono le “cose giuste” da portare in produzione. Deve sapere quali soluzioni sono veramente valide e generano un valore vero per gli utenti. Prima di pensare al “cosa”, deve avere ben chiaro il “perché” e attraversare tutte le fasi preliminari di discovery e di validazione delle ipotesi.
Adesso tocca a me, Geanina!
L’abbiamo già detto: quando pensi alla realizzazione di prodotti digitali e alla figura che si prende cura di loro all’interno dell’organizzazione, hai già notato che tra il ruolo del Product Manager e quello del Product Owner non c’è una “delimitazione” chiara.
Partiamo subito dal presupposto che, anche se nel mondo dello sviluppo IT in Scrum, far lavorare insieme Product Owner e Product Manager potrebbe risultare inefficace, ci sono aziende e contesti in cui questo succede per vari motivi: complessità dei prodotti, difficoltà ad innovare, cultura del prodotto carente, bisogno di creare processi, etc.
È questo il motivo per cui, navigando su Linkedin o sbirciando tra i vari annunci di lavoro, potrai notare che certe aziende hanno (oppure cercano) sia PM che PO. Quello di cui ti parlo di seguito è un esempio pratico di come si è scelto di definire il rapporto tra il Product Owner e il Product Manager in una grossa corporate italiana. Ti racconterò dove finiscono le responsabilità di uno e dove iniziano quelle dell’altro.
Ovviamente questa linea di demarcazione può cambiare da corporate a corporate, oppure da un’azienda corporate che opera nel B2C rispetto ad una che opera nel B2B. Quello che vedremo infatti, non è una ricetta universale, ma solo un esempio.
Nella fase di Product Discovery iniziale, quando vengono concepite nuove idee che porteranno a dei prototipi, l’unico in grado di ricoprire questo ruolo è il Product Manager. Il PM passa la gran parte del suo tempo nel Problem Space. Conosce benissimo gli obiettivi, la vision, la mission e la strategia aziendale.
Attraverso un’incessante lettura dei dati, il PM guida il processo di ricerca delle esigenze dell’utente, raccoglie informazioni sulle condizioni del mercato, identifica un problema e una proposta di valore aggiunto, scopre potenziali nuovi utenti, eccetera.
Dopodiché, insieme ad un team cross-funzionale, deve proporre una soluzione innovativa, testare le ipotesi attraverso un MVP, passare quindi dal problema alla soluzione. A volte il PM decide addirittura come promuovere il prodotto sul mercato.
Fare tutto questo in una azienda di grandi dimensioni, soprattutto durante la fase di Solution, è una bella sfida per un PM. Ed è proprio in questo contesto che entra in gioco il Product Owner. Quindi, anche se la grande azienda corporate lavora in Scrum, il Product Owner e il Product Manager non sono la stessa persona, come può succedere nella start-up/scale-up, ma il PO è una figura separata, molto più vicina al team di sviluppo e con un ruolo più di Delivery che strategico.
Affinché questo equilibrio funzioni e non diventi un dualismo, il PO deve essere sempre in sintonia con il PM. Quindi, anche in fase di ricerca e colloquio, se ti stai candidando per un ruolo di PO in una grande azienda, prova a capire bene chi sarà il PM con cui ti interfaccerai, come lavora, come pensa e che skills ha. Se hai modo, prova a conoscerlo in un incontro, solo così ti renderai davvero conto se vorrai lavorare con lui/lei.
Facciamo un breve riassunto della situazione che ti ho appena descritto, dove l’azienda è di grande proporzioni:
Ovviamente la Star, lo special one su cui vertono tutte le attenzioni, è sempre il Prodotto. Tutti si adoperano per realizzarlo e per migliorarlo attraverso un flusso continuo di feedback, dagli stakeholders al PM, dal PO al Team di sviluppo, grazie ad una comunicazione continua tra tutte le parti.
Tuttavia, questi attori non comunicano in maniera diretta. Il Product Owner agisce come unico rappresentante di tutti gli stakeholder, interni ed esterni, nei confronti del Team di sviluppo.
Questi feedback alimentano il Product Backlog. Un’altra importante responsabilità del PO, infatti, è quella di prendersene cura aggiornandolo continuamente. In questa attività, il Product Owner è consapevole delle priorità, ma non essendo necessariamente tecnico, non può avere la sensibilità necessaria a stimare l’effort ed eventuali dipendenze tecniche, motivo per cui si avvale dell’aiuto del Team.
Una volta che la visione è stata comunicata al Team e sono state identificate le funzionalità chiave, si cristallizza il Product Backlog, che diventa quindi una declinazione più dettagliata della visione discussa tra PM e PO.
Se abbiamo parlato finora dell’importanza del rapporto tra PM e PO, questa non è l’unica chiave vincente affinché tutto funzioni. È importante infatti sottolineare un altro aspetto fondamentale: deve esserci un rapporto simbiotico anche tra PO e Team. L’uno non può esistere senza l’altro e solo attraverso questa simbiosi entrambe le parti coinvolte possono prosperare. L’ambiente è un fattore chiave per l’esistenza di questa simbiosi.
Ti chiedi cosa dovrebbe fornire l’ambiente per incoraggiare questa relazione?
Personalmente, credo che un ambiente sano debba nutrire prima di tutto fiducia, creatività e innovazione. L’ambiente in cui le persone sono autorizzate e incoraggiate a proporre idee e soluzioni è l’ambiente in cui accadranno le vere magie 🙂.
Il Product Owner ha la responsabilità di creare e coltivare questo ambiente, in quanto il suo prodotto sarà direttamente influenzato dal grado di motivazione del Team. Pensavate che il PO dovesse avere solo un rapporto speciale con il PM e vi siete dovuti ricredere dopo aver capito l’importanza del rapporto anche con il Team? Non è finita qui!
Un altro asse strategico è quello tra il PO e lo Scrum Master. Entrambi hanno infatti un focus sulla timeline degli sviluppi, si preoccupano di rimuovere eventuali ostacoli, collaborano per facilitare il lavoro del Team di sviluppo.
Per poter creare questo magico equilibrio e alimentare un ambiente di lavoro stimolante, il Product Owner deve stare con il Team, collocato o distribuito, per evitare ritardi, errori di comunicazione e altre forme di spreco. Deve assicurarsi che ci sia sempre linearità tra ciò che è stato definito nella roadmap e ciò che viene effettivamente sviluppato, partendo dai macro-obiettivi di quarter o di sprint.
Se le due cose iniziassero a divergere (può capitare a causa di stime sbagliate, dipendenze esterne, debito tecnico da sanare, eccetera), il PO è tenuto a comunicarlo al PM affinché possano identificare insieme la miglior strategia per raddrizzare la rotta.
Google translate: Product Owner (Eng) → Proprietario del prodotto (Ita)
Nonostante il nome possa essere fuorviante, il Product Owner non è esattamente l’owner del prodotto, quindi non ha il “potere” di prendere tutte le decisioni relative al prodotto per conto dell’organizzazione. Questo è infatti compito del Product Manager.
Ma quindi se il Product Owner non è l’owner del prodotto, il Product Manager è il manager del Product Owner?
No, neanche in questo caso la dicitura ci aiuta a capire chi fa cosa. Il Product Manager è manager e owner del prodotto, ma non del Product Owner. Infatti nell’organigramma il PO è all’interno del contesto IT, il PM è cross tra IT e business.
Ok, il Product Owner non è l’owner del prodotto, e il Product Manager non è il manager del Product Owner. Possiamo almeno dire che il Product Owner è owner del Team di sviluppo?
Assolutamente no, neanche questo. Anzi, è totalmente sbagliato! I dev sono infatti guidati dai Tech Lead, gli UI/UX dall’Head of Design, gli analisti funzionali dall’Head of Functional Analysis, i QA dall’Head of Quality Assurance.
Tutto chiaro? Tutto confusionario? Mettiamo un po’ di ordine!
Abbiamo menzionato:
Tantissime figure, nessuna delle quali risponde al Product Owner, il quale – a sua volta – non riporta a nessuna di esse.
Come è possibile? Non esiste nessuna gerarchia, eppure c’è tantissima coesione? Come fanno tutte queste figure a coordinarsi, a lavorare bene, a rispettare la roadmap, a produrre ciò che gli utenti finali si aspettano?
È esattamente questo il ruolo del Product Owner, risponde a tutte queste ultime domande. È un leader senza titolo. Prende tutti questi punti, apparentemente scollegati tra loro, e li unisce come una linea che li attraversa tutti e garantisce una connessione persistente.
Il Product Owner non è né un autore di user story né un ingegnere dei requisiti, ma un comunicatore, un narratore e un facilitatore tra tutte le parti interessate.
Arrivati a questo punto è finalmente chiaro il ruolo di un Product Owner, quali siano i suoi compiti e un esempio della sua giornata tipo, sicuramente diversa da quella di un Product Manager. Tuttavia, riflettendoci, non sembra poi così diversa da quella di un Project Manager, vero? Risolviamo allora anche questo ultimo grande dilemma, rispondendo a questa domanda da veri problem solver, quindi spezzettandola in tante sotto-domande:
Può sembrare che sia così, ma non si tratta di un vero e proprio backlog ordinato per priorità. Si tratta piuttosto di una To-do list, non per forza ordinata, ma su cui sono segnate le priorità e le date di go-live.
Ahimé no, perchè questa non viene cristallizzata ad inizio sprint come avviene per il backlog, ma può cambiare frequentemente anche in corso d’opera.
Facendo un passo indietro ci viene più semplice notare come tutti questi aspetti siano tipici dello Scrum, che è una prerogativa per il PO, ma non lo è assolutamente per il Project Manager, il quale può benissimo utilizzare anche altri approcci o metodologie (es. Kanban o Waterfall).
Si seguono le linee guida della metodologia utilizzata, quindi si parla di date di go-live, si utilizzano timeline e Gantt, si stima in giorni/uomo e non in story points.
Di solito parla con gli stakeholder e, in seguito a brainstorming, inserisce nuove attività e le prioritizza, senza necessariamente passare da una fase di Product Discovery o una fase di condivisione con il Team per capire le implicazioni tecniche. La priorità è infatti solitamente dettata più dall’impatto che dall’effort necessario. Alla base di tutto c’è la vera differenza tra un Progetto ed un Prodotto.
Il progetto nasce da un’idea degli stakeholder, si pianifica, si realizza e, una volta terminato, si consegna.
Per questo motivo il progetto ha delle tempistiche e un budget prestabiliti, che non possono essere superati (o come si dice in gergo, “bucati”). Di conseguenza, si monitorano quotidianamente i progressi e si confrontano con le deadline dei Gantt per assicurarsi di avere un impatto immediato sui KPI aziendali.
Il prodotto nasce da un’esigenza degli utenti, si pianifica, si realizza in MVP e si evolve continuativamente.
Per questo motivo il prodotto punta a risolvere un problema (che sia un’esigenza, un desiderio o un’assenza di valore) e propone delle soluzioni con delle ipotesi che devono essere validate. Quindi, si lavora inizialmente su un MVP e si monitorano le relative metriche, per poi proseguire con tutte le altre evoluzioni, creando un percorso di crescita costante, con degli impatti visibili su un periodo più lungo, sia per l’utente, che per il business.
Anche se Product Owner e Product Manager lavorano a livelli diversi a seconda del contesto e dell’azienda nella quale si trovano, idealmente dovrebbero collaborare sin dalla prima fase di discovery, per poi pianificare, prioritizzare e arrivare al deploy insieme.
Il PO dovrebbe non essere solo un order taker o un esecutore del lavoro che gli viene assegnato dal PM. Entrambi dovrebbero contribuire al miglioramento del prodotto interagendo direttamente con i customer, creando la vision, gestendo la roadmap e decidendone insieme le priorità. Questo contribuirebbe a creare un relazione più genuina tra PO e PM e probabilmente una complessiva miglior definizione del prodotto.
Se hai deciso di entrare nel mondo dei prodotti digitali, capirai quanto questo sia complesso ma estremamente gratificante. Ci auguriamo che questo articolo vi abbia aiutato a capire meglio certi aspetti, e a scegliere il ruolo giusto che fa per voi, partendo direttamente dal vostro next-step.
La sfida è sapersi evolvere e distinguersi. Ci sono molti modi per crescere, ma vorrei condividere con voi il mio preferito: il networking. È sorprendente quanto puoi imparare dallo scambio con persone che sono qualche passo avanti a te. Più ti confronti, più prospettive e possibilità ti darai.
Sei un Product Owner e vuoi diventare un Product Manager? Sappi che tante altre persone hanno fatto questa scelta, e non ti deve spaventare. Nel Product Management è importante affinare continuamente le proprie conoscenze e competenze. Più esperienze farai, e più sarai preparato ad affrontare le inevitabili sfide che il mondo del Prodotto ti regalerà.
E tu, che ne pensi? Facci sapere la tua opinione nei commenti. Se hai dubbi, chiedi pure agli autori dell’articolo. Saranno lieti di risponderti!
…e se volessi approfondire il Product Management all’interno di un percorso formativo di gestione del prodotto a 360°, dai un occhio al nostro Master in Product Management 🎓 in partenza!
Il mio sogno è quello di contribuire a reinventare realtà aziendali attraverso le logiche sistemiche legate al design, offrendo prodotti e servizi capaci di soddisfare i bisogni delle persone. Il mio habitat naturale è il prodotto. Ho avuto modo di lavorare sia in corporate che startup, su prodotti B2C e B2B. Ho iniziato a lavorare nel mondo del prodotto nell'headquarter di Haier Europe, nel reparto Brand e IoT, dove mi sono occupato dello sviluppo e gestione dell'app hOn (product line washing), con la quale abbiamo vinto il premio internazionale RedDot 2020. Mi sposto poi in Movenda, software house del gruppo TIM dove ho lavorato sia a prodotti utilizzati all'interno del gruppo che a prodotti per aziende esterne. Attualmente lavoro in Jobtech, azienda HRtech che ha l'obbiettivo di rivoluzionare il settore attraverso la tecnologia.Dopo la laurea specialistica in Design dei Sistemi - Prodotti e Servizi, amplio la mia formazione con il master in Innovation Design Management presso la 24ORE Business School e il Master in Product Management di Product Heroes in modo da implementare le mie conoscenze e competenze in ambito strategico e gestionale.
Dopo 6 anni in finance e 6 in marketing tra Bucarest, Parigi, Verona e Milano, entra a far parte di Wise Emotions, che da lì a breve sarebbe diventata Telepass Digital, come Product Owner a gennaio 2021. Lo stesso anno segue il primo Master in Digital Product Management by Product Heroes. Oggi Geanina ricopre il ruolo di Digital Product Manager per l’app Telepass. Nel tempo libero legge, viaggia, pratica yoga e investe nella sua crescita personale grazie a mentoring e networking.
Le slide sono disponibili per studenti ed ex studenti del Master in Product Management