Questi sono gli appunti presi durante la preparazione dell’esame di certificazione come professional scrum product owner II di scrum.org. Suggerisco a chiunque voglia intraprendere questo percorso il buon corso udemy che trovate qui. Prezzo ragionevole, contenuto di qualità.
Cosa é un prodotto?
Ogni product owner necessita un prodotto :-). Ma cosa è un prodotto? Un prodotto è un mezzo per fornire valore ai clienti. Può essere un bene fisico, un servizio o qualsiasi altra cosa, purché fornisca valore a qualcuno.
Il prodotto è definito dalla sua ragion d’essere. Perché qualcuno dovrebbe volere usare un prodotto? Per quello che fa, non per quello che è. Il cliente non vuole il prodotto, vuole i risultati che il prodotto gli permette di ottenere. Parafrasando il famoso professor Theodore Levitt, il cliente non vuole un trapano, vuole fare buchi.
Per questo, il product owner deve concentrarsi su quello che il cliente vuole (wants) e quello di cui ha bisogno (needs), massimizzando il valore.
Gestire l’incertezza
Lo sviluppo di un prodotto é un problema complesso (come da definizione del cynefin framework), in quanto caratterizzato da incertezza. Il product owner non sa se un’ipotesi funzionerà o meno. Per questo, è consigliato un approccio empirico, con cicli di feedback veloci.
Il modo migliore per validare le ipotesi consiste nell’effettuare esperimenti, rilasciando spesso feature sul mercato. Alcune pratiche associate sono l’uso di MVP, di survey e landing page in cui si permette la pre-sottoscrizione ad un prodotto…che ancora non esiste (tipo kickstarter).
Product owner maturity model
L’accountability (e non ruolo, visto che scrum non definisce più ruoli) di product owner (PO nel seguito) si declina in diversi modi in diverse realtà, secondo il livello di maturità della pratica:
- Al livello piu basso troviamo il PO scriba, che si limita a popolare il backlog seguendo le indicazioni di altri.
- Il passo successivo è il PO proxy. Non ha il permesso di aggiungere autonomamente entry al backlog, né di toglierle, né di rivedere le priorità.
- Il terzo livello è il PO business representative. Ha il diritto di rivedere le priorità, ma non ha potere sul budget del suo prodotto.
- Il passo successivo è il PO sponsor. Puo’ gestire il budget del prodotto.
- L’obiettivo finale è il PO enterpreneur, che agisce come un mini-ceo del prodotto, con piena delega.
Tipicamente i PO entrano a livello 2. L’evoluzione richiede uno sforzo attivo del PO stesso.
Interpretazioni fuorvianti
Il PO in scrum ha l’obiettivo di massimizzare il valore fornito al cliente. Spesso però il ruolo (ok, scrum non ha ruoli, ha accountabilities, ma non so proprio come dirlo diversamente in italiano) viene interpretato in modo diverso. In letteratura ci sono 6 deviazioni principali:
The clerk (il fattorino): si limita a mettere tutto a backlog, senza alcuna considerazione per il valore che le item erogheranno.
The story writer (lo scrittore): ritiene che il suo compito principale sia di raffinare tutte le item del backlog. Questo va contro lo spirito lean-agile alla base di scrum. Da un lato, avere troppe item dettagliate nel backlog è uno spreco, in quanto si tratta di semilavorati che potrebbero non vedere mai la luce. Dall’altro, le item del backlog sono placeholder per la conversazione diretta tra il team e gli stakeholder: renderle requirement completi di tutti i dettagli riduce la comunicazione diretta.
The manager: si focalizza sulle performances del team, prestando attenzione a cose come resource utilization, velocity e altre metriche di output. Cosi facendo, perde di vista il suo obiettivo principale: il delivery di valore.
The project manager: fa il PM. Trasforma gli standup in status report. Assegna task. Riduce l’accountability del team e lo deresponsabilizza.
The subject matter expert: non condivide la conoscenza con il team, che in questo modo si ritrova impossibilitato a contribuire appieno alla definizione delle soluzioni.
The gatekeeper (il guardiano del cancello): si pone come punto unico di contatto verso il team. Da un lato viene apprezzato perché scherma efficacemente il team dalle interruzioni. Tuttavia impedisce il feedback diretto degli stakeholder, cosa che limita trasparenza e ispezione.
Atteggiamenti desiderabili
Nel paragrafo precedente abbiamo visto come il PO non dovrebbe comportarsi. Quali sono invece i comportamenti desiderabili?
The visionary (il visionario): un PO deve avere una chiara visione del prodotto (product vision). La product vision costituisce un obiettivo a lungo termine e come tale puo’ cambiare e raffinarsi nel tempo. Un PO visionario comunica al team e agli stakeholder un messaggio ispirante e motivante.
The customer representative: il PO agisce come rappresentante dei bisogni e desideri dei clienti. Il suo obiettivo è la loro soddisfazione. Un modo per conoscere la soddisfazione dei clienti è il Net Propomoter Score, ovvero la propensione di un cliente di consigliare il servizio o prodotto a qualcun altro. Il satisfaction gap invece indica la distanza tra il livello corrente di soddisfazione e il livello atteso dal cliente. Un altro obiettivo del customer representative é quello di misurare l‘uso delle features del prodotto. Se nessuno usa le features che stiamo creando, c’è evidentemente un problema.
The decision maker: un PO che possa prendere decisioni tempestive in autonomia velocizza il flusso di lavoro. Il PO deve aver l’autorità per decidere, essere risoluto e basare le decisioni sulle evidenze, rinforzando così l’approccio empirico. Chiaramente un PO story writer o peggio scriba non avrà la delega per poter decidere autonomamente.
The experimenter: l’approccio empirico richiede l’esecuzione di esperiementi. Il PO deve guidare il team nel disegno degli esperimenti, valutarne i risultati. Meglio condurre un esperimento alla volta.
The influencer: la gestione degli stakeholder è importante nel product management come nel project management. Il PO puo’ usare pratiche come lo stakeholder mapping (identificazione, prioritizzazione, gestione) e il modello DISC.
The collaborator: il PO fa parte di un team. Deve quindi essere in grado di collaborare con i membri del team tramite l’ascolto attivo. Deve incarnare i principi Agili del rispetto della trasparenza e dell’apertura.
Product vision and product strategy
Il PO è responsabile di definire e comunicare la product vision. La product vision puo’ essere una semplice frase. In assenza di idee migliori, si puo’ usare il template seguente
for <someone>, who <customer need> <product name> is a <description> that <main benefit>. Unlike <competitor>, <main USP>.
Es: For people willing to travel to Mars, who need to travel safely, Marsplorer is a website that allows travellers know when a sand storm is coming. Unlike MarsBooking, Marsplorer accurately tracks sandstorms everyewhere on Mars.
Puo’ anche essere utile arricchire la product vision con una product vision board. La product vision board contiene queste sezioni:
- la product vision (vedi sopra)
- Target group: a chi serve il prodotto.
- Needs: bisogni del target group, problemi che il prodotto risolve.
- Product: caratteristiche del prodotto, USP, fattibilità.
- Business goal: obiettivi di business, come il prodotto porterà vantaggi all’azienda.
Un altro strumento per visualizzare la strategia è il product stategy canvas. Il product strategy canvas si compone di 4 parti:
- vision, comprensivo di orizzonte temporale
- challenge, obiettivo misurabile da raggiungere entro una certa data
- target condition, cosa fare per raggiungere l’obiettivo
- current state: stato attuale
un ultimo strumento è il business model canvas. Si compone di 9 sezioni, anche se ne esistono diverse varianti con sezioni in piú o in meno. Le sezioni sono:
- Customer segment: un po’ come la sezione target group del product vision board
- Value proposition: il beneficio atteso del prodotto. La ragione per cui il customer segment dovrebbe volerlo acquistare.
- Channels: quali canali verranno usati per comunicare la value proposition al customer segment.
- Customer relationship: descrive la strategia per tenere e incrementare la base di utenti. Ad esempio, contenuti di valore inviati gratuitamente.
- Revenue streams: freemium, subscription, etc…
- Key resources: persone, fondi, asset fisici necessari per mettere a terra il business.
- Key partners: chi sono i partner per questa impresa?
- Key activities: le attività principali.
- Cost structures: le voci di costo principali.
Product roadmap
Un altro tool utile per comunicare la strategia e l’obiettivo è la product roadmap. Una Goal Oriented Product Roadmap pone l’accento sugli obiettivi.
Ha una struttura matriciale in cui le colonne rappresentano i quarter o i mesi (o qualunque altra scala temporale significativa, purchè non troppo ampia). Le righe sono le seguenti:
- Name: nome della versione o dell’obiettivo
- Goal: obiettivo da raggiungere in quella iterazione.
- Features: features principali a supporto di quell’obiettivo.
- Measure: quali sono gli indicatori e quali sono i valori attesi che ci permetteranno di dichiarare l’obiettivo raggiunto.
I benefici di usare un roadmap sono
- Trasparenza
- Allineamento tra team e stakeholder
- Facilita il focus e le decisioni
Da notare che, sebbene la roadmap contenga l’indicazione delle features principali, essa non rimpiazza il backlog. E’ altrettanto vero che non tutto il contenuto del backlog deve necessariamente essere riflesso nella roadmap.
La roadmap non è un piano: il fatto che possa cambiare è un fatto atteso e benvenuto… è la norma.
Un altro strumento utile allo scopo di condividere obiettivi e roadmap sono il modello now-next-later, che ha peró il difetto di non dare risalto a metriche e obiettivi, limitandosi alla features. D’altra parte, tale modello non indica date, quindi evita il malinteso per cui una roadmap possa essere scambiata per un piano.
Da ultimo, la story map permette di focalizzare l’attenzione sulle user activities e task, derivando da esse il backlog.
Lettura suggerita: https://www.scrum.org/resources/blog/tips-agile-product-roadmaps-product-roadmap-examples
Value Driven Development
Il compito principale del PO è massimizzare il valore. Ma cosa è il valore? Possiamo definirlo come l’utilità, il beneficio che qualcuno trae. Per il PO, la definizione operativa di valore puo’ essere la seguente:
- Valore è il beneficio finanziario che l’organizzazione riceve
- Valore è il beneficio sociale che la società riceve (ad es, per non-profit)
- Valore è il beneficio che i clienti ricevono in termini di felicità
- Valore è il beneficio che i lavoratori ricevono in termini di felicità
L’unico modo di fornire valore è rilasciare all’utilizzatore. Un PO deve definire il valore e misurarlo frequentemente. Un modo per farlo è costituito dai KVI.
L’uso di customer personas e value proposition canvas pemtette di analizzare cosa significhi per il nostro target segment fornire valore.
Ciclo di vita del prodotto
Il modello tradizionale di ciclo di vita del prodotto prevede 4 fasi: introduzione, crescita, maturità, declino. Scrum e l’EBM legano le fasi del ciclo di vita ai 4 KVA:
- Current value
- Unrealized value
- Time to market
- Ability to innovate
In particolare, prodotti in fase di declino avranno un alto current value e un basso unrealized value. Questi prodotti vanno tenuti sul mercato fin tanto che generano profitto (definito come ricavi – costi), ma bisogna cercare nuove opportunità e non investire in essi. Una metrica utile è il product cost ratio, definito come rapporto tra costi e ricavi di un prodotto.
Il time to market si riferisce alla velocità di portare nuove cose sul mercato.
Strategie di prezzo
Freemium: si offre una versione gratis e una a pagamento con features aggiuntive.
Price skimming: in un mercato relativamente nuovo, in cui mancano alternative, si possono tenere prezzi alti. Quando le alternative arrivano, si abbassano i prezzi per impedire ai competitors di acquisire quote di mercato
Market penetration: per entrare in un mercato, si tengono prezzi bassi per acquisire quote.
Premium prices: si punta ad una clientela disposta a spendere per prodotti di qualità superiore.
Economy prices: si punta ad un segmento per cui il prezzo costitutisce un fattore di scelta importante.
I parametri per scegliere sono competitors pricing, market share, unmet needs e customer satisfaction.
Validation
L’ultima delle 3 V (value, vision, validation) indica la capacità di validare le proprie ipotesi di business rispetto al mercato. La preferred stance del PO deve essere quella dell’Experimenter, per verificare se esiste una domanda.
L’unico modo per arrivare a valirade le ipotesi è rilasciare degli esperimenti, degli MVP.
Non tutte le release sono uguali (major, minor, desirable, undesirable).
Product backlog management
Ogni item nel backlog è una product baclog item (PBI). Per scum, gli unici attributi obbligatori per un PBI sono la descrizione, l’ordine e le dimensioni.
Un PO deve valutare il valore, il costo e le dipendenze. Il costo deve considerare anche il fattore tempo. Per questo si parla di cost of delay.
E’ buona pratica scrivere gli acceptance criteria, anche se non è obbligatorio per scrum.
Contract types
Scrum puo’ funzionare sia con contratti fixed price che con contratti time & material… ma con i contratti fixed price è piú complesso. Perchè? I contatti fixed price partono dal presupposto opposto rispetto all’agile: che lo scope sia noto all’inizio. Qualora non si possa fare a meno di un contratto fixed price, conviene inserire della contingency sotto forma di sviluppatori aggiuntivi o di periodi di assestamento.
I contratti fixed price spostano il rischio sul fornitore, mentre quelli time & material lo spostano sul cliente. Un modo per mitigare il rischio per il cliente consiste nel mettere, ad esempio, un cap alla spesa massima per un contratto T&M.