Mi scrive un responsabile marketing criticando il testo di una email. Il testo esprimeva perfettamente i concetti che volevo comunicare e la visione con cui ho pensato questa campagna marketing era perfettamente descritta dalla email che il team (nella persona del content designer) aveva creato. Quella che non era piaciuta era la forma, le espressioni usate, le singole parole.
Qualche giorno prima e in maniera analoga mi era stata contestato il colore di uno sfondo.
La mia posizione in questi casi è un po’ imbarazzante perché a una prima osservazioni sa molto di allontanamento delle responsabilità; infatti in questi casi sono costretto a ricordare che il Product Owner si occupa esclusivamente di cosa viene sviluppato e su questo ha totale autonomia di scelta ma, una volta fissati i criteri di accettazione della storia (acceptance criteria) e i criteri generali di accettazione di un rilascio (definition of done e non functional requirements), non osa mai spingersi nella valutazione (tanto meno nella validazione) del come una cosa viene fatta, dando per scontato uno dei principi fondamentali dello Scrum: l’intelligenza collettiva di un team che rilascia una feature è superiore all’intelligenza di una singola persona, fosse anche il Product Owner.
Che sia vero o falso è poco rilevante, questa è la regola del gioco dello Scrum che io ho accettato in tutti i suoi aspetti, cambiando di fatto la mia professionalità da Project Manager a Product Owner. Rispetto al passato ho perso senza dubbio tanta decisionalità sulla qualità e sul modo di esecuzione, avendo però acquisito un margine enorme nella scelta di quali feature rilasciare e quando rilasciarle, all’atto pratico una vera carta bianca su decisioni strategiche che mi erano state sempre occluse o almeno limitate, in quanto ogni scelta doveva essere condivisa da una tale pila di persone da rendere nei fatti praticamente impossibile i cicli di build-measure-learn.
Dall’altro lato ho visto nascere nei team una entusiasmante (e in certi casi insospettabile) professionalità, i tecnici sono saliti dalla sala macchine e hanno visto in cosa si trasforma il loro prodotto, anzi di più, hanno virtualmente incontrato i clienti che usano il prodotto che loro hanno creato.
Ho abbastanza fiducia in questo sistema da trovare le parole giuste per spiegare la differenza tra il ruolo di un Product Owner e quello di un Project Manager.
Tag Archive for product ownership
Product Owner vs Project Manager
Apologia del fallimento
In Italia il termine fallimento, che già tradizionalmente era associata a concetti come sconfitta e irreparabile tracollo, in questi anni di crisi ha acquisito una accezione a dir poco sinistra, istintivamente associata alla perdita di tutti i diritti e al dramma del suicidio.
Forse è una leggenda l’idea che, come mi riportò un italiano che viveva negli States, oltre oceano il fallimento sia vissuto come una prova di coraggio, un grado del valore di un imprenditore, al punto da poter dire che chi fallisce più volte è uno in gamba, uno che ci prova.
Di certo l’idea che abbiamo in Europa del fallimento non trova un corrispettivo nell’approccio pragmatico del mondo anglosassone, dove il solo fallire non può essere giudicato senza verificarne i costi e gli effetti.
Fallire presto.
Fallire a poco costo.
È questo il punto.
Le metodologie Lean e Agile mi hanno insegnato tanti valori che non sempre sono stato pronto ad acquisire ma di uno di essi sono certo: imparare a fallire il prima possibile e usare le metriche in maniera oggettiva per capire quando andare avanti o quando tornare indietro.
Ho seguito uno webinar sull’approccio lean startup presentato da Francesco Fullone di Ideato. Uno dei concetti che mi ha attirato è stato quello di invalidazione associato al validate learning.
Faccio un passo indietro: già Ries metteva in guardia dall’innamoramento verso una value proposition, e come potrebbe essere altrimenti? Ho avuto una idea, me la sono curata, coltivata, amata, finalmente l’ho applicata e infine l’ho fatta passare al setaccio delle metriche, come potrei a questo punto rinnegarla? A meno che le metriche non siano così esplicite da non poter essere ignorate per lo più avverrà che, istintivamente, si sarà portati a minimizzare i valori che smentiscono l’idea e a dare importanza a quelle che invece la confermano. Questa, secondo Ries, è una delle peggiori trappole in cui può cadere un imprenditore come un product owner, con la conseguenza di ritardare a volte fatalmente il momento in cui si decide che l’idea non è corretta e si fa dietro front.
Torniamo alla invalidazione: invalidare significa assumere un atteggiamento contro ogni logica massacrando la propria idea, cercando in tutti i modi di rinnegarla e dimostrandone la mancanza di valore. Così come nelle teorie su cui si fonda il testing, se l’idea infine passa l’invalidazione potremo affermare che essa è certamente valida. Metodo scientifico.
Difficilissimo!
Chi non vorrà dare almeno una piccola chance alla propria idea, sperando che le sue debolezze dipendano dalla giovane età?
Se cambia il Product Owner
Conoscete le tabelle dei parametri di compensazione da applicare in caso di ingresso di un nuovo team member? Se entra nel team un nuovo sviluppatore, applicare un moltiplicatore di 1,2. Se lo sviluppatore non ha conoscenza di dominio, moltiplicare per 1,5.
Non esistono tabelle per il cambio di Product Owner. Forse per pura scaramanzia, perché alla fine tutti sanno che il moltiplicatore in caso di PO sarebbe costoso e molto, molto proporzionato alla effettiva capacità del PO.
Questo è in effetti ciò che è accaduto nella mia azienda: una nuova posizione da ricoprire ha richiesto una serie di cambiamenti a catena, tra cui la mia sostituzione alla guida del primo prodotto (fase 1) e il mio successivo ingresso alla guida di un prodotto totalmente diverso (fase 2).
La fase 1 prevedeva l’ingresso di un manager tecnico, con una lunga esperienza di gestione delle piattaforme su cui il mio primo prodotto in parte si basava; in altre parole, grande conoscenza del dominio, poca conoscenza degli aspetti commerciali e nulla della metodologia e del suo nuovo ruolo.
Nel corso del primo sprint abbiamo iniziato un generico passaggio di informazioni, nella pratica una serie di incontri lunghi e faticosi nei quali raccontavo gli aspetti diversi del prodotto. Guardavo il collega come se avessi guardato una persona in procinto di affogare, non potevo aiutarlo ma contavo nella sua capacità di nuotare; gli rovesciavo addosso tonnellate di parole e materiali, incroci e matrici di variabili che a me erano familiari ed elementari fino a quando non avevo dovuto spiegarli. Sapevo che di tutte quelle informazioni il nuovo PO avrebbe ben recepito un 30%, e forse un altro 30% sarebbe caduto dimenticato ma sarebbe riemerso al momento giusto, magari supportato da qualche appunto, e infine un’ultima parte sarebbe stata reinterpretata, riadattata o forse dimenticata del tutto.
Se potessi dar(mi) dei consigli retrospettivi proporrei:
1. è la grande occasione per rifare un MOSCOW di quanto fatto e da fare; potrebbe essere sorprendente scoprire quanti precedenti MUST fossero in realtà legati a qualche personale crociata e perdano di priorità nel momento in cui vengano filtrati dalla visione di un altro PO
2. sarà la prova del nove di quanto siamo stati bravi a pubblicare e condividere le informazioni di base, le analisi più rilevanti, i progetti: se siamo costretti a inviare attachment più che link a un vostro repository, wiiki o altro, non è buon segno
3. una delle pagina del repository deve essere: contatti e persone rilevanti, mailing list e processi ricorrenti di comunicazione
4. un’altra delle pagine dovrà essere: vision di prodotto e ipotesi di sviluppi per il futuro
A valle di questa prima fase di condivisione abbiamo speso tre sprint per l’affiancamento: nel primo sprint io continuavo nel mio ruolo di PO in toto, l’altra persona partecipava passivamente; nel secondo le cerimonie operative (planning, review) erano ancora gestite da me mentre gli incontri di grooming dello sprint successivo erano già seguiti da lui, che così iniziava a calarsi nella nuova realtà; nel terzo sprint infine il nuovo PO prendeva ufficialmente le redini del prodotto, solo momentaneamente affiancato in maniera passiva da me.
Alla fine del terzo sprint ho scritto una email di saluti agli stakeholder (simbolica, molti di loro sarebbero stati rimasti per il nuovo prodotto), era un atto dovuto che ha avuto la forza di una cerimonia di chiusura di un’era.
Pochi giorni dopo entravo nella fase 2 spostando le mie cose e sedendomi al mio nuovo posto. Ero un po’ nervoso e lo ammettevo chiaramente, in fondo si lavorava con le persone e i ragazzi che ho davanti sono probabilmente il miglior team di sviluppo dell’intera azienda, non ho dubbi che dovrò lavorare per dimostrami alla loro altezza prima di tutto proprio ai loro occhi. Inizio rassicurando il mio team che non amo le rivoluzioni e i tagli netti, che tutte le trasformazioni saranno dove saranno necessarie e nei tempi che le renderanno sostenibili.
Il processo inverso segue più o meno gli stessi passi della fase precedente, inizia con un primo periodo di passaggi di consegne molto complesso e articolato durante il quale la legge del contrappasso mi fa passare dal medesimo purgatorio di cui io ero stato l’aguzzino pochi sprint prima.
Poi, le altre fasi che vedono una mia presenza sempre più forte nell’attività del team.
Naturalmente, mi calo completamente nel ruolo solo il giorno in cui il precedente PO passa alla sua nuova attività.
Nel giro di due sprint inizio ad avere i primi scontri con la realtà. Alcuni dei modelli che, devo ammetterlo, mi rendevano maledettamente sicuro, saltano di fronte alla inapplicabilità in questo nuovo contesto, a riprova del fatto che una metodologia è elastica fintanto che resta a livello di framework, ma diventa un esoscheletro troppo stretto quando viene applicato come un set di esperimenti e regole fisse.
Ho idea che questa differenza sia proporzionale non tanto alle differenze tra i due team, che in qualche modo sono livellate dalla aderenza alla metodologia Scrum, quanto alla distanza tra i due prodotti.
Il prodotto 1 è un prodotto high end, pochi clienti, per lo più reseller o corporate, con alta capacità di spesa e per lo più con notevole competenza tecnica, sufficiente per lo meno ad aiutarli a valutare un investimento abbastanza consistente.
Il prodotto 2 è esattamente l’opposto: generalmente considerato un prodotto entry level, di utilizzo semplice e costo molto ridotto (da 1/100 a 1/1000 del costo di prodotto 1), fa i suoi numeri grazie all’enorme quantità di vendite; l’utenza è ovviamente la più varia possibile, le cui competenze tecniche possono essere da nulle a molto avanzate.
Questa enorme differenza tra prodotti e soprattutto utenze mi disorienta e mi obbliga a rivedere molti de metodi di approccio.
Qualche esempio.
Sono abituato a estrarre statistiche abbastanza significative delle richieste al supporto tecnico del prodotto 1 prendendo un campione di circa una settimana: nel nuovo prodotto lo stesso numero di richieste arriva in alcune ore e dipende da variabili spesso molto localizzate (orario di attività, problemi momentanei anche limitati, etc.)
Sono abituato a chiamare alcuni clienti, a campione, intervistandoli sulle loro esigenze e traendone spunti importanti: nel nuovo prodotto i clienti sono svogliati, per niente interessati a dirmi i loro problemi, e generalmente poco interessati a partecipare allo sviluppo di prodotto; la loro aspettativa è: tu fai il prodotto come o meglio dei concorrenti, poi giudicheremo noi.
D’altro canto sono abituato a trarre dati poveri e contrastanti dalle analisi di traffico e di comportamento del cliente: stavolta i numeri enormi che mi trovo a manipolare mi consentono di fare delle proiezioni sicure come fossero analisi a posteriori.
La morale dell’esperienza è stata dunque che cambiare il product owner ha un impatto enorme sulla continuità del team e dello sviluppo di prodotto. Non è passato molto prima che abbia iniziato a dirigere lo sviluppo di prodotto secondo la mia personale visione, in parte molto diversa dalla precedente: il team ha spesso accusato questo cambio di direzione ma purtroppo è un effetto collaterale irrinunciabile visto che, in fin dei conti, il mio ruolo esige che il nuovo prodotto diventi il mio prodotto.
Incontrare chi investe in noi
Con il termine stakeholder si intende uno sponsor del progetto che il Product Owner sta seguendo, un super cliente interno all’azienda o comunque uno di quelli che, sul vostro progetto, ci mette il soldo.
Già da questa definizione si capisce che uno sbadiglio del vostro stakeholder è peggio di una critica del vostro capo: non avete interessato il vostro investitore, non lo avete eccitato con quello che avete rilasciato.
Male.
Da lì in poi la situazione è tutta in salita, ma recuperabile.
Ci sono fior di capitoli dedicati al coinvolgimento dell’investitore, dai piccoli dettagli dei pasticcini offerti in review agli incontri one to one di preparazione e di retrospettiva di ogni review: ho scoperto quanto gli investitori siano timidi e quante cose emergano da incontri personali (“volevo dirlo in review, ma non me la sentivo in inglese”, “non volevo che il mio commento portasse alla bocciatura della user story”, “mi scocciava fare una critica in pubblico”).
Io spendo decine di ore in incontri con i miei stakeholders e non sembrano mai bastare; se l’investitore tiene davvero ai propri soldi non sarà mai sazio di incontri e presentazioni personalizzate e revisioni del planning e dei rilasci.
Non si tratta di una mera attività diplomatica: è uno scambio nelle due direzioni, un processo per rendere permeabile quella membrana di diffidenza o timidezza che altrimenti sarebbe impermeabile.
Un’altra tecnica scaccia-timidezza si basa sui feedback anonimi.
Le nostre review attualmente si chiudono sempre con un survey inviato alla lista degli stakeholder. Il survey è anonimo e brevissimo (4 domande, con risposte multiple, e campi di testo solo per chi vuole aggiungere qualcosa).
Allo stakeholder è richiesto un breve giudizio sulla qualità della review, in termini sia di comunicazione che di contenuti espressi, quindi viene chiesto l’argomento preferito, e infine si entra nel dettaglio del rilascio più importante, chiedendo il grado di apprezzamento del prodotto ed eventuali commenti.