Tag: build – measure – learn

Pubblicato il

Comunicare con gli stakeholder è un must

Se mi chiedessero di elencare le 5 cose più importanti che ho imparato in anni di lavoro nel Prodotto uno degli aspetti che menzionerei sarebbe sicuramente comunicare con gli stakeholder.
Non ribadirò mai abbastanza l’importanza di questa pratica.
E per stakeholder intendo proprio tutti gli stakeholder, interni ed esterni così come li abbiamo definiti quando parlavamo di mappatura.

Diciamo che abbiamo fatto i compiti a casa, ci siamo presi il tempo di intervistare le persone che a vario titolo sono interessate o influenzate dalla realizzazione del nostro prodotto, abbiamo compreso il loro punto di vista e le loro aspettative e quindi abbiamo gettato le basi per una relazione efficace.

Adesso si tratta di passare alla fase successiva, all’atto: ciò che ti serve è una strategia di comunicazione con i tuoi stakeholder.

Perché serve un piano di comunicazione

Partiamo da un presupposto: più è grande l’organizzazione di cui fai parte e più persone saranno influenzate dal tuo prodotto.
Se parli con ognuno degli interessati dovendo ripetere sempre le stesse informazioni perdi un sacco di tempo e rischi di non ricordare esattamente cosa hai detto a chi.
Ecco perché serve un piano.

Non è tanto importante quale tipo di formalizzazione decidi di adottare, ciò che conta davvero è che tu abbia chiaro:

  1. chi ha bisogno di quali informazioni
  2. quando ne hanno bisogno
  3. quanto frequentemente si aspettano di essere aggiornati
  4. come preferiscono ricevere le informazioni
  5. in generale come puoi massimizzare efficienza e chiarezza

Diciamo che se hai condotto un’attività di mappatura degli stakeholder e li hai intervistati dovresti avere chiari i primi 4 punti.

Essere intenzionali e consistenti

Questa è la chiave della comunicazione con gli stakeholder: essere intenzionali.
Decidere a priori quando avverranno i meeting, quali comunicazioni potranno passare semplicemente via mail e in quali occasioni sarà invece necessario allinearsi con il supporto di presentazioni.

Il migliore approccio che potete avere è creare un piano (condiviso possibilmente) e verificare mano a mano come sta funzionando. Non è necessario che sia perfetto, buono quanto basta è più che sufficiente.
Potreste scoprire in corso d’opera che l’idea iniziale non funziona come vi aspettavate. Non c’è problema: prendete dei feedback, modificate il piano di comunicazione testando i cambiamenti e reiterate il ciclo.

… ebbene sì, stiamo sempre parlando del metodo Lean Start-Up

Ad esempio vi potrebbe capitare che quanto ha funzionato ad inizio progetto si rivela meno efficace con il passare del tempo. Questo può essere dovuto al fatto che le informazioni da passare in fase di discovery sono molto diverse da quelle rilevanti durante la delivery e anche gli interlocutori potrebbero essere differenti.
Prendete nota della cosa e adattate il piano di comunicazione.

Ciò che dovete preservare a tutti costi è non il piano in sé ma l’approccio: essere intenzionali e consistenti. Avere chiara la finalità degli incontri (sono puramente informativi o servono a prendere decisioni?), prioritizzare le informazioni (soprattutto quelle più critiche) e capire cosa dev’essere riportato, quando e come.

Stiamo sempre raccontando storie

Poco tempo fa ascoltavo su Mind the Product un’intervista al CPO di Zoopla, David Wascha. L’intervistatrice domandava quali sono le skill più importanti nella gestione degli stakeholder e lui ha parlato di storytelling e ripetizione.

Tutte le volte che comunichiamo il nostro prodotto, ciò che stiamo realizzando e in quali attività è impegnato il team di sviluppo stiamo creando una narrativa su ciò che facciamo per l’organizzazione.
E’ importante essere consapevoli di questo aspetto: stiamo raccontando storie.

E come in qualsiasi storia che si rispetti è necessario rispettare un plot.
Nella narrativa in questione non possono mancare:

  • WHO (a chi stiamo risolvendo un problema)
  • WHAT (quale problema stiamo risolvendo)
  • WHY (perché è importante o di valore, in particolare per il cliente finale).

Chiediamoci sempre la motivazione della storia che stiamo creando, cosa vogliamo ottenere, se ciò che raccontiamo è al livello giusto, se ci siamo presi il tempo di supportarla con dati reali, se oltre ai dati abbiamo anche la possibilità di sostanziarla con citazioni degli utenti raccolte durante le interviste.

Il nostro storytelling di prodotto racconta dove siamo oggi, dove saremo e ciò che vogliamo ottenere.

Se ci pensate è proprio questa la scaletta di una review di prodotto:

  • riepilogo degli obiettivi e degli aspetti fondanti del progetto
  • lo stato dell’arte attuale
  • le attività che ci apprestiamo a fare nelle prossime iterazioni
  • gli impatti, i rischi e le eventuali decisioni da prendere

Ripetere, ripetere, ripetere… ed evitare di omettere le cattive notizie

Il secondo aspetto menzionato da David Wascha è la ripetizione.
“Le storie vanno ripetute. È fondamentale. Non devi essere soddisfatto fino a quando tutti sanno cosa state facendo. Lo ripeti anche 100 volte fino a quando non lo fanno anche gli altri.”

Riportare lo stato dell’arte di un progetto agli stakeholder è un processo continuo ed un’opportunità di allineamento continuo.
Ecco perché non ha ha senso “nascondere la polvere sotto il tappeto”.
Per quanto sia normale preferire riportare buone notizie, nascondere quelle brutte non le fa andare via e più tardi vengono sollevate peggiore è il rischio.

Avete presente quando slittano le date di una release di prodotto?
Questo è un grande classico!
Si vedono in anticipo i segnali che indicano qualche aspetto problematico ma si pensa di poter recuperare in corso d’opera e troppo tardi viene comunicato che non c’è possibilità di rispettare la deadline. E negli eventuali SAL di progetto è sempre stato comunicato che tutto procedeva secondo i piani…
Questo non fa che provocare la frustrazione in tutti gli stakeholder e una perdita di fiducia non solo sul progetto in questione ma anche su tutti quelli che verranno in futuro.

Ne vale la pena? Direi proprio di no. Meglio sollevare il rischio da subito!
Se i problemi che prefigurate oggi rientreranno non avrete impatti sul rilascio del prodotto, se non sarà così avrete tutto il tempo di valutare le opzioni disponibili e decidere come muoversi.
In più gli stakeholder apprezzeranno il fatto di sentirsi parte attiva del processo, sapranno che non nascondete loro informazioni e creerete i presupposti per una relazione di fiducia.

Pubblicato il

Pensare e testare il prodotto – intervento all’Agile Experience Conference

Recentemente ho preso parte all’Agile Experience Conference organizzata dagli amici di Agile for Italy. Si tratta di incontri live caratterizzati da un taglio pratico e dalla formula intervento iniziale più intervista da parte dei peer.
Giovedì 18 febbraio ho parlato di come “Pensare e testare il prodotto” in compagnia di Roberto Lunazzi, Lorenzo Cassulo e Deborah Ghisolfi.
Abbiamo approfondito quali tecniche usare per creare un prodotto amato dai nostri clienti, quali metriche e quali difficoltà si incontrano.

Qui trovate la registrazione:

Ed ecco a voi una traccia del mio intervento.

Le precondizioni di un buon progetto

Dobbiamo fare una premessa prima di affrontare il momento della discovery di prodotto.
E’ necessario fare un setting quando affrontate progetti di questo tipo per comprendere:

  • chi saranno gli interlocutori (il cliente finale, l’acquirente, lo sponsor in azienda, il responsabile della decisioni finale e chi può influenzare il progetto).
    E’ fondamentale riuscire a mappare tutti questi attori per partire con il piede giusto;
  • qual è esattamente l’obiettivo.
    Quando si fanno attività di questo tipo c’è sempre un’aspettativa da parte dell’azienda, che siano obiettivi di ricavi, quote di mercato piuttosto o volumi di vendita.
    È opportuno fare tante domande prima di iniziare e capire bene quali sono le regole del gioco perché gli obiettivi si possono portare a casa in molti modi e noi dobbiamo capire quali sono i trade-off percorribili.

Prima di tutto vi voglio proporre una distinzione tra prodotti totalmente nuovi e prodotti esistenti che devono essere fatti evolvere, ottimizzati, ecc.
Perché questo? Perché nei due casi abbiamo a disposizione strumenti diversi.

Creare prodotti, ma di che tipo?

Nuovi prodotti

Stiamo parlando di una situazione in cui non abbiamo dati a disposizione di prima mano.
Il prodotto non è presente in azienda; stiamo creando qualcosa di nuovo con cui non ci siamo ancora confrontati.

Cosa faccio di solito io?

Analisi

Faccio un’analisi: cerco gli stessi prodotti o soluzioni simili sul mercato e li studio (se posso li utilizzo direttamente, altrimenti cerco qualcuno che ne abbia esperienza, cerco materiale online, help o video, commenti, ratings).
Queste sono tutte informazioni utili per cominciare a farmi un’idea di questa tipologia di prodotti:
– come sono fatti
– che caratteristiche hanno
– quali sono i loro punti di forza
– eventuali punti deboli.

Personas

L’altro passo che faccio immediatamente è andare a capire chi sarà il mio pubblico.
Dedico tempo alla costruzione delle personas primarie che coincidono con i miei utilizzatori.
Si dice che i PO sono la voce del cliente in azienda ma se questa voce non la ascoltiamo mai dal vivo non stiamo facendo il nostro lavoro, ci stiamo perdendo una grande opportunità.

Con le personas voglio capire quale sarà il mio segmento di pubblico, non solo da un punto di vista socio-demografico.
Qui ho bisogno di scavare in profondità:
– che tipo di bisogni ha?
– quali preoccupazioni?
– cosa vuole ottenere?
– cosa è importante per queste persone?
– che cosa li motiva e li ispira?

Devo riuscire a costruire un profilo a tutto tondo per potermi mettere nei loro panni e verificare che il nuovo prodotto risponda alle sue necessità.

Impact Mapping

Negli anni uno strumento che mi è venuto molto in aiuto nella creazione di nuovi prodotti è l’impact mapping.
E’ una tecnica di pianificazione strategica che ci aiuta a costruire la mappa mentale del progetto:
– qual è esattamente l’obiettivo che vogliamo ottenere
– quali sono gli attori in gioco (e qui tornano in gioco le personas ma non solo)
– quali sono gli impatti che vogliamo produrre ovvero i cambiamenti nel comportamento degli attori
– quali attività (ovvero funzionalità o caratteristiche del prodotto potrebbero aiutarci ad ottenerli).

Per costruire questa mappa si fanno sessioni collaborative, più persone con diversi ruoli e competenze. Maggiore è la varietà e meglio è.

Sessioni collaborative di discovery

Come dico sempre il prodotto è un gioco di squadra, non è qualcosa che fate chiusi da soli dentro il vostro ufficio. Avete bisogno di un confronto continuo nella fase di discovery.

Ecco perché consiglio di sfruttare il più possibile per la creazione di nuovi prodotti le sessioni collaborative di co-creazione: facciamo brainstorming, ad esempio lift-off di progetto o – se ne avete la possibilità – potete proporre degli innovation days o degli hackathon dove diversi team cross-funzionali elaborano idee, le migliori vengono votate e si può arrivare a generare un prototipo dell’idea.

Tutti questi eventi hanno un enorme vantaggio perché portano le persone a bordo, fanno comprendere la sfida e consentono di generare tantissime idee così da selezionare le migliori.

Migliorare prodotti esistenti

Dati ed esperienze di prima mano

Qui possiamo utilizzare tutto quello che abbiamo detto prima ma abbiamo altre frecce al nostro arco. Esistono già degli utenti del nostro prodotto, abbiamo dati di acquisto e di utilizzo.
Sfruttiamo al massimo questi mezzi!
Andiamo a parlare con acquirenti e utilizzatori, intervistiamoli (i dati quantitativi non vi bastano per capire i fenomeni, dovete capire il perché), guardiamo gli analytics, dati di vendita e utilizzo, le registrazioni di sessioni utente, le domande che arrivano all’assistenza clienti o vengono fatte ai commerciali, sondaggi, analisi della customer journey.

Io di solito parto da interviste interne all’azienda per farmi un’idea dei problemi principali, monitoro l’utilizzo e poi vado a fare interviste qualitative.

Interviste JBTD

Potete utilizzare il framework JBTD con cui cercate di capire a quale scopo serve il prodotto o il servizio, sia da un punto di vista più funzionale (è il cosiddetto lavoro primario), sia da un punto di vista emotivo e sociale (come il prodotto fa sentire il cliente, come viene percepito dagli altri).
Perché sono importanti? Perché se non capiamo sulla base di che cosa un utente sceglie il nostro prodotto, quali sono i suoi parametri principali o creiamo una soluzione che non vuole nessuno (e magari questo problema non l’avete con un restyling o un replatforming) o riempiamo il prodotto di funzionalità inutili che non ne aumentano il valore, bensì lo diminuiscono.

Utilizzando anche solo alcuni di questi strumenti avrete raccolto una marea di informazioni su cosa funziona e cosa no, avrete moltissimi spunti su cosa aggredire per primo e avrete generato un backlog di attività.

Pronti per lo sviluppo? No, testiamo l’idea di business

A me piace l’idea di testare l’idea di business (non stiamo parlando di testare il prodotto finito); stiamo parlando di compiere un giro completo prima ancora di partire con un singola riga di codice.
E’ un approccio che è diventato sempre più mainstream negli ultimi anni. Da Lean Startup in avanti è conosciutissimo.

Experiment Map

Qui ci vengono in aiuto una serie di strumenti: ad esempio potete utilizzare un semplicissimo canvas, quello della experiment map. Identificate quali sono le assunzioni più rischiose che stanno dietro alla vostra soluzione, chiarite il risultato che vorreste ottenere e poi costruite un esperimento (il più semplice e meno costoso possibile) per verificare la vostra idea.
Non serve avere il prodotto finito, basta abbozzarlo!

Minimum Viable Product

Ci rifacciamo al concetto di MVP, Minimum Viable Product, una delle idee più bistrattate e meno comprese.
Quando parlo di MVP mi viene sempre in mente l’esempio di Zappos che nel 1999 ha testato l’assunzione più rischiosa che stava dietro alla sua idea di business con un concierge MVP.
Tenete conto che l’e-commerce non era il fenomeno che è adesso. Il founder doveva capire se le persone sarebbero state disposte a comprare qualcosa online – le scarpe – senza poterlo provare.
Ha costruito un negozio finto, un front-end vetrina senza che ci fossero tutti i processi dietro. Ogni volta che qualcuno cliccava sul pulsante “Compra” andava fisicamente a comprare il paio di scarpe in negozio.

Design Sprint

Negli anni gli strumenti sono diventati sempre più sofisticati: pensate al design sprint inventato da Google Venture. In 5 giorni riducete i rischi del lancio sul mercato di un nuovo prodotto o servizio. Partite dalla definizione del problema, fate brainstorming delle possibili soluzioni, scegliete la più promettente, costruite un prototipo e lo validate con potenziali utenti.
Questo non vi fa solo risparmiare tempo e denaro, vi fa risparmiare la creazione di waste.

Conclusioni

In sintesi abbiamo tanti strumenti a disposizione.
Non esiste lo strumento perfetto o un unico strumento per un problema.
Provateli, testateli e cercate quello che più vi risuona, con cui vi trovate bene.

Ma la cosa importante non sono gli strumenti in sé.
Quando penso alla creazione di un nuovo prodotto per me è determinante l’approccio che è fatto di questi ingredienti principali: ascolto, lavoro di squadra, confronto con la realtà (uscite dagli uffici!), utilizzo di dati e sapere di non sapere.
Tutto è ancora da imparare!

Pubblicato il

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.

Proudly powered by WordPress