I migliori libri per Product Owner: Lean Startup

Il 2011 per me è stato davvero un anno di svolta.
E’ l’anno in cui ho scoperto l’Agile e ho preso parte ad un primo pilot nella mia azienda di allora (Matrix!). Sarà per questo che sono così legata al libro di Eric Ries?
Lean Startup” è uscito nello stesso anno e per me è stato davvero una rivelazione… uno di quei libri che ti aprono un mondo. L’ho letto e riletto più volte, consumato di note e regalato con gioia.

Racconta per filo e per segno qualcosa che ai tempi avevo solo intuito durante il mio percorso professionale ma non ero mai riuscita ad articolare così chiaramente.
Ries lo fa con una leggerezza, una facilità e una trasparenza senza eguali.
Ecco perché ho deciso di partire da questo volume per inaugurare una nuova serie di post: “I libri migliori per Product Owner”.

Il libro parla del mondo delle startup (come è intuibile dal titolo), ma i principi ed i suggerimenti che contiene sono dal mio punto di vista preziosi in qualunque contesto di mercato.
Questo volume ha proprio cambiato il mio modo di pensare; mi ha illuminato con un metodo che applico istintivamente a tutti i progetti in ambito professionale e tendo a far sconfinare anche al di fuori del lavoro.

Sono 5 i concetti-chiave che mi hanno più influenzato come Product Owner e voglio ripercorrerli con voi uno ad uno. Parliamo di flessibilità, apprendimento validato, Minimum Viable Product, cicli di feedback e metriche di qualità.

Rimani flessibile

Le startup a differenza delle aziende consolidate non possono prevedere il proprio futuro perché non hanno passato e non sanno (ancora) quali sono gli approcci migliori per trovare clienti o creare un’attività sostenibile.
Per scoprire cosa potrebbe funzionare, devono rimanere flessibili. Nel loro caso adottare piani fissi con traguardi prestabiliti o fare affidamento su previsioni di mercato a lungo termine significa illudersi. Perché gestire una start-up è come guidare una jeep su un terreno accidentato: i fondatori devono costantemente cambiare direzione e rispondere rapidamente a ostacoli imprevisti e vicoli ciechi.

Come Product Owner tendo a storcere il naso quando sento parlare di roadmap “annuali” e di pianificazioni che vanno oltre i 6 mesi. Non fraintendetemi: ha tutto il senso del mondo definire degli obiettivi di business annuali o pluriannuali ma non credo che il percorso su come raggiungerli (la roadmap appunto) sia scritta sulla pietra.

Oltre l’orizzonte temporale di metà anno tutto ciò che viene dichiarato è potenzialmente soggetto a cambiamento per motivi interni ed esterni all’azienda (nuove opportunità di mercato, la necessità di rispondere alle mosse di un competitor, una ripianificazione delle priorità a fronte di determinati risultati).
Posso immaginare che nell’edilizia la pianificazione di un complesso sia un progetto che è meno soggetto a fluttuazione ma nel mondo digitale 6 mesi sono un periodo lungo in cui lo scenario può essere stravolto anche sono dall’evoluzione della tecnologia stessa.
Per questo motivo come Product Owner evito di fare piani dettagliati che vadano oltre i 6 mesi e per periodi successivi mi limito ad indicare una serie di temi (di alto livello) che saranno oggetto di sviluppo, ma che possono essere riconsiderati periodicamente strada facendo.

Rimanere flessibile mi consente di cogliere opportunità più interessanti che si presentano lungo il percorso e che non erano previste in fase iniziale o di riconsiderare le mie priorità se nuovi dati le mettono in discussione.

Non dare per scontato il valore

L’obiettivo principale di qualsiasi startup è trovare un modello di business redditizio e sostenibile.
In pratica, questo significa scoprire quali prodotti desiderano i potenziali clienti e come trasformare i loro desideri in ricavi costanti.

Alla base di ogni prodotto esistono infatti due presupposti fondamentali: l’ipotesi del valore e l’ipotesi di crescita.
L’ipotesi del valore presuppone che un prodotto fornirà valore ai propri clienti, ovvero che i primi utilizzatori troveranno e abbracceranno il prodotto.
L’ipotesi di crescita afferma che il prodotto non solo piacerà alla nicchia degli early adopters, ma troverà anche un mercato più ampio in seguito.

E’ importante comprendere che questi concetti sono ipotesi e come tali devono essere testate e convalidate parlando con i clienti. Solo in questo modo sapremo di essere sulla strada giusta per trovare un modello di business sostenibile.

Come Product Owner non posso dare nulla per scontato, anche che ciò che l’azienda ritiene sia di valore per il cliente finale. Ho spesso sperimentato che le società affermano di conoscere il loro pubblico ma presumono, a volte dimostrano anche una certa arroganza nel pretendere di sapere a priori ciò che vogliono i clienti, ma la verità è che fino a quando un prodotto non va in mano ad un utilizzatore finale non saprai mai quanto piacerà e come verrà utilizzato.

Sapete come si dice? Customer is king! Quindi la cosa più di valore che posso fare per assicurare il successo di un prodotto è lasciare da parte il mio “corporate ego”, rimanere umile, approcciare il cliente ed ascoltarlo. Tutto il resto è presunzione!
Se avete bisogno di indicazioni pratiche su come farlo le trovate in questo post dedicato alle 15 domande per costruire le Personas.

Testa le idee con esperimenti

Come si possono mettere alla prova le idee di valore e di crescita? Semplice! E’ necessario formulare ipotesi su se e come determinati prodotti avranno successo in un particolare mercato.
E’ stato questo il caso di Zappos che, prima di lanciare il suo business in rete e ben prima dell’acquisizione da parte di Amazon, ha testato l’assunzione più rischiosa di tutto il suo modello di business: “i clienti statunitensi saranno disposti ad acquistare scarpe online”.

Nick Swinmurn – fondatore dell’azienda – l’ha fatto nel 1999 creando una versione minima del prodotto (MVP), ma minima davvero. Ha rilasciato un sito “civetta”, il front-end di un negozio di scarpe online senza che esistesse alcun tipo di back-end, di infrastruttura dietro o di magazzino. Ha evaso i primi ordini acquistando e spedendo le scarpe precedentemente fotografate direttamente nei negozi.
Questo MVP gli ha permesso di verificare che l’idea di business iniziale era valida.

Sono tristemente consapevole di quanto il concetto di MVP nelle aziende digitali sia stato scarsamente compreso, spesso osteggiato e molto vituperato (… a quanto pare oggi “fa più figo” parlare di Minimum Lovable Product).

Non entro in questa polemica che richiederebbe un post a sé, ma mi preme sottolineare il principio che ne sta alla base: quando non si è ancora trovato il product/market fit, quando il valore è ancora solo un’ipotesi il MVP dovrebbe essere il più semplice possibile e contenere solo ciò che è necessario per offrire ai clienti un’esperienza realistica di come funzionerebbe il prodotto. Serve solo quanto basta per trarre utili feedback!
Qui trovate uno strumento che potrebbe supportarvi nel creare esperimenti Lean.

Diverso è il caso di un prodotto consolidato che viene riproposto in una nuova veste o riaggiornato. In questo caso il “minimum” accettabile dal cliente non è meno delle funzionalità già presenti nel prodotto. In ogni caso questo approccio può tornarvi molto utile per evitare eccessivi sviluppi upfront o gold plating.

Costruisci – Misura – Impara

Ries si sofferma a lungo sui benefici del ciclo Build – Measure – Learn (BML) in Lean Startup.


Come funziona? Si costruisce una versione semplice del prodotto, come un prototipo o uno smoke test, lo si porta sul mercato e si raccolgono i feedback dei clienti.
Con i dati quantitativi di questo esperimento si misura l’interesse per il prodotto, nel caso di Zappos quante persone hanno cliccato sul pulsante “buy” e hanno provato ad acquistare scarpe dal negozio fake.
Ciò che si impara in un ciclo completo viene utilizzato per ottimizzare il prodotto che nella versione migliorata fa partire il successivo ciclo BML.
Ci sono due aspetti importanti qui: la velocità del feedback loop è fondamentale e un prodotto non è mai finito al primo rilascio!

Personalmente credo molto nel feedback loop (e non solo in ambito digitale!).
Questo è l’approccio corretto non solo per il lancio di un nuovo prodotto, ma per qualsiasi ottimizzazione vogliate fare.
Costruite un MVP o una nuova funzionalità o una nuova interfaccia, la mettete nelle mani di clienti reali e analizzate quanto e in che modo il prodotto cambia i loro comportamenti.
Se non misurate i risultati non avete modo di imparare alcunché!

Allo stessa stregua come Product Owner utilizzo estensivamente gli esperimenti per testare varianti del mio prodotto. Gli A/B test e in generale tutti i test dai più semplici ai più complessi dovrebbero essere il pane quotidiano per chi lavora in ambito prodotto.
Anche quando avete raggiunto una buona conoscenza del target e del mercato scoprirete che i test riusciranno sempre a stupirvi. I risultati inaspettati sono all’ordine del giorno.

Cerca le metriche giuste

Definire le metriche corrette da monitorare e valutarle con costanza è fondamentale per qualsiasi startup… e per qualsiasi prodotto aggiungo io!
Solo quando vediamo i KPI di riferimento migliorare sappiamo di essere indirizzati verso il raggiungimento degli obiettivi a lungo termine.
Ovviamente queste metriche possono variare – e di molto – da business a business, quindi non esiste una formula magica che possa valere per tutti.

Le metriche “giuste” sono quelle che ci consentono di capire se stiamo andando nella giusta direzione. Eric Ries sottolinea come molte startup cedano alla tentazione di utilizzare “vanity metrics”, metriche lusinghiere ma inutili o addirittura dannose che fanno sembrare un’azienda buona ma non aiutano ad avvicinarla ai suoi obiettivi.
E’ fin troppo facile farsi lusingare da tanti like su Facebook: possono essere fonte di gran soddisfazione ma questi apprezzamenti non pagano gli stipendi e non rappresentano in alcun modo un modello di business sostenibile.

Come Product Owner è mia responsabilità capire quali sono le metriche più adatte per misurare le specificità del mio prodotto. Senza dati sono totalmente cieca.
Posso avere delle intuizioni circa la strada da intraprendere, posso aver collezionato feedback dai miei utenti, ma ho in ogni caso bisogno di dati quantitativi affidabili per prendere delle decisioni informate e giustificarle agli occhi degli stakeholder.
I dati mi aiutano ad eliminare sul nascere qualsiasi guerra di opinione.

Conclusione

Le startup utilizzano un approccio semi-scientifico per testare le loro ipotesi di base e costruire un modello di business sostenibile sulle ipotesi convalidate.
Io Product Owner posso trarre vantaggio dal metodo Lean Startup decidendo di sviluppare rapidamente prototipi di prodotto e perfezionandoli continuamente attraverso il feedback dei clienti. Eseguendo cicli di costruzione, misura e apprendimento (BML) incremento significativamente le possibilità di successo del mio prodotto.

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”.


Backlog declutter 2: come mettere ordine tra le user stories

Come scegliere i requisiti da tenere seguendo il criterio della felicità… dei clienti!

Questa è la seconda parte di un post dedicato al declutter del backlog.
Qui, se ve la siete persa, trovate la prima parte.

Ci siamo lasciati parlando di user stories che hanno campeggiato troppo a lungo nel product backlog senza mai essere state portate in priorità. 
Vediamo quali altri casi sono buoni candidati per l’eliminazione.

Le user stories che ho nel mio backlog  hanno individuato un soggetto reale?
Stiamo parlando di persone o di moduli?
Si tratta di un’attività di valore?
Abbiamo individuato un reale bisogno o solo una soluzione tecnica?
Queste storie sono ottimi spunti per fare pulizia.
E poi la coerenza con la strategia generale. Potremmo avere in realtà degli item così vecchi che sono ormai superati perché le strategie aziendali hanno preso una direzione differente.

Sono tutte considerazioni che possiamo fare.
Non temete di eliminare troppo, non rimarrete mai senza nulla…
Se invece vi sentite sopraffati dall’impresa non scoraggiatevi. 
C’è sempre chi ha affrontato di peggio, come nel caso di una transizione a LESS in cui si è passati da 508 item a 23 user stories. Qui probabilmente si erano spinti un po’ troppo in là con la granularità, però è un buon esempio del fatto che è possibile fare un’operazione significativa di pulizia. 
Come? Seguendo gli step che stiamo percorrendo noi… hanno fatto un lavoro colleggiale, hanno stampato tutti gli item e li hanno classificati, che è esattamente il passo successivo.

Adesso con tutte le card davanti a noi concentriamoci su quali criteri utilizzare nel processo di eliminazione.

Categorizzare le user stories

Per fare ordine dopo la fase dell’eliminazione si passa al categorizzare. 
Riordinare per categoria è un altro principio cardine nella gestione del clutter fisico. 
Non si riordina stanza per stanza ma categoria per categoria: vestiti, libri carte, ricordi.
Andremo a individuare delle categorie e a classificare gli item uno alla volta. 
Ognuno di voi dovrà trovare il criterio che meglio si adatta al proprio caso. 

Ecco qualche idea: categorizzate per epiche, step dello user journey, impatti, stakeholder o obiettivi di business. Potete focalizzarvi sul contenuto, sul valore, sugli interlocutori e molto altro. 
Il mio consiglio fondamentalmente è di provare varie classificazioni e vedere quella che meglio si adatta al vostro caso. Personalmente ho iniziato utilizzando gli step del processo poi mi sono resa conto che non era esattamente ciò di cui avevo bisogno, era troppo vincolante mentre mi sono trovata molto meglio con quelli focalizzate sulla parte dei contenuti.

Mettere a confronto

Una volta che siete riusciti a categorizzare le vostre storie dovete fare un lavoro all’interno di ognuna di queste categorie e procedere per confronti.
In sostanza avete definito dei sotto raggruppamenti nel backlog e in ognuno di questi fate un lavoro di prioritizzazione.
Potreste scoprire anche in questa fase che qualcosa può essere ancora eliminato. Ad esempio se provassimo a vedere ognuna di queste categorie attraverso il principio di Pareto qual è il 20% delle user stories che producono 80% del valore?
Quali sono dei must? Quali should o could?
Siamo in grado di individuare i must-have per gli utenti e quelle storie che invece possono fare la differenza ed essere dei delighters?
Trovate il focus!
Provate a riconsiderare ognuna di queste categorie sulla base di varie tecniche di prioritizzazione. Più una… che ho tenuto a parte.

La felicità come criterio di scelta

Questa è un’idea mutuata proprio dal declutter: non dovremmo scegliere che cosa buttare bensì scegliere cosa tenere. E il criterio in questo caso è conservare solo ciò che ci rende felici, che ci fa sentire bene, che ci risuona emotivamente.
Non voglio prendere una deriva new-age fricchettona, dico solo che questa idea può essere trasposta nella gestione del backlog.
Quanta felicità una determinata storia porta ai nostri utenti?
In una scala di felicità siamo sicuri che l’ordinamento che ci siamo dati sia quello corretto? Riesco a produrre un impatto significativo nei miei utenti?

Continuare a prendersi cura

Bene una volta che abbiamo fatto questo repulisti, abbiamo organizzato i nostri item per categorie e abbiamo dato anche un ordine di priorità guardiamo con un occhio più attento ogni singolo elemento che abbiamo conservato.

Dobbiamo verificare che sia tutto effettivamente in ordine. Andare a vedere se ognuno di questi item che abbiamo conservato è completo, ha la struttura corretta, se abbiamo individuato realmente chi sono gli interlocutori e quali sono i loro bisogni.
E capire se sono coerenti con lo scenario attuale.

Una delle cose che si possono fare è focalizzarsi sulla prossima release di prodotto e cercare di associare al backlog una roadmap di prodotto per gli sviluppi più avanti nel tempo. 
Anche qui facciamoci delle domande per verificare che effettivamente quello che abbiamo conservato sia in buono stato: abbiamo tenuto conto di tutti gli interlocutori?
Abbiamo individuato bisogni espliciti ed impliciti?
Tutto questo è coerente con la strategia più generale?

Dopodichè non ci resta che…

Evitare le ricadute

Bisogna evitare di tornare nella situazione dalla quale siamo partiti. Come possiamo farlo? Dobbiamo avere attenzione nei confronti di ciò che a questo punto entra all’interno del backlog. E qui possiamo cogliere diversi spunti.
Diamoci una finestra temporale. In un armadio teniamo i vestiti per la stagione in corso, perché non nel backlog?
Facciamo in modo che il nostro backlog sia focalizzato sui prossimi tre mesi massimo sei mesi magari.

Utilizziamo un criterio che definisca esattamente che cosa è pronto per il backlog e tutto quello che non lo è può essere inserito in una sorta di waiting box / may be box (un contenitore dove inseriamo tutta una serie di buone idee da cui potremmo andare a pescare successivamente).

Teniamo sott’occhio la ratio delle cose che entrano ed escono oppure diamo un limite esplicito al nostro backlog. Alcuni ad esempio si impongono una certa soglia oltre la quale non andare proprio perché appunto la visione complessiva del backlog si sfilaccia.

Vedere l’ordine

Un altro suggerimento che potrebbe esservi d’aiuto nel mantenere l’ordine è tenere sotto controllo il backlog utilizzando diverse modalità di visualizzazione.

Chi ha letto il libro di Marie Kondo sa che uno dei consigli più preziosi e totalmente controintuitivi è disporre gli indumenti nei cassetti in un modo diverso che uno sopra l’altro bensì in verticale.


Questa idea mi ha fatto riflettere e mi sono resa conto che a volte siamo troppo condizionati dalla strumento che utilizziamo per gestire il backlog.
Proviamo ad andare oltre jira e tool simili che mostrano il backlog come una lunga lista di item.
Vi invito a sperimentare modalità alternative che tengano conto non solo della quantità ma anche del contenuto del backlog.

Non voglio sapere semplicemente quanti item ho ma vorrei capire anche meglio come sono distribuiti sui vari contenuti.
Ricordate le categorie di cui abbiamo parlato prima? Voglio capire che tipo di gerarchia esiste tra i vari elementi, voglio avere più visibilità delle connessioni, voglio vedere la granularità. 

Qui le possibilità sono svariate: dal classico backlog analogico su parete, alla modalità story mapping, mappe mentali e mappe ad albero.
In questa presentazione potete vedere i vari spunti che ho solo raccolto alcuni spunti ma sono curiosa di capire se voi ne vedete altri o ne avete magari già utilizzato alcuni che ritenete particolarmente efficaci.