Product Owner: cosa fa, il ruolo e le responsabilità

• Cosa fai nella vita?
• Sono un Product Manager, tu?
• Ahh, quasi lo stesso. Io sono un Product Owner e lavoro con gli sviluppatori!
• Ma anche io lavoro con gli sviluppatori 😅

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:

1. Product Owner: cosa fa e chi è
   1. Product Owner e il suo background
   2. Product Owner e il Product Backlog
   3. Product Owner e le cerimonie Scrum
2. Product Owner: le responsabilità
3. Un esempio di PO in una Startup 
4. Product Owner e Product Manager
5. Un esempio di PO in una grossa corporate italiana
6. Quali sono le responsabilità del Product Owner in questa “combinazione”?
7. Il Product Owner e lo Scrum Team
   1. Il titolo che crea confusione
   2. La gerarchia
8. Il Product Owner e il Project Manager
9. Conclusioni

Product Owner: cosa fa e chi è

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.

Product Owner e il suo background

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.

Product Owner e il Product Backlog

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:

• Creare e ordinare gli item del Backlog;
• Comunicare gli Item sui quali si dovrà lavorare;
• Fare in modo che il PB sia trasparente, visible e chiaro.

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à. 

Product Owner e le cerimonie Scrum

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.

Le cerimonie Scrum

• Sprint Planning (qui trovi la guida completa): è la cerimonia d’inizio Sprint in cui viene definito lo Sprint Goal. Qui vengono selezionati i task del Product Backlog che si ritengono di maggior valore e che verranno pianificati nelle future settimane. Di solito, uno Sprint dura 1 mese o 2 settimane e fa da container a tutti gli eventi Scrum;
• Daily Scrum: breve e giornaliera cerimonia della durata di 15 minuti dove il team (la presenza del PO è opzionale) si focalizza su tre domande: Cosa ho fatto ieri? Cosa farò oggi? Ci sono degli impedimenti nello svolgere il mio lavoro? Questo serve ad “ispezionare i progressi fatti” e ad “adattare il piano”, facendo luce e trasparenza su ogni impedimento riscontrato;
• Product Backlog Refinement o Backlog Grooming: cerimonia facoltativa fatta solitamente a metà dello Sprint per “rifinire e perfezionare” il Product Backlog, in modo da renderlo più chiaro possibile, e per far sì che contenga tutti i dettagli sugli item che dovranno essere lavorati (come descrizione, ordine e dimensione);
• Sprint Review: cerimonia di chiusura dello Sprint della durata di 4 ore in cui viene mostrato agli stakeholder il lavoro fatto dal team. Si raccolgono i feedback e si decide cosa può essere rilasciato in produzione. Se volete rendere la Sprint Review interessante, non potete non scoprire i 10 segreti che potete applicare fin da subito;
• Sprint Retrospective: cerimonia post Sprint della durata di 3 ore in cui lo Scrum Team capisce cosa ha fatto bene, cosa ha fatto male e su cosa può migliorare. Si tratta di una importantissima cerimonia per la crescita del team perché va a supporto del costante miglioramento della produttività del team, della qualità del prodotto e della “salute” del team stesso.

Product Owner: le responsabilità

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:

• Comunicare Product Vision e Product Goal per assicurarsi che tutti abbiamo chiari gli obiettivi e siano allineati sul lavoro che si sta facendo;
• Prioritizzare e ordinare il Backlog, in modo che il lavoro svolto dallo Scrum Team possa generare più valore possibile per gli utenti e per il business;
• Perfezionare e dettagliare i Product Backlog Item in modo che gli sviluppatori sappiano non solo cosa fare, ma perché il loro lavoro è importante;
• Misurare i progressi ad ogni rilascio di prodotto e decidere quando rilasciare.

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.

Un esempio di PO in una Startup 

Nella mia attuale azienda le due figure coincidono.

• Il PO è il PM che parla sia con gli utenti che con gli sviluppatori, è responsabile sia del Product Backlog che della Product Roadmap e della definizione delle priorità. 
• Il Product Owner cerca di mettere assieme sia le esigenze di business dell’azienda che quelle degli utenti. Nel mio specifico caso Job seeker e lavoratori per il B2C, HR e aziende clienti per il B2B. 

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. 

Product Owner e Product Manager

Adesso tocca a me, Geanina!

• Io sono un Product Owner, lavoro con gli sviluppatori, ma lavoro anche con un Product Manager 🙂

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.

Un esempio di PO in una grossa corporate italiana

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:

• Il Product Manager si concentra sulle esigenze dell’utente e garantisce che il prodotto risolva il problema giusto e fornisca la soluzione giusta per il mercato giusto, al fine di massimizzare opportunità e profitti;
• Il Product Owner aiuta a realizzare il prodotto da zero, guidando e coordinando il lavoro del Team di sviluppo, al fine di massimizzare il valore del prodotto garantendo la realizzazione di un increment tangibile ad ogni iterazione (Sprint).

Quali sono le responsabilità del Product Owner in questa “combinazione”?

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.

Il Product Owner e lo Scrum Team

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.

Il titolo che crea confusione

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!

La gerarchia

Abbiamo menzionato:

• Utenti
• Product Manager
• Scrum Master
• Dev
• UI/UX
• Analisti funzionali
• QA

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.

Il Product Owner e il Project Manager

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:

• Anche il Project Manager gestisce un backlog come il PO? 

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.

• Quindi se la To-do list del Project Manager fosse ordinata, sarebbe come il backlog del PO?

Ahimé no, perchè questa non viene cristallizzata ad inizio sprint come avviene per il backlog, ma può cambiare frequentemente anche in corso d’opera.

• La differenza sta tutta nel fatto che il backlog non sia né ordinato né cristallizzato?

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).

• Come viene organizzato quindi il lavoro del Team quando c’è un Project Manager?

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.

• Il PO parla esclusivamente con il PM e il Team, ma con chi parla il Project Manager?

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.

Conclusioni

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!