Sentiamo molto spesso parlare di Product Owner, ora più frequentemente di quanto si parli Product Manager, Job Title più in voga prima dell’arrivo di Agile e di Scrum. E non si parla della stessa cosa.

Ufficialmente il concetto di Product Owner è stato lanciato da Scrum, ma è stato poi scopiazzato più i meno bene in un sacco di mondi diversi, perché i principi che stanno dietro al suo ruolo by-the-book sono applicabili in molti contesti legati al management in generale.

Accountability

Il principio probabilmente più importante che sta dietro al ruolo del PO è quello dell’accountability. In un mondo pieno di qualcosa-manager, gente che gestisce una facciata del prodotto, finalmente c’è un “owner”, un tizio o una tizia che possiede e domina il prodotto in ogni suo angolo ed è Accountable per quel prodotto (avete presente la matrice RACI?).

È colui o colei che è il primo responsabile del prodotto, nel bene e nel male, e che prende le decisioni strategiche sul futuro del prodotto. È quello o quella che va a casa se il prodotto va male o riceve dei premi se il prodotto va alla grande.

Va da sé che per esercitare appieno questa responsabilità, o si è direttamente l’imprenditore (tipo nelle aziende mono-prodotto o startup) oppure si ha una fortissima delega dalla direzione.

In cosa si manifesta l’accountability?

Parlavo di decisioni strategiche. È un concetto generico, ma chi lavora tutti i giorni su un prodotto sa di cosa parlo: decisioni scomode, gente che non si trova d’accordo, scelte impopolari. Se vogliamo tornare con i piedi per terra, per esempio, il PO ordina il backlog (la lista delle cose da fare), non solo al livello dei progetti, ma anche delle singole funzionalità che compongono un progetto relativo al suo prodotto. Decide cosa si fa prima, di cosa è composta la prima release. Decide anche se è il caso di dedicare un mese alla manutenzione, ma su questo si deve fidare molto del suo team: è comunque lui a deciderlo. Ovviamente non decide sulle architetture, su “come” si sviluppano i prodotti, ma sicuramente ha potere assoluto su “cosa” si rilascia al cliente.

È il Signor NO

Dal l’assunto che saranno più le idee buone di quelle che si riescono a fare, il Product Owner ha anche il compito di dire di No alle idee che portano poco valore al proprio prodotto, confrontate con altre che lui ha intenzione di sviluppare e rilasciare. Dire NO è probabilmente la cosa più difficile che un manager in generale debba fare. Molto spesso si traccheggia, si prende tempo, “risentiamoci tra 2 settimane”, “l’ho messa nel backlog, ti faccio sapere”.

Il rapporto con i vari stakeholder che hanno interesse sul tuo prodotto è difficile e porta continuamente a prendere scelte su cosa sviluppare prima, dopo e cosa mai. Se una Product Unit sviluppa ha capacità per 2 progetti all’anno, avere un backlog di 30 progetti è pura follia o fantascienza (decidete voi). Il PO deve farsi coraggio, dire NO ai progetti oltre il quarto e semplicemente invitare gli stakeholder a trovare soluzioni differenti, magari aiutandoli nel brainstorming. Non dire NO e far vivere qualcuno nella speranza che “me lo ha messo nel backlog, ha detto che tra un po’ lo fa” è una presa in giro.

È trasparente

Perché gli stakeholder si comincino a fidare del PO, delle sue scelte, delle sue priorità, è necessario, oltre che a dimostrare estrema competenza in ogni ambito relativo al prodotto, che lui o lei sia trasparente sulle scelte che fa, che sappia giustificare in ogni momento l’ordinamento del backlog, parlando di valore consegnato al cliente e non semplicemente dicendo “me l’ha chiesto il capo”.

È orientato al valore

Si dice che il PO è il responsabile del ROI (Return On Investment) del prodotto: la sua accountability lo rende responsabile sia delle scelte, ma anche degli effetti che queste hanno sul fatturato. Ed è sempre il valore che arriva al cliente (che si trasforma in valore per l’azienda) a guidarlo e non idee o supposizioni. È costantemente in contatto con i clienti, siano essi pochi o molti, conosce esattamente come loro usano il prodotto e realizza quelle funzionalità che vanno, in quel momento, a produrre più valore per il suo prodotto e per i clienti che lo usano. Da questo punto di vista deve avere un’ottima capacità di ascolto sul cliente finale: il suo backlog è sempre composto da cosa chiede il cliente e da cosa invece richiede il mercato e la sua vision.

Ha una vision

Visto che ha un forte endorsement e delega da parte della direzione, deve avere una visione chiara di dove deve andare il prodotto, sia esso destinato alla vendita o all’uso interno. Un backlog realistico arriva a 6 mesi, un anno al massimo: quello che succede dopo è variabile ma comunque illuminato dalla vision che indirizza non solo gli sviluppi, ma anche il modo in cui ci si relazione con i clienti, con il mercato, con i competitor.

È un motivatore

Quando si ha la vision, diventa facile motivare chi ti sta intorno. Il Product Owner è un motivatore, è una persona che da un lato riesce a convincere gli stakeholder che quello che sta sviluppando è la cosa migliore che potrebbe mai fare in quel momento è dall’altro motiva il team per sviluppare un prodotto che farà il botto sul mercato (in senso positivo ovviamente). Team motivato e stakeholder onboard rappresentano già 2 ingredienti importantissimi per sviluppare un prodotto fatto bene.

È un comunicatore

Avere una vision è una cosa fondamentale e saperla comunicare è altrettanto importante. Comunicare a chi? Il Product Owner si relaziona continuamente con il team, con i clienti, con gli stakeholder, sale sul palco per parlare del suo prodotto (pensate agli eventi con i pitch delle startup): ha doti di comunicazione, supportate dalla vision, che gli consentono di convincere le persone intorno a lui che le scelte che fa sono quelle giuste. Avere una buona vision ma non saperla comunicare a volte equivale a non averla, soprattutto quando hai bisogno dell’onboarding di sponsor strategici, siano essi interni o esterni, come per esempio finanziatori: un Product Owner che sa comunicare la vision in maniera convincente può far la differenza fra un progetto che muore nel backlog dei sogni e uno che invece vede la luce ed ha successo.

È poliglotta

Dover comunicare la propria vision a molti interlocutori, richiede che il PO sappia parlare molte lingue diverse: deve parlare la lingua dello sviluppo al team, quella marketing al CMO, quella business al CEO, quella del cliente (una lingua molto difficile da imparare) al cliente stesso.

È un semidio

Non sono poche le caratteristiche che un PO deve avere. In effetti il ruolo così com’è concepito in Scrum è estremamente sfidante, soprattutto su prodotto molto complessi, con un’ampia varietà di interlocutori lati stakeholder e clienti. Per questo in molte realtà si riduce lo spazio di azione del PO, spostando qualche compito su altre figure interne o esterne al team.

E questo è un vero peccato. Il PO così com’è concepito è una figura consapevole, è una guida sul prodotto, conosce il mercato, l’essenza tecnica del prodotto, quali sono i suoi punti di forza, cosa i clienti odiano e adorano. E per questo può esercitare la sua accountability con autorevolezza; al momento che gli togli un pezzo, perderà un punto di vista e comincerà a giustificare, con quella mancanza, i suoi piccoli grandi fallimenti.

Se un Product Owner è troppo carico, l’approccio deve essere diverso, che poi è lo stesso che si usa per tagliare le User Story: piuttosto che tagliare una responsabilità, taglia lo scope del prodotto. Un prodotto si può tagliare in verticale, basta pensarci un po’. Di solito si hanno ambiti di prodotto in carico ad un unico PO che accorpano più prodotti perché simili. Si creano poi 2 PO, con 2 team, dove ognuno lavora sul nuovo ambito che è il risultato del taglio verticale.

Per finire

Non volendo mi sono venuti 10 punti, ma non chiamerò l’articolo “Le 10 caratteristiche che un Product Owner deve avere”. Troppo banale.

Vi aggiungo qui in calce un video che secondo me è l’apoteosi di come si può spiegare “Cos’è un Product Owner”: è un video di Henrik Kniberg, uno degli dèi di Agile e Scrum. Godetevelo.