Product Owner per caso

12 Giugno 20218 Gennaio 2023

3 consigli per esercitare meglio la tua product ownership

Conoscete Robbin Schuurman? E’ un Agile Coach e Scrum Master Trainer di origini olandesi che ha alle spalle un’esperienza di Product Owner e prima ancora di Project Manager.
E’ anche un prolifico autore di articoli e post sul suo blog, su Medium e Scrum.org.
In questi giorni ascoltavo una puntata di Product Owner Podcast di cui è stato ospite per parlare delle responsabilità del PO e di come dire no.

Abbiamo già parlato in passato di questa responsabilità del PO.
Schuurman ribadisce che dire no è una delle cose più difficili che il product owner deve fare e allo stesso tempo uno dei modi più efficaci per creare valore.
Proprio così! Creare valore attraverso la negazione. Perché di 10 idee o richieste che arrivano sul nostro tavolo statisticamente una sola è veramente rilevante per le nostre personas primarie mentre le altre 9 – che magari sono comunque buone idee – non lo sono.
Quindi dire no alla maggior parte delle richieste ha la finalità di preservare il massimo valore del prodotto che state gestendo.

Speriamo di poter leggere presto qualche chicca nel prossimo libro di Schuurman in uscita “50 Shades of No”; nel frattempo lui ha suggerito 2 modi immediatamente spendibili per dire no e condiviso alcuni consigli per esercitare al meglio la product ownership che trovo pratiche e centrate. Ve le riassumo.

Dire no in modo gentile e perentorio

Sostiene il coach: “Dire no è difficile per moltissimi Product Owner. È difficile perché ci sono tantissime persone che chiedono o esigono determinate funzionalità. Massimizzare il valore è una tua responsabilità e lo fai mediante lo stakeholder management e dicendo no”.

Ecco due esempi efficaci per un NO “chiaro e tondo”:

“non implementiamo la funzionalità X perché non è coerente con la product vision”
Questo è un no molto potente, ma presuppone che abbiate formulato una product vision e che sia stata anche condivisa con gli stakeholder
“non lavoreremo sul requisito X perché non è di valore per i clienti e gli utenti”
Anche questa affermazione è perentoria e contiene a sua volta un presupposto: che abbiate preso il tempo di validare con questi interlocutori cosa sia realmente di valore.

In sostanza il presupposto per poter dire no con credibilità è fare bene l’attività di stakeholder management. Attendiamo “50 Shades of No” per prendere altri spunti…

Non tutti gli stakeholder sono ugualmente importanti

“Chi sono i tuoi stakeholder e con chi spendi il tuo tempo?” ci chiede Chris.
Nella sua esperienza ha incontrato molti product owner che trascorrono tanto tempo a gestire gli stakeholder (e questa di per sé è una cosa positiva!) senza tuttavia fare dei distinguo in termini di importanza o dedicando troppa energia a quelli meno importanti.
Gli stakeholder meno importanti sono solitamente quelli con poco potere e poco interesse per il prodotto finale; gruppi di persone che dovrebbero essere tenuti d’occhio saltuariamente.

“Nelle pratiche quotidiane molti PO sembrano dare ugualmente importanza a tutti. Mi dispiace… questo non è vero! Non tutte le parti interessate sono ugualmente importanti! Alcuni hanno un alto interesse per il prodotto, altri un interesse basso… alcuni hanno molto potere, altri no… alcuni collaborano con voi nella creazione, altri sono solo interessati all’impatto che il vostro prodotto avrà sul loro dipartimento e sulle persone”.

E’ fondamentale secondo il coach essere ben consapevoli di quali sono gli stakeholder più importanti e meno importanti. Robbin Schuurman ci suggerisce di creare una mappa degli stakeholder così da organizzare il nostro tempo con le parti interessate in modo più efficace, efficiente e intelligente (è un tema che abbiamo toccato in relazione agli stakeholder).

Esercitati ad agire da owner

Non è inusuale all’inizio della carriera come PO trovarsi in situazioni in cui non si ha alcun mandato, alcun potere decisionale o alcuna libertà. E’ capitato a tutti noi e in breve tempo abbiamo realizzato che dovevamo rimboccarci le maniche.
Non è la Scrum Guide o qualche guru dell’Agile a venirci in aiuto quando si tratta di guadagnare autorevolezza sul campo di gioco.

Quello che potete cominciare a fare (in qualsiasi momento) è comportavi da “owner”, da proprietari del prodotto.
Non avete bisogno di chiedere il permesso di sviluppare una nuova funzionalità o dedicare del tempo alla risoluzione di bug o alla riduzione del debito tecnico. Schuurman ci incita a comportarci da proprietari e non da proxy.

“Devi smettere di fare lo scriba e iniziare a comportarti da owner! Il modo in cui ti presenti agli stakeholder, il modo in cui presenti il tuo prodotto e il modo in cui agisci (parli, ti comporti, ti presenti, ecc.) determinano il mandato che ottieni! Se inizi ad agire come un vero product owner, ad assumerti la responsabilità, a formulare un piano dimostrando che ti prendi cura del prodotto e del tuo team, questo ti aiuterà ad aumentare il tuo mandato”.

Questo è un punto cardine sottolineato dall’autore: tra le responsabilità del PO c’è creare un piano, costruire il prodotto e renderlo di successo (in questo ordine!). Se non ti sei preso il tempo di elaborare un tuo piano qualcun altro te ne affibbierà uno. Del resto la delivery ha bisogno di una tabella di marcia, una previsione, una guida per un arco di tempo che va dai 3 ai 6 mesi, senza che diventi “il santo graal” né tantomeno sia scolpito nella pietra.
Piano e vision devono precedere la creazione del product backlog.

Smetti di fare il piccione viaggiatore…

Schuurman riporta la sua esperienza di coaching: “Quello che vediamo fare abbastanza spesso dai Product Owner è che iniziano a fungere da proxy, un gateway, l’unico punto di ingresso, verso il team di sviluppo.
Il team non sono autorizzati a parlare con gli stakeholder, i clienti e gli utenti; tutte le comunicazioni in questi team passano attraverso il Product Owner”.

Esercitare il controllo non significa fare da tramite tra gli stakeholder e il team.
Questa mala pratica ha un costo enorme in termini di tempo per il PO oltre a rivelarsi inefficace e diseducativa per lo Scrum team.

Un product owner consapevole del proprio ruolo supporta il più possibile la comunicazione diretta tra stakeholder, clienti, utenti, business, sales e sviluppo.
In questo modo il team recepisce direttamente i feedback sul prodotto, acquisisce comprensione degli utenti e del business.
Per quanto il mandato del PO sia ampio e versatile non c’è bisogno di affrontare tutti i problemi da solo; si può fare leva sulla squadra nel momento in cui ha compreso la visione di prodotto, la direzione in cui vuoi andare e quali sono i prossimi passi da compiere.

Tra i valori agili ci sono l’autonomia e il coraggio: non dimentichiamo di lasciare spazio al team per esercitarli! Una volta che il PO ha condiviso la vision di prodotto e ha fornito un obiettivo chiaro per lo sprint , lascia che gli sviluppatori si organizzino a riguardo e che prendano tutti i contatti che servono per costruire al meglio le funzionalità richieste, compresa la comunicazione diretta con gli stakeholder.
E se proprio qualcosa va storto, c’è la Sprint Retrospective con il team per scoprire cosa non ha funzionato e come migliorare in futuro.

30 Maggio 202130 Maggio 2021

Le 3 C delle user stories: carta, conversazione e conferma

Oggi parliamo di storie, un grande classico per i product owner, e andiamo alla base della loro costruzione esplorando insieme le 3 C delle user stories: carta, conversazione e conferma.

Ma cosa sono le user stories? Sono semplici descrizioni, contenute in una frase, di ciò che un determinato utente vuole ottenere raccontate dal suo punto di vista.
Sono nate nell’ambito dell’Extreme Programming prima dell’inizio di questo millennio (la loro origine si fa risalire al 1998) e sono poi diventate popolari in tutti i processi agile.

User story: qualche esempio di scrittura delle card

Facciamo qualche esempio pratico per capirci meglio.
Immaginiamo di stare sviluppando un sito di annunci (i cosiddetti classified) che consente a venditori e acquirenti di scambiarsi beni materiali e servizi accordandosi tra privati.
La nostra piattaforma avrà user stories come queste:

come utente di <nome della piattaforma> , posso effettuare ricerche su articoli specifici.
come venditore, posso facilmente consultare la lista di tutti i potenziali acquirenti interessati al prodotto che ho messo in vendita.

Come vedete sono frasi brevi che descrivono cosa un utente vuole fare, raccontate secondo il suo punto di vista.
Un’altra cosa che possiamo notare è che abbiamo più tipologie di utenti: nel primo caso parliamo di un utente generico, nel secondo adottiamo il punto di vista di uno dei principali attori della piattaforma (in venditore).

Possiamo fare la stessa cosa mettendoci dal punto di vista dell’acquirente:

come potenziale acquirente di una macchina usata, voglio poter vedere delle foto del veicolo.

Cosa manca ancora in questo esempio?
Manca un dettaglio che per me è la parte più importante delle user stories, la cosiddetta clausola so-that.
Ciò che spiega perché un determinato utente vuole una certa cosa, qual è la sua finalità, qual è il risultato finale a cui tende (o outcome).

La storia potrebbe prendere allora questa forma:

“come potenziale acquirente di una macchina usata, voglio poter vedere delle foto del veicolo così da potermi accertare delle sue condizioni”

O dal punto di vista del venditore:

“come proprietario di un auto che desidero vendere, posso creare una pagina in cui descrivere lo stato dei veicolo e mostrarlo al suo meglio”

Notate che stiamo parlando della medesima funzionalità (le foto associate al prodotto) da due punti di vista differenti: quello del venditore e quello dell’acquirente.

User story: l’importanza del punto di vista

Bene, abbiamo introdotto il formato più classico con cui si scrivono le user stories:

Come <tipo di utente>, voglio <funzionalità> così da <obiettivo o valore per l’utente>.

Semplice ed efficace! Chiunque è in grado di esprimere un bisogno, una necessità o un desiderio secondo questo formato.
Ma non è solo la semplicità ad essere la chiave del successo delle user stories, l’elemento essenziale qui è la prospettiva: il punto di vista che adottiamo ci aiuta a relazionarci con specifiche tipologie di utenti, a metterci nei loro panni.

Sembra un dettaglio ma non lo è.
Ditemi se vi fa lo stesso effetto esprimere le medesime funzionalità come si descrivevano una volta nei documenti di requisiti …

il sistema consente all’utente di effettuare una ricerca
il sistema consente all’utente di pubblicare online un prodotto
il sistema consente all’utente di associare una o più foto a un prodotto

Il significato di queste affermazioni è lo stesso ma nel primo caso rispondiamo con più empatia perché stiamo mettendo l’utente – una persona – al centro della scena.

User story: la conversazione a partire dalla carta

Un errore in cui cadono spesso i team che muovono i primi passi con i framework agili è pensare che una volta scritta la user story tutto sia chiaro e definito.
In realtà chi ha un po’ più di esperienza alle spalle sa bene che la scrittura è solo l’inizio del gioco.
Non dobbiamo dimenticare che la user story comprende tre C:

una scheda o carta (= card),
la conversazione (= conversation)
criteri di conferma (= confirmation).

Le 3 C sono un’allitterazione ideata da Ron Jeffries per chiarire che una user story è più di un semplice testo scritto su carta fisica o su strumento software.
Le user stories sono brevi, non sono fatte per contenere molti dettagli bensì per agevolare delle conversazioni (si parla anche delle storie anche come “placeholder per conversazioni con il team”).
La carta è solo una delle tre C, la più visibile, e anche quella meno importante.

Mi è capitato in passato di lavorare con team che pretendevano di avere il massimo livello di dettaglio nelle storie; questo desiderio di chiarezza e completezza per quanto comprensibile dà l’illusione che tutto sia stato definito e compreso ma non aiuta le persone ad uscire dalla propria comfort zone e fare il “viaggio di scoperta” nei bisogni dell’utente.
E’ dall’interazione tra il product owner, il team allargato e gli utenti che nasce la vera comprensione di ciò che c’è da fare, non da una frase scritta su un pezzo di carta.

Non si tratta di un modo alternativo di scrivere requisiti, la card è “una promessa a due vie” come dice Mike Cohn:

la promessa del team di porre domande prima di iniziare a lavorare su una storia
la promessa del product owner di essere disponibile ad approfondire l’argomento.

Questi due aspetti insieme ci evitano di dover scrivere corposi documenti di specifiche contenenti ogni singola funzionalità.

Se il team si parla prima di iniziare a lavorare, il product owner può specificare solo quanto basta per poter avere quella conversazione.
E’ la conversazione in sé che rende agile un team, non la scrittura delle storie, l’utilizzo di post-it o di tool come Jira.

User story: la C di conferma

Quando Mike Cohn illustra questa parte delle storie dice che non gli piace iniziare qualcosa se non capisce come saprà quando ha terminato. E a chi piace questa incertezza?
I criteri di conferma di una user story servono proprio a questo; sono il modo in cui il product owner definisce insieme al team ciò che deve essere fatto affinché lo sviluppo possa essere considerato completo.

Ricordate quando a scuola per la prima volta un insegnante vi ha assegnato un riassunto di un libro? Alzi la mano chi non si è chiesto quanto dovesse essere lungo lo scritto!
Ecco, questo è un classico esempio di criterio di accettazione. Per alcuni professori una sintesi di una pagina è accettabile, per altri non si parla di sufficienza sotto le 3 pagine (e non pensate di barare con la dimensione del testo e l’interlinea!).

Una parte della conversazione tra il team e il product owner prima di lavorare una storia riguarderà proprio i criteri di conferma, ovvero come ciò che sarà sviluppato verrà valutato per l’accettazione durante la sprint review.
Si tratta delle “condizioni di soddisfazione” della storia. In altre parole, affinché il product owner possa considerare la user story fatta, una determinata cosa deve fare questo, quello e quell’altro.

Torniamo al nostro esempio di prima quando parlavamo della possibilità di associare delle foto all’auto che il nostro utente vuole mettere in vendita.
Per questa user story potremmo definire criteri di accettazione di questo tipo:

i formati di immagine accettati dal sistema (es. jpg, png, ecc.)
il peso massimo della singola immagine
la possibilità di vedere un’anteprima dell’immagine caricata
e magari anche la possibilità di poter ruotare eventuali immagini capovolte prima della pubblicazione.

User story: la prima C da sola non basta!

Siamo arrivati alla fine del nostro excursus sulle user stories.
Come abbiamo visto le storie non sono un nuovo modo di scrivere i requisiti, ma molto di più. Hanno come minimo 3 funzioni:

sono un placeholder per una conversazione sui bisogni degli utenti
sono strumenti per capire cosa vogliono gli utenti e cosa ha senso realizzare
sono un modo per programmare il lavoro del team.

Quindi ricordatevi di prestare attenzione a tutti e 3 gli aspetti: non solo al testo che andrete a scrivere su una scheda, ma anche alle conversazioni sulla funzionalità e ai criteri di conferma che utilizzerete per determinare se la storia è completa.

Note

Questo post è liberamente tratto dalle lezioni di Mike Cohn sulle user stories. Se volete approfondire vi consiglio il suo corso – molto valido – “Better User Stories“.

Nel blog trovate anche diversi post dedicati alle storie. Eccone qui una piccola selezione:

23 Maggio 202123 Maggio 2021

Valore per i clienti e impatto commerciale del prodotto

Product owner, ti sei mai chiesto qual è l’impatto commerciale del tuo prodotto?

C’è una citazione di Marty Cagan che ultimamente ritrovo spesso nelle mie letture online:

“lo scopo dei team di prodotto è servire i clienti creando prodotti che i clienti amano, lavorando tuttavia per l’azienda”

Cosa intende dire esattamente Cagan con questa frase?
Vuole sottolineare il fatto che come responsabili del prodotto non ci muoviamo all’interno di un silos; siamo focalizzati sul valore per il cliente finale ma abbiamo la nostra parte di responsabilità sull’impatto commerciale del prodotto e sul conto economico dell’azienda.

Mentre riflettevo sulle implicazioni di questo messaggio mi sono imbattuta su Mind The Product in un intervento del Chief Product Officer di Talabat – Yi-Wei Ang – dal titolo “Driving commercial impact for product teams”.
L’ho trovato molto interessante e ve lo riassumo qui di seguito.
E’ proprio incentrato sul fatto che la figura del product practitioner si trova oggi di fronte all’ennesima evoluzione.

Perché essere customer-obsessed non basta…

Come figure di prodotto – product owner, product manager, designer ed esperti UX – siamo spesso sbilanciati verso la prima parte dell’affermazione di Cagan: amiamo creare prodotti amati dai clienti.

Noi siamo quelli che nel giro degli ultimi 10 anni sono passati – per chi lavora in questo ambito da più tempo – dalle pianificazioni annuali di sviluppo dei prodotti e da lunghi documenti di requisiti redatti upfront ad essere i customer-advocates, la voce del cliente all’interno dell’azienda.

Diciamoci la verità: abbiamo un bias verso la creazione di prodotti che abbiano valore per i nostri clienti ma se spendiamo il 90% del nostro tempo su questo aspetto nei processi di discovery e delivery, quanto ci dedichiamo al successo commerciale?

Secondo Yi-Wei Ang è giunta l’ora di ribilanciare i nostri sforzi perché il ruolo del prodotto sta cambiando. Ciò che ci è richiesto oggi è di continuare a creare prodotti amati dai clienti ma che allo stesso tempo siano in grado di far crescere il business, che abbiano un impatto tangibile sulla bottom line (proprio quell’ultima riga del rendiconto finanziario che mostra l’utile o la perdita netti di un’azienda).

E’ ora di abbattere un altro silos…

A pensarci bene questo aspetto è spesso alla base della frizione o dell’incomprensione che si crea tra il team sales e quello di prodotto.

Vi è mai capitata questa situazione?
Il team sales sollecita il prodotto a sviluppare certe funzionalità richieste espressamente dai clienti con lo scopo, ad esempio, di diminuire il churn o tasso di abbandono. Il team di prodotto crea delle soluzioni senza un adeguato lavoro di discovery sul problema e alla fine le nuove feature rimangono inutilizzate senza raggiungere lo scopo iniziale.
E’ una dinamica alquanto frequente.
Evidentemente qualcosa è andato storto nella relazione tra i due.

Se vogliamo raddrizzare questa situazione il CPO di Talabat ci invita a farci carico dei risultati di business oltre che degli outcome di prodotto.
Lavorando a stretto contatto con il team business possiamo massimizzare i risultati per l’azienda nel senso più ampio.

Questo pensiero mi trova assolutamente d’accordo.
Ho sperimentato più volte che per essere davvero efficace nel mio lavoro con gli stakeholder devo essere in grado di mostrare al business l’impatto che sono in grado di produrre sulla bottom-line.
Il mio amministratore delegato, per quanto attento ai bisogni della clientela e consapevole delle metriche di prodotto, finisce comunque per misurare ogni risultato in termini di ricavi e riduzione dei costi. Non c’è niente di male, è il suo focus principale in fin dei conti.

Quantificare l’impatto commerciale del prodotto

Le vendite non sono altro rispetto al prodotto; il prodotto non serve il business, il prodotto è il business.
Se pensate che il prezzo, il costo di acquisizione dei nuovi clienti e il lifetime value siano aspetti che vi riguardano solo marginalmente come product owner state sbagliando strada e rischiate di perdere la migliore occasione per dare rilevanza al vostro ruolo in azienda.

Le decisioni business e di prodotto sono per lo più profondamente intrecciate.
Ang scherza sul fatto che anche se siamo diventati bravissimi ad utilizzare il business model canvas di Osterwalder ci sono alcuni aspetti di questo template che tendiamo con maggior frequenza a tralasciare.
Siamo super-concentrati sulla value proposition, le attività e le risorse chiave ma non approfondiamo altrettanto il prezzo, i canali utilizzati per il go-to-market, la struttura dei costi e delle revenue.

Quindi stiamo davvero dicendo che il Product Owner deve diventare anche un esperto degli aspetti finanziari del prodotto? Dobbiamo andare a coprire l’ennesimo ambito nel nostro ruolo?
La risposta è – come nelle ricette di cucina – “quanto basta”.
Dobbiamo conoscere e comprendere questi aspetti quanto basta per prendere le giuste decisioni.
La buona notizia è che non è necessario fare tutto da soli…

Co-creare con il business

Come possiamo portare l’organizzazione di business e quella di prodotto più vicine in modo da rafforzarle entrambe?
Il suggerimento che da Ang è semplice ed efficace: impariamo a co-creare con il business.

I product owner sono ormai abituati da tempo a considerare la relazione con i designer e con gli sviluppatori la chiave dell’attività di progettazione e sviluppo prodotto.
E’ una relazione che abbiamo creato all’interno dei framework agili e che oggi non mettiamo in discussione perché ne conosciamo il valore.

L’invito che ci viene fatto adesso è di estendere questa relazione di fiducia introducendo nel trio un quarto componente: il business.
Il business partner a quel punto si immerge con noi nella discovery, nella delivery e nella validazione.
L’approccio sperimentale che portiamo nella realizzazione del prodotto non si limita più alla prototipazione, ai test di usabilità o agli A/B test, ma si estende anche a validare le assunzioni di business sul pricing, i segmenti di clientela, le strategie go-to-market e molto altro.

Conoscere l’impatto economico del prodotto

In questa evoluzione della figura di prodotto Ang ci suggerisce di partire da una serie di domande a cui dare risposta:

Come fa i soldi il nostro prodotto?
Quali sono i costi associati alla linea di prodotto?
Quanto costa acquisire nuovi clienti?
Quanto costa far funzionare l’intera catena del valore?
Quali sono le assunzioni che il business sta facendo?

Quando diventiamo consapevoli degli economic drivers e dell’intero processo che va dall’acquisizione del cliente alle revenue la nostra capacità di influenzare l’evoluzione del prodotto e di creare storie potenti intorno al suo perché si fa esponenziale.

Nel mio caso so che questo passaggio non è stato facile da digerire; ho fatto resistenza per più tempo di quanto avrei dovuto.
Pensavo che essere misurata nel mio ruolo di responsabile di prodotto su metriche di business non fosse del tutto appropriato perché non sono aspetti che controllo direttamente; ho capito che questa è una visione parziale.
In realtà ho scoperto che l’essere legata proprio a obiettivi di business mi da la possibilità di esercitare grande influenza su quelle metriche e di dialogare con il management al livello in cui vengono prese le decisioni.

Quindi product owner non temere di affrontare nel tuo percorso l’ennesimo viaggio di scoperta. Entra nelle dinamiche del P&L; fatti aiutare dalla tua controparte business ed esplorate insieme come poter creare un impatto commerciale del prodotto senza precedenti.