Tracciare esperimenti Lean su Trello: un modello pronto da usare

Il concetto di esperimento è basilare nel processo Lean Startup. Quando un’organizzazione decide di innovare migrando da un approccio tradizionale a quello del Validated Learning, avere una struttura da seguire aiuta nello sforzo di assimilazione dei concetti e a evitare di prendere scorciatoie. La tentazione di implementare qualche feature al volo e solo poi abbozzare un qualche esperimento giusto per fare il compitino, è molto forte.

La bacheca Trello che vi presento nasce con questo scopo: aiutare il team di Progetta la Domotica – startup in cui Kiwifarm fa azione di accelerazione –, a fare le cose nell’ordine giusto e a dedicare loro il giusto tempo.

La struttura è ispirata ai modelli di scheda esperimento proposta da Osterwalder e Bland e al Lean SMART Template di Kromatic. A queste ho aggiunto la possibilità, inoltre, di tracciare le attività pratiche di preparazione e monitoraggio introducendo le schede sui risultati attesi generici (sarà più chiaro cosa intendo più avanti).

La scelta di fare tutto su Trello è stata dettata dal fatto che mi permetteva di tracciare, oltre al processo, anche dati e conversazioni per ogni singolo step grazie alle sue funzioni di commento e annotazione.

Struttura della bacheca

Vi presento la nostra compagna di avventure:

Partendo da sinistra verso destra, la bacheca è composta dalle seguenti liste:

• Come usare questa bacheca: contiene una serie di card che descrivono l’utilizzo della bacheca stessa. Questa lista è anche il punto giusto per inserire le vostre indicazioni di netiquette per il team o descrivere eventuali modifiche alla stessa che vorrete fare;
• Modelli: ospita tutte le schede modello che ho creato e che useremo. Le vedremo in dettaglio tra poco;
• Riferimenti: mettete in questa lista link, immagini, documenti e tutto il materiale che può essere utile al team per portare avanti gli esperimenti. Ricordatevi di tenerla sempre aggiornata: documenti obsoleti vanno marcati come obsoleti o eliminati per evitare che le persone vaghino in cerca di informazioni (o peggio che prendano per buone informazioni che non lo sono);
• Esempio esperimento: contiene un esempio di utilizzo della bacheca. Ne parleremo più avanti;
• Esperimento #1: una lista vuota pronta ad ospitare i vostri primi sforzi di modellazione, esecuzione e revisione di esperimenti.

Vediamo nel dettaglio quali modelli di schede mette a disposizione la bacheca. Ve li presenterò nell’ordine in cui andrebbero usati.

La prima cosa è definire l’ipotesi

La prima cosa da fare è sicuramente definire l’obiettivo dell’esperimento, ovvero qual è l’ipotesi che si vuole esplorare e quali eventi porteranno a una validazione o meno della stessa.

Scheda Ipotesi

La scheda Ipotesi descrive l’ipotesi che guida l’esperimento. Sarà possibile espandere l’idea nella descrizione ma un buon esperimento dovrebbe essere descrivibile in modo chiaro e sintetico nello spazio del titolo della scheda. Piuttosto, trovo molto utile mettere nella descrizione l'obiettivo di apprendimento da cui nasce l'esperimento: perché sto esplorando proprio questa ipotesi? Ad esempio, se state facendo l'ipotesi che il "canale passaparola" porti ad un certo tasso di conversione, l'obiettivo di apprendimento da mettere in descrizione potrebbe indicare che state facendo questo esperimento specifico perché state cercando il canale giusto per raggiungere i vostri clienti. Un singolo obiettivo di apprendimento può accomunare anche più esperimenti diversi presenti in bacheca, ovviamente.

La scheda mette a disposizione una serie di etichette che si possono usare per indicare lo stato dell'esperimento. In particolare sono a disposizione:

• 🏃🏻‍♂️ In corso, per quando l'esperimento è partito.
• 🙌 Validata!, per quando l'esperimento è risultato portare ad una validazione dell’ipotesi. Complimenti!
• 🔥 Invalidata, per quando l'esperimento ha portato ad un'invalidazione dell’ipotesi.
• 🤕 Cantonata micidiale, quando l'esperimento si rivela essere “rotto” ovvero perché i risultati sono stati disastrosi o incongruenti tanto da far sospettare che ci sia qualcosa di sbagliato altrove.

Trovo l’uso delle etichette moto utile soprattutto quando si portano avanti più esperimenti contemporaneamente. L’uso dei colori aiuta ad avere a prima vista lo stato degli esperimenti e, grazie alla possibilità di filtrare le schede per etichetta, diventa facile focalizzare l’attenzione su cosa si sta facendo, su cosa si è fatto e sulle cose più importanti che abbiamo imparato.

Se siete rigorosi, può essere comodo utilizzare il campo Insight area per indicare che area del Business Model si sta indagando.

I possibili valori sono:

• Desirability/Problem
• Desirability/Value
• Desirability/Channel
• Feasibility
• Viability

Insieme alle etichette, per tracciare l’evoluzione dell’esperimento, viene comodo il campo Progressi che abbina alla scheda una percentuale di progresso. Questo campo è visibile in tutte le card ma ragionevolmente è utile o nella scheda Ipotesi o, se volete concentrarvi di più sull'evoluzione delle metriche, potete usare quello all’interno delle schede dedicate ai Risultati Attesi.

Scheda Risultato Atteso

Un risultato atteso è una cosa che deve succedere per validare (o invalidare) l'esperimento ma può includere le attività preparatorie all’esperimento.

Se non li odiate, potete usare gli emoticon nel titolo della scheda per categorizzare a colpo d'occhio il tipo di risultato atteso stai descrivendo:

• 🔑🙌 descrive un risultato atteso che porta alla validazione: cosa deve accadere perché l’ipotesi sia considerata validata?
• 🔑🥺 descrive un risultato atteso che porta all’invalidazione: cosa deve accadere perché l’ipotesi sia considerata invalidata?
• 🔑🤯 descrive un risultato atteso che identifica il fallimento o un'incongruenza all'interno dell'esperimento: cosa deve accadere perché l’esperimento sia palesemente incoerente?
• 🔑 risultato atteso generico: cosa devo fare per costruire l’esperimento? Con i risultati attesi generici indichiamo tutto quello che è necessario fare per validare l’ipotesi quindi anche le attività che il team fa per preparare l’esperimento o che deve fare durante l’esperimento. L’idea è di evitare lo sparpagliamento delle to-do list del team: tutto quello che riguarda l’esperimento è qui.

Esempi di risultati attesi sono:

• 🔑🥺 Ricevute meno di 3 nuove email dal questionario online su Typeform
• 🔑🤯 La permanenza media sulla pagina secondo Hotjar è >2 minuti ma nessuno scarica l'ebook
• 🔑🙌 5 intervistati in target confermano che il prezzo preferito sia 9.99$
• 🔑 avere pronto il testo del questionario da presentare ai potenziali clienti su Google Form.

NB: Sebbene il nome sia lo stesso è evidente che non ci sono relazioni con il concetto di Key Result (risultato atteso, appunto) degli OKR. Vi rimando ad un mio articolo sul tema se siete digiuni riguardo gli OKR.

Cosa stiamo misurando?

Definita l’ipotesi e quali sono i criteri per validarla, il nostro esperimento partirà. Sarà quindi necessario tracciare l’evoluzione delle metriche di interesse. Per questo ci vengono in aiuto le schede sulle metriche: la scheda per la metrica principale e quella per le metriche secondarie.

Scheda Metrica principale

Mentre il Risultato Atteso descrive l'evento che determina il successo o meno dell'esperimento, la Metrica Principale è proprio il numero che sarà osservato e sul quale si baserà la decisione. Esplicitarla al di fuori del risultato atteso aiuta ad essere sicuri che tutti stiano misurando allo stesso modo le variabili importanti.

Se avessimo un risultato atteso del tipo “permanenza media di un utente è maggiore di 1 minuto”, la metrica principale sarà tempo medio speso da un utente sul sito. Come dicevo, ribadire in modo chiaro e condiviso cosa si deve misurare aiuta – soprattutto i membri più tecnici del team – ad avere una definizione condivisa su cosa si sta osservando evitando interpretazioni personali. Ad esempio nel nostro esempio si può essere più specifici: tempo medio ovvero tempo medio di una sessione utente? Tempo medio tra login e logout? Qui c’è l’opportunità di essere chiari.

Durante l’esperimento, il campo Valore di questa scheda viene usato per annotare l’ultimo valore registrato, così che il team abbia con regolarità una visione di cosa stia succedendo. Ovviamente si possono allegare anche grafici o tabelle se il campo numerico non è sufficiente. La flessibilità di Trello è un’arma da sfruttare.

Scheda Metrica secondaria

Una Metrica Secondaria è o una misura che serve d'appoggio alla metrica principale o è una metrica che si decide di osservare comunque durante l'esperimento, anche se non relativa da un risultato atteso.

Ad esempio per calcolare il tasso di conversione della mia campagna Facebook (misura principale) misurerò le impression dei miei post perché è un dato che mi serve per il calcolo. Oppure, si decide di registrare il numero di click su un particolare link: questo non perché sia utile al calcolo della metrica principale, ma perché viene comodo e utile registrare oggi questo valore come riferimento per altri esperimenti futuri.

Anche questa scheda ha un campo Valore per tracciarne lo stato corrente e avere un unico posto per raccogliere commenti e conversazioni sulla metrica descritta.

Cosa abbiamo imparato?

Scheda scoperta principale

Ad esperimento terminato, in questa scheda andrà scritta la cosa più importante che si è appresa dall'esperimento.

Ci sono cose importanti che si imparano sia quando un esperimento ha successo, sia quando l'ipotesi viene invalidata. Inoltre si potrebbe imparare qualcosa di importante che non avevate previsto nell'esperimento! Ad esempio, stavate verificando che il vostro cliente fosse interessato ad una certa offerta e oltre a questo i dati ti danno evidenza che è interessato anche a qualcos'altro. Sorpresa: ho imparato una cosa inaspettata!

Una buona idea è usare anche qui il campo Insight area per indicare che area del Business Model si è indagato come fatto nella scheda dell’ipotesi: quando farete il punto della situazione sarà facile filtrare le schede e trovare le informazioni giuste.

Decidete con il team quale cosa tra le tante che imparerete durante un esperimento è la più importante. Abituate il team a valutare le cose in base all’obiettivo che vi siete dati: non fate di tutta l’erba un fascio. Questo accade solo se si decide di non scegliere, ma lo scegliere è lo strumento principale di design che abbiamo a disposizione: usatelo.

Ma le altre cose che abbiamo imparato? Le scriveremo usando la prossima card.

Scheda scoperta secondaria

Questa scheda serve per dichiarare altre cose imparate durante l'esperimento.

Sicuramente, alla fine dell'esperimento, avrete imparato più cose, alcune inaspettate e altre semplicemente periferiche rispetto ai risultati attesi descritti. Ad esempio, avrete scoperto che l'aver sostituito Hotjar con CrazyEgg è stata una buona mossa (oppure no) e questo per motivi tecnici (o meno). Ecco, questa scheda è un buon posto per segnare queste informazioni per renderle patrimonio del team.

Usate anche qui il campo Insight area !

Scheda documenti

Abbiamo detto che c’è una lista Riferimenti che può essere usata per raccogliere link e documenti di interesse generale. Puoi usare questa scheda lì o in una lista dedicata ad un esperimento specifico.

Questa scheda è una specie di graffetta per pinzare materiale a supporto dell'esperimento o del team: allegateci il materiale di supporto prodotto prima, durante o dopo l'esperimento.

Può contenere un CSV con i dati grezzi raccolti, una relazione che avete preparato o anche solo i link agli strumenti utilizzati.

Ovviamente, se il materiale è tanto, si possono creare più schede suddivise tematicamente. Si potrebbe creare, ad esempio, una scheda per il materiale che serve a creare l'esperimento, una con quello per tracciarlo e una con relazioni e presentazioni dei dati.

Gatti che miagolano e croccantini: un esempio di utilizzo

Facciamo un esempio?

Nella bacheca trovate la colonna Esempio Esperimento che descrive un esperimento fittizio che riguarda un gatto, dei croccantini e la voglia di miagolare.

Di solito, per verificare che tutto sia coerente, con il team faccio così: alla fine del lavoro, prima di dare l’esperimento per approvato, leggo in fila tutte le schede e chiedo a tutti se il discorso fila liscio o c’è qualche cosa che “suona stonata”.

Man mano che il lavoro di gruppo avanza tutti si concentrano sempre più sui dettagli e c’è il rischio di perdersi qualcosa che puoi vedere solo dall’alto. Di solito questa rilettura aiuta a guardare l’esperimento nella sua interezza almeno un paio di volte prima di dare l’ok.

In questo caso la lista si potrebbe leggere così:

Nell’ultima settimana abbiamo imparato che
la sazietà del gatto non influisce sul suo miagolio
e che
il gatto preferisce i croccantini al tonno e pistacchio rispetto a manzo affumicato.
Inizialmente noi pensavamo che
un gatto non è miagoloso se ha mangiato almeno 3 etti di croccantini.
Abbiamo detto che questo sarebbe stato vero se,
predisposta una ciotola di croccantini da dare al gatto tutti i giorni alle 12 con 300gr di croccantini,
allora
il numero di miagolii medi giornalieri è < 50.
Se invece
il numero di miagolii medi giornalieri è maggiore di 100
allora la nostra ipotesi sarebbe stata invalidata, ma sempre stando attenti al fatto che non succedesse qualcosa di imprevisto come il fatto che
il gatto non ha mangiato i croccantini!
A sostegno delle nostre conclusioni abbiamo misurato il
numero di miagolii medi su base giornaliera
che sono stati 133 e la
quantità di croccantini mangiati
che sono stati 300g giusti.

Questo esempio descrive un esperimento già completato, infatti abbiamo anche le schede delle cose imparate. Attenzione però: dovreste usare il trucco di leggere le card tutte in fila con il team soprattutto quando state definendo l’esperimento (non solo alla fine)!

Consigli finali

Per chiudere vi lascio di nuovo qui il link al modello della bacheca in versione italiana e in versione inglese.

Prima, però, tre ultimi consigli:

1. Mettete in ordine le schede: ipotesi, risultati attesi, misure. La grafica delle copertine delle schede è pensata per raggruppare visivamente le card se le mettete nell’ordine coretto.
2. Aggiungere le schede delle cose imparate in cima alla lista per dare loro la giusta importanza: infondo tutta questa fatica la facciamo per riempire queste schede e farne tesoro. Inoltre, il fatto che siano tutte in un posto specifico, aiuta la lettura rapida della bacheca.
3. Riguardo gli emoticon nel titolo: io consiglio di mantenerli sempre. Questo per aiutare a capire che tipo di scheda state leggendo al primo sguardo.

Fatemi sapere come vi trovate usando la bacheca, mi raccomando! Scrivetemi un’email o venite a trovarmi su Twitter e LinkedIn.

Approfondimenti

Lascio qui qualche link per chi volesse approfondire alcuni temi toccati in questo post.

Riporto anche qui i link al modello della bacheca Trello in versione italiana e in versione inglese.

Per un riassunto veloce del tema della sperimentazione nel Lean, vi rimando a questo articolo di Kirsten van Engelenburg (link visitato il 20 Marzo 2021).

Sul tema della viability, desirability e feasibility, qui Charlie Gedeon ha scritto un bell’articolo che li descrive all’interno del processo di validazione del business (link visitato il 20 Marzo 2021).

Per una visione critica del processo Lean Startup vi rimando al lavoro di Nancy Bocken e Yuliya Snihur, Lean Startup and the business model: Experimenting for novelty and impact, pubblicato su Long Range Planning, Volume 53, Issue 4, del 2020 (ISSN 0024-6301, https://doi.org/10.1016/j.lrp.2019.101953 – link visitato il 20 Marzo 2021).

Se si parla di Lean, non posso non chiudere ricordandovi il libro di Eric Ries, The Lean Startup, nella versione originale inglese o nella traduzione italiana.