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.