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.

Perché investire nella strategia di prodotto

La scorsa settimana ho parlato di visione strategica, di cosa sia e quanto sia rilevante per l’allineamento di tutte le iniziative in azienda rifacendomi al framework della Core Strategic Vision.
Oggi voglio invece approfondire un elemento su cui la visione strategica aziendale ha un impatto determinante: la strategia di prodotto.
Su questo argomento ci viene in aiuto Roman Pichler con i suggerimenti contenuti nel volume “Strategize” pubblicato nel 2016.

Visione e strategia di prodotto

Cosa indica il termine “strategia”?
Un piano d’azione per raggiungere un obiettivo a lungo termine.
Pianificare il successo di un prodotto comporta secondo l’autore due aspetti:

  1. trovare la giusta strategia di prodotto
  2. decidere come implementarla.

Nel primo ambito i due elementi chiave sono la visione e la strategia di prodotto; in fase di esecuzione la product roadmap e il product backlog (di cui abbiamo parlato qui).

La visione è la ragione ultima per creare il prodotto e deve essere coerente con la Core Strategic Vision dell’azienda. Descrive il cambiamento positivo che il prodotto porta e risponde alla domanda “perché questo prodotto esiste?”.

La strategia di prodotto descrive come l’obiettivo a lungo termine è raggiunto: include la value proposition del prodotto, il posizionamento di mercato, le principali caratteristiche e gli obiettivi di business. Indica insomma come la vision viene realizzata.

La product roadmap mostra come la strategia di prodotto viene eseguita definendo le principali release con specifica di date, obiettivi e funzionalità.
Infine il backlog contiene tutti i dettagli necessari per sviluppare il prodotto come indicato dalla roadmap con epiche, user stories e altri requisiti.

Se volete qualche dettaglio operativo su come derivare il backlog di prodotto dalla product vision vi consiglio di utilizzare la vision board.

Gli elementi della strategia di prodotto

La strategia di prodotto guarda alla “big picture”, non ai dettagli.
Il piano di alto livello che aiuta a realizzare l’obiettivo finale deve spiegare a chi è destinato il prodotto è perché le persone vogliono acquistarlo e utilizzarlo; che cos’è il prodotto e in che cosa è differente dagli altri; quali sono gli obiettivi di business e perché per l’azienda ha senso investire in esso.

Gli elementi della strategia di prodotto sono quindi 3:

  1. il mercato e i suoi bisogni
  2. gli obiettivi di business
  3. le funzionalità chiave e gli aspetti differenzianti.

Il mercato descrive il target e gli utilizzatori del prodotto, le persone che hanno maggiore probabilità di acquistarlo e usarlo; i bisogni comprendono i problemi che il prodotto risolve o il principale beneficio che produce.
Abbiamo parlato a lungo di questi aspetti in relazione alle Personas se ricordate.

Il business goal definisce come il prodotto genererà valore per l’azienda. Anche su questo aspetto ci siamo già soffermati in passato parlando di come possiamo definire più dettagliatamente il valore.
Nella maggior parte di casi si parla di generare ricavi, ma un prodotto potrebbe produrre valore anche supportando la vendita di altri prodotti o servizi, riducendo i costi o facendo aumentare il valore del marchio. A seconda dell’obiettivo sceglieremo il corretto KPI per misurare il valore generato dal prodotto.

Le key features sono quegli aspetti del prodotto cruciali nel creare valore per i clienti e gli utilizzatori, le funzionalità che lo fanno scegliere dal pubblico al posto delle altre alternative di mercato.

La product strategy può cambiare?

Proviamo a contestualizzare quanto detto sinora.
Abbiamo detto che la vision è la ragione ultima per creare il prodotto e descrive il cambiamento in positivo che il prodotto vuole generare.
Pichler fa l’esempio di una app che aiuti le persone a diventare consapevoli di cosa, quando e quanto mangiano.

La vision in questo caso può consistere nell’aiutare le persone a fare una vita più salutare; la strategia è creare una app che monitori l’assunzione di cibo tramite alcuni device quali uno smartwatch, una banda fitness e una bilancia smart.

Intanto notate come una visione di questo tipo – aiutare le persone a fare una vita più salutare – abbia maggior potere di ispirare rispetto al semplice obiettivo di “perdere peso” (una visione efficace deve essere grande!).
L’altro aspetto fondamentale è questo: la vision non cambia nel tempo, ma la product strategy può cambiare.

Tornando all’esempio di prima se la app non si rivela lo strumento giusto per aiutare le persone a fare una vita più salutare si possono provare altre strade per raggiungere l’obiettivo: scrivere un libro, creare una community di influencer, ecc.

Quando la vision manca…

Abbiamo più volte ribadito che la strategia di business deve dirigere quella di prodotto e che la company vision influenza la visione del prodotto.
L’autore di “Strategize” è proprio diretto quando scrive:

“Se il tuo business non ha una strategia generale o se non ne sei consapevole, rimanda la formulazione di una strategia di prodotto fino a quando la business strategy non è disponibile.
A meno che tu lavori per una start-up, in qual caso il business e la strategia di prodotto è molto probabile che siano identici”.

L’autore ci suggerisce anche un possibile espediente quando si verifica una situazione di questo tipo. L’idea è di mettere insieme i principali stakeholder, fare formulare loro prima individualmente la vision del prodotto e poi condividerla nel gruppo.
Si tratta di un esercizio molto potente che consente di guardare cosa hanno in comune le visioni di ciascuno e di creare una strategia di ampio respiro, condivisa e di ispirazione.

Sono più chiari adesso i benefici di una strategia di prodotto?
La finalità è massimizzare le chance di successo del prodotto stesso.

La strategia è il nodo chiave tra la visione in alto e l’esecuzione in basso: indica la direzione a cui puntare in linea con la vision aziendale più generale e allo stesso tempo indirizza il processo di discovery permettendo di scoprire i giusti dettagli di prodotto.
E poi, cari Product Owner, deve ispirare voi e le persone che lavorano con voi!
Deve avere la capacità di coinvolgere e farvi venire la voglia di rimboccarvi le maniche.
Un po’ come dice Pichler che va dritto al punto ed è sempre per me di grande ispirazione :

“Life is too short to work on products
you don’t believe in”.