Caro Product Owner, di cosa sei realmente owner?

Avete presente la differenza tra un prodotto, una specifica funzionalità ed un componente di prodotto?
Questa distinzione – magari non immediata per tutti – è alla base della classificazione che Roman Pichler adotta per chiarire l’ambito di intervento del Product Owner.
Ancora oggi infatti c’è una certa confusione su questa figura perché si tratta di un ruolo complesso, sfaccettato e che può essere applicato in modo differente a seconda dei contesti organizzativi e della dimensione dell’azienda.

Ma partiamo dalle basi…
Di cosa si occupa il Product Owner?
Il Product Owner è colui che gestisce il prodotto per conto dell’organizzazione.
Avrà quindi due referenti principali: da una parte gli utenti o clienti, dall’altra l’azienda stessa che commercializza il prodotto.
Il prodotto è un mezzo per creare valore.
Qualcosa in grado di risolvere un problema o generare un beneficio per gli utilizzatori e i clienti, ma anche un asset tangibile dell’azienda in grado di generare revenue o stimolare la vendita di altri prodotti/servizi.

Secondo questa definizione è legittimo chiedersi se il Product Owner gestisca uno o più prodotti e se ciò che gestisce sia davvero un prodotto.
L’ambiguità è data dal fatto che spesso le funzionalità e i componenti – che sono parti del prodotto – vengano considerati essi stessi prodotti, pur non essendo in grado di generare valore da soli.

Analizziamo più nel dettaglio questi concetti.
Una funzionalità è un attributo del prodotto con cui l’utente può interagire.
Parliamo ad esempio di una funzione di ricerca e navigazione, del log-in o del check-out per effettuare un acquisto.
Tutti questi sono step dello user journey, non prodotti essi stessi.
Il valore per l’utente è dato dall’esperienza complessiva, non dalla singola funzionalità (avete mai sentito discorsi di questo genere? “Non sono riuscito ad acquistare il prodotto che volevo, ma sono rimasto soddisfatto del semplicissimo processo di registrazione”. Mai visto!).
Colui che gestisce singole funzionalità di prodotto è un Feature Owner.

D’altra parte un componente è un building block del prodotto, un elemento della sua architettura come ad esempio un database management system, un data access layer o la user interface stessa.
Anche in questo caso si tratta di una parte del prodotto (uno strato a ben vedere), non del prodotto nell’accezione di veicolo di valore.
Qui il concetto nella testa dell’utilizzatore finale si fa sempre più labile. Come è organizzato tecnicamente il prodotto non ha alcun importanza per il cliente (“Basta che funzioni!”).
Chi gestisce singoli elementi dell’architettura del prodotto è un Component Owner e di norma ha un background tecnico dato l’ambito specializzato di intervento.

Anche a livello della product ownership vera e propria è possibile fare una distinzione.
Un conto è gestire un prodotto a livello strategico, altra cosa è gestirne l’evoluzione day-by-day.
Pur essendo questi due livelli intercomunicanti, le skill e le competenze richieste sono profondamente diverse.
Pichler parla in questo caso di “Big Product Owner” e “Small Product Owner”.

Il Big Product Owner è responsabile sia della strategia sia della tattica, ma delega l’esecuzione della seconda ad altre figure.
E’ colui che elabora la vision di prodotto e ne definisce gli obiettivi. Deve sapere come il prodotto crea valore, chi sono i clienti, qual è la sua value proposition distintiva e come si differenzia rispetto ai competitor.
Il Big Product Owner definisce la roadmap di prodotto, gestisce gli stakeholders, interagisce con i customer e gli user, produce forecast e tiene traccia delle performance.

Lo Small Product Owner è responsabile di attività di tipo tattico.
Gestisce e prioritizza il backlog, scrive le user stories, si occupa del release planning, partecipa alle cerimonie Scrum e lavora a diretto contatto con il team di sviluppo e lo Scrum master avendo prevalentemente a che fare con i vincoli di prodotto (tempi, costi e ambito).

Ovviamente il tipo di Product Owner adottato in un determinato contesto è in stretta correlazione con l’organizzazione dei team di lavoro e la dimensione dell’azienda.
Se l’azienda adotta component team avremo dei Component Owner, se utilizza feature team potremo avere sia Feature Owner sia Product Owner.
La differenza tra Big e Small Product Owner può dipendere anche dalla dimensione dell’azienda: in start-up, realtà medio-piccole e aziende grandi dove sono stati adottati framework di scaling sono più facilmente presenti Big Product Owner (figure più vicine all’ambito del product management classico); in realtà di medie dimensioni dove sono presenti più prodotti o prodotti maturi la responsabilità è più spesso ripartita tra Small Product Owner, mentre il vero controllo del prodotto è tenuto dal management o da figure dedicate (es. Head of Product, Business Owner, ecc.).

E voi che tipo di Product Owner siete? Avete sperimentato questi diversi livelli di gestione? Avete preferenze a riguardo? Mi piacerebbe confrontarmi con chi ha esperienze di prima mano su questo tema.

Per approfondimenti sull’argomento trovate a questo indirizzo la registrazione del webinar di Roman Pichler sul ruolo del Product Owner che ha ispirato questo post.

Il Product Owner in un’immagine

Girovagando in rete ho trovato uno schema che riassume a colpo d’occhio il ruolo del PO, per riprendere un argomento che mi sta a cuore…

scrum-product-owner-role

Ha il pregio di sintetizzare le responsabilità del Product Owner all’interno dello Scrum Team.
Ripercorriamo gli eventi e gli artefatti Scrum con un focus su questa figura.

Con chi interagisce in PO

Il Product Owner è un focal point per tutti gli stakeholder di progetto.
E’ fondamentale che le richieste di clienti esterni ed interni all’azienda (ad esempio il management, i Product Manager, i Software Architect, ecc.) siano indirizzate al PO che funziona da collettore unico di richieste verso il team Scrum.

Responsabilità del Product Owner

Questo argomento richiederebbe un post dedicato data la vastità dell’argomento…
Lo schema descrive le principali responsabilità operative del PO:

Non approfondisce invece le attività di tipo più strategico quali – ad esempio – l’analisi dei bisogni degli utenti, lo studio degli scenari di mercato, la definizione della vision di prodotto, ecc.

Release planning

In questa fase il compito fondamentale del Product Owner è definire gli obiettivi della release e spiegare le principali funzionalità da rilasciare.
Un aspetto interessante – e spesso sottovalutato – presente nello schema è l’analisi dei rischi che deve essere compiuta dal PO e dal team in questa fase, attività che può migliorare sensibilmente la pianificazione.

Sprint Planning

In fase di Sprint planning il Product Owner descrive al team cosa deve essere fatto seguendo le priorità elencate nel backlog. Definisce l’obiettivo dello sprint e ripercorre le singole user stories con l’intento di rendere chiaro il tipo di utente che ne trae vantaggio, la funzionalità richiesta ed il beneficio atteso.

Daily Scrum

E’ opportuno che il Product Owner  sia presente al Daily Scrum, ma è il team ad essere protagonista di questo momento. Organizza la propria giornata e fa il punto sullo stato dell’arte.
Per questo motivo è utile che il PO ci sia (se non sempre spesso), che ascolti gli aggiornamenti e le esigenze del team senza far pesare la propria presenza.
E’ tendenzialmente un osservatore silenzioso nel Daily Scrum.

Sprint

Durante l’iterazione il Product Owner tiene d’occhio l’andamento dei lavori, verifica in corso d’opera quanto il team sta realizzando ed è disponibile per chiarimenti ed approfondimenti.

Sprint Review

Al termine dell’iterazione il Product Owner ha il compito principale di accettare o rifiutare quanto sviluppato dal team. Solo lui può decidere cosa considerare realmente “done”.
Nel corso della demo presenta agli stakeholder l’obiettivo dello sprint e contestualizza quanto realizzato all’interno della più ampia pianificazione di release.

Retrospective

Questo evento è presidiato dallo Scrum Master con l’obiettivo del miglioramento continuo. Mediante l’analisi di cosa ha funzionato e cosa non ha funzionato nel corso dello sprint vengono individuate una o più azioni per ottimizzare il processo.
Il Product Owner partecipa attivamente alla retrospective insieme a tutti gli altri membri del team Scrum, portando le proprie osservazioni e proposte.

Al termine della release

Così come per i singoli sprint il PO accetta o rifiuta le storie, al termine della release è colui che tira le fila dell’intero progetto, verifica i deliverable, decide il go/no-go finale e lo comunica a tutti gli stakeholder.

Product Ownership: il gruppo su Linkedin

Come orientarsi nel ruolo di Product Owner?
Quali sono gli strumenti e gli skill più importanti per guidare con efficacia un gruppo di sviluppo?
Quali sono i principali problemi con cui dovrete confrontarvi in questa attività?
Cosa vi differenzia dagli altri profili “agili”?
Ma anche… sono solo o esistono altri Product Owner come me in Italia?
Se queste sono alcune delle domande che avete in mente un’altra risorsa può venirvi oggi di aiuto.

Su Linkedin è attivo da anni il gruppo “Lean Agile Italy”, che conta ormai più di 2.000 membri.
Al suo interno è stato creato un sotto-gruppo italiano espressamente dedicato alla Product Ownership.
Si tratta ancora di un piccolo nucleo di professionisti, ma posso garantirvi che è molto motivato a portare avanti discussioni ed approfondimenti su questo tema.

Una delle cose che ci unisce è la consapevolezza che su questo tema c’è ancora molto da dire, da scrivere e da condividere.
La letteratura Agile sull’argomento non è così estesa ed esaustiva, le competenze richieste sono variegate e difficilmente presenti in un’unica figura professionale, gli “scogli” che si possono incontrare esercitando questo ruolo sono numerosi e i dubbi che emergono sul campo ancora di più.

Da qui è nata l’idea di uno spazio di riflessione dedicato. E’ un’iniziativa nata a valle del PO Camp (per chi non sapesse di cosa si tratta ne ho parlato in questo post), ma è estesa a chiunque sia interessato a discutere il tema della Product Ownership.
Il gruppo è privato, ma chiunque può chiedere di essere ammesso ed è il benvenuto a portare il proprio contributo (essere un Product Owner non è un requisito obbligatorio!).

E’ un punto di partenza, ma ha tutte le caratteristiche per andare lontano. Se siete appassionati come me, vi invito ad andare a dare un’occhiata.