Archivi tag: product owner

Impact Mapping per la pianificazione strategica

Di ritorno da un workshop di un giorno con Gojko Adzic ho deciso di raccogliere le idee e gli appunti sull’Impact Mapping, una tecnica di pianificazione strategica che mi sembra allo stesso tempo semplice e molto potente.

Che cos’è una impact map?

E’ una mappa mentale che rappresenta il percorso da uno specifico obiettivo di business alle azioni che consentono di raggiungerlo.
E’ una rappresentazione creata in maniera collaborativa dal business e dalla tecnologia ed ha il vantaggio di mostrare anche le assunzioni sottostanti.
Risponde a queste 4 domande fondamentali:

  • perché?
  • chi?
  • come?
  • cosa?

Perché stiamo facendo questo progetto?

Questa parte spiega qual è l’obiettivo che vogliamo raggiungere, aiuta a renderlo esplicito e patrimonio di conoscenza condivisa.
Spesso infatti gli obiettivi di business non sono esplicitamente dichiarati; a volte sono presenti solo nella mente degli stakeholder, a volte hanno una definizione troppo vaga.

Nell’immagine d’esempio l’obiettivo è uno: far crescere l’advertising mobile.

Priorità agli obiettivi, non alle funzionalità!

Se un progetto consente di raggiungere gli obiettivi di business è un successo anche se l’ambito è variato rispetto alla visione iniziale; viceversa se tutte le funzionalità individuate all’inizio vengono portate in produzione senza che l’obiettivo sia raggiunto il progetto è un fallimento.

Non dimentichiamo inoltre un consiglio sempre valido: formulare gli obiettivi in maniera smart (specifici, misurabili, orientati all’azione, realistici e collocati nel tempo).

Chi sono gli attori?

Chi sono i nostri utenti e come sono influenzati dal nostro prodotto?
Di chi vogliamo cambiare il comportamento?
L’Impact Map ci aiuta a focalizzare tutti coloro che influenzano le decisioni di prodotto, gli utenti e le varie tipologie di clienti.
Tiene conto degli attori primari (quelli per cui il prodotto soddisfa un bisogno), gli attori secondari (coloro che forniscono un servizio) e gli attori “fuori scena” che hanno un interesse ma non ricadono nelle due precedenti casistiche (i più rischiosi in termini di pianificazione perché prima o poi si risvegliano).

Nell’esempio riportato sono stati individuati 3 segmenti potenzialmente interessanti: i fan dotati di device mobili, gli organizzatori di concerti e infine agenti e promoter.

Come vogliamo modificare il comportamento degli attori?

Questo passo è il collegamento più importante tra l’obiettivo e il prodotto finale perché mette in relazione l’attore con l’obiettivo.
Definisce come vogliamo cambiare il comportamento degli attori.
Cosa vogliamo che inizino a fare, smettano di fare o facciano in maniera differente?
Gli impatti non sono funzionalità, sono appunto comportamenti.
Dobbiamo individuare quelli che sono più rilevanti per centrare l’obiettivo e – cosa importante – misurarli.

Meglio sottolinearlo: stiamo parlando di cambiamenti nel comportamento delle persone, non a livello dei sistemi!

E’ in relazione agli attori e agli impatti che andremo a definire le nostre priorità, non sulle feature.

Nell’immagine d’esempio sono stati riportati gli impatti che si vuole indurre nei fan: una maggiore frequenza di utilizzo del sito mobile, sessioni più lunghe ed una maggiore esposizione ai banner mobile.

Cosa?

Solo nell’ultimo passaggio parliamo di ambito e funzionalità, non prima.
Andremo a mappare i deliverable rispetto agli obiettivi di business.
L’Impact Map mette tutti i deliverable in relazione con gli impatti da produrre.
Mappare queste relazioni significa portare alla luce le assunzioni che abbiamo fatto.
Gojko sottolinea che questo è il livello meno importante della mappa. Non è necessario infatti che sia fatto tutto dall’inizio alla fine; i deliverable sono opzioni, mano a mano che verranno rilasciati saranno misurati gli impatti e si potrà decidere se proseguire nell’implementazione o dedicarsi ad altri obiettivi.

Ambito di applicazione

Le Impact Map possono essere applicate allo sviluppo di nuovi prodotti, all’evoluzione di prodotti esistenti e alla gestione della roadmap, purché ci sia accordo sul fatto che lo scopo finale è raggiungere l’obiettivo di business, non un set prestabilito di funzionalità.
Se un deliverable non produce cambiamenti pur funzionando correttamente è da considerarsi un fallimento.
L’Impact Map non si presta invece ad essere applicata in progetti di pura maintenance.

Quali vantaggi offre

La progettazione iterativa è spesso carente in termini di big picture.
L’Impact Map colma questa mancanza offrendo un contesto alla progettazione.

Ha il vantaggio di farci mantenere un focus forte e ci aiuta a prioritizzare, facilita la collaborazione e l’interazione oltre a rendere visibili le assunzioni.

E voi l’avete mai utilizzata? In quale contesto?

Il primo Product Owner della storia

In questi giorni sto leggendo il libro di Jeff SutherlandFare il doppio in metà tempo: Puntare al successo con il metodo Scrum“.
Il volume racconta in maniera discorsiva come attraverso varie esperienze personali e professionali Sutherland – il padre fondatore di Scrum insieme a Ken Schwaber – sia arrivato ad elaborare il famoso framework.

Non mancano aneddoti divertenti sui progetti più disparati salvati dall’adozione di Scrum (dai sistemi di antiterrorismo sviluppati dall’FBI, ai primi ATM, agli applicativi per la gestione delle ricette online, ma anche ristrutturazioni edilizie e matrimoni).

Una delle parti più interessanti per me è il racconto di come è nata la figura del Product Owner e come se l’è immaginata ai tempi l’autore.

Tutto sta a mettere in ordine di priorità il lavoro da fare.
Come si fa? Beh, per prima cosa vi serve qualcuno che sia in grado di capire contemporaneamente qual è la visione e dove sta il valore. In Scrum lo chiamiamo “Product Owner”.

Il Product Owner decide quale dev’essere il lavoro. Gestisce il Backlog, i compiti che include, e soprattutto l’ordine in cui vanno messi in atto.
Nel 1993, quando ho avviato il primo team Scrum, non avevo un Product Owner. Facevo parte del gruppo dirigente e avevo tante altre responsabilità oltre a quella di capire esattamente cosa doveva fare il team in ogni Sprint.
Mi occupavo del management e del marketing, trattavo con i clienti e definivo la strategia. Ma in quel primo Sprint ho capito che potevo anche gestire il Backlog. Dovevo solo fare in modo di avere abbastanza “storie” e abbastanza caratteristiche su cui mettere al lavoro il team nello Sprint successivo.
Il problema era che dopo il secondo Sprint abbiamo introdotto il Daily Stand-up. La velocità è aumentata del 400% nello Sprint successivo, e il team ha portato a termine in una settimana il lavoro che avevamo preventivato su un mese.
Non c’era un altro Backlog su cui metterlo al lavoro! Avevo pensato di avere davanti un mese per creare altre “storie”.
È un problema che vorrebbero tutti, bisogna ammetterlo, ma andava comunque affrontato. Quindi ho ideato il ruolo del Product Owner e ho cercato di capire che caratteristiche dovrebbe avere idealmente chi è chiamato a ricoprirlo.

Mi sono ispirato al Chief Engineer di Toyota
… ciò che non hanno [ i Chief Engineer] è l’autorità.
Nessuno riporta a loro, semmai sono loro che riportano ai propri gruppi.
I collaboratori possono dire ai Chief Engineer che sbagliano, perciò costoro devono accertarsi di aver ragione.
Non valutano la performance di nessuno, e non concedono né promozioni né aumenti, ma decidono la visione della nuova vettura, e stabiliscono come verrà costruita, con la persuasione, e non con la coercizione.
È questa idea che volevo incorporare in Scrum.

Già agli albori di Scrum sapevo di aver bisogno di qualcuno che conoscesse molto bene il cliente.
Il Product Owner doveva essere in grado di riportare al team il feedback del cliente a ogni Sprint. Doveva dedicare metà del proprio tempo a parlare con le persone che acquistavano il prodotto (ascoltandone le opinioni sull’ultima release incrementale e su come creava valore), e l’altra metà a sviluppare il Backlog con il team (spiegando ai suoi membri cosa apprezzavano e cosa non apprezzavano i clienti).
Ricordatevi che il “cliente” potrebbe essere il consumatore in generale, una grande banca, vostro marito o chi ha bisogno del vaccino contro il rotavirus e dipende da voi per ottenerlo. Il cliente è chiunque tragga valore da ciò che fate.
Però non volevo un manager. Volevo qualcuno in cui il team credesse e di cui potesse fidarsi quando metteva in ordine di priorità il Backlog. Perciò sono andato a prendere il più bravo di tutti nel product marketing; attenzione, non nell’engineering, ma nel marketing. Ed è così che Don Rodner è diventato il primo Product Owner.
Conosceva il prodotto che stavamo sviluppando non da un punto di vista tecnico – pur sapendone abbastanza da poter comunicare con gli ingegneri – ma piuttosto dal punto di vista del cliente.
Di che cosa avevano bisogno coloro che usavano effettivamente il prodotto? Quando siete alla ricerca di un Product Owner, scegliete qualcuno che sia in grado di mettersi nei panni di chiunque tragga valore da ciò che fate.

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.