Metodologia Lean: 5 consigli pratici + esempi

Metodologia Lean: 5 consigli pratici + esempi

- di
Metodologia Lean: 5 consigli pratici + esempi

Negli ultimi anni la metodologia Lean, grazie anche al libro di Eric Ries Lean Start-up, ha riscosso grande successo. Dopotutto, quando un imprenditore si sente domandare: vuoi aumentare le possibilità di successo del tuo prodotto riducendo lo spreco di tempo e soldi?

La risposta non può che essere positiva.

Il problema è che quando provi ad applicare quello che si legge nei libri senza aver ancora avuto esperienze dirette sul campo rischi di sprecare tantissimo tempo nel capire come adattare il metodo alla tua situazione reale.

Altro rischio che corri, in questi tempi, in cui mi sembra ci siano più Mentor che Start-up in Italia, è di affidarti a persone che hanno studiato tantissimo, sono super intelligenti e in gamba, ma nella loro vita hanno fatto più consulenza o mentorship che “guerra in trincea”. Non sono mai stati costretti a prendere decisioni da cui dipendeva il proprio futuro, quello del proprio team o azienda.

L’obiettivo di questo post è quello di aiutarti a non commettere errori che ho già commesso o che ho visto commettere “in trincea”.

Se sei in un’azienda più strutturata che lavora sullo stesso prodotto da anni non temere: tutto quello che leggerai lo puoi applicare anche a singole feature o idee/progetti che vuoi testare prima di investire più tempo e soldi.

In questo post non ti spiegherò cosa è la metodologia Lean, per cui se ancora non lo sai puoi partire da qui, ma troverai le 5 cose da non fare se vuoi aumentare le tue possbilità di successo, risparmiando tempo e soldi.

1. Metodologia Lean non significa validare tutto

Se dovessi riassumere in una sola frase il libro di Eric Ries, sarebbe:

“Testa sistematicamente l’ipotesi più rischiosa del tuo piano”

Non “fai tantissimi esperimenti su cose irrilevanti sprecando molto tempo”

Per lavorare in questo modo devi avere 3 caratteristiche e devono esserci tutte e tre contemporaneamente.

1.1 Coraggio

Può sembrarti strano parlare di coraggio quando si lavora su prodotti digitali eppure vedo spesso team alla ricerca di quella micro ottimizzazione di qualche punto percentuale piuttosto che andare alla ricerca di impatti significativi per il proprio prodotto/progetto.

Non devi testare cose a caso ma solo quelle che possono darti davvero un insight profondo sul futuro del tuo prodotto.

Definisci degli obiettivi molto sfidanti non sapendo ancora come li raggiungerai e da lì itera partendo dalle ipotesi più rischiose che potrebbero distruggere il tuo piano.

Ti faccio un esempio molto semplice sul coraggio:

Qualche tempo fa ho assistito a uno speech dei due founder di of course me che avevano da poco lanciato il proprio prodotto B2B, in Italia stava andando bene e stavano già lavorando per aprire il prossimo paese.

Avevano scelto la Germania.

Onestamente non capivo quella scelta, così ho chiesto il motivo.

Il loro ragionamento non faceva una piega.

Nonostante il paese più prossimo per similarità su cui abbia senso muoversi sia la Spagna e il paese che per noi sarebbe più semplice aggredire, per i contatti che abbiamo, sarebbe UK, partiamo dalla Germania perchè per dimensioni e per mercato potenziale per il nostro prodotto sarebbe davvero un altro livello.

Vogliamo scoprire il prima possibile se la nostra è una società da 5 milioni € di revenue o da 20.

Non si tratta di giusto o sbagliato, si tratta di essere coraggiosi e partire dalla fine.

1.2 Egoless

Durante l’ultima session della Product Academy Sara ha ripetuto più volte questa parola “Egoless”: se vogliamo davvero delle risposte dobbiamo essere disposti a “scomparire”.

Tra tutti i “don’t know” che puoi esplorare le cose che “non sai di non sapere” possono darti le più grandi opportunità e per scoprirle devo essere disposto a sacrificare il tuo “ego”.

Spesso ho visto applicare cicli di feedback loop esclusivamente per avere dati a supporto nel vendere o proporre l’idea al proprio capo/responsabile.

Sì, lo puoi fare, ma ha poco senso.

Ti perdi la parte più bella e interessante del creare prodotti da zero: la scoperta.

Se vuoi “scoprire” sappi che il tuo EGO può essere il maggiore ostacolo al successo del tuo prodotto.

Consiglio super semplice, soprattutto quando pensi di avere l’idea del secolo: ricordati che è sempre un’ipotesi, anche se ne sei super-sicuro, e come tale va validata.

Un Esempio di validazione andata male:

Anni fa lavoravo su una piattaforma di Video Advertising ed ero super sicuro che se avessimo implementato nuovo un formato utilizzato da un nostro competitor avremmo svoltato.

Invece di impiegare mesi nello sviluppo del videoplayer perfetto integrato con il nostro sistema ne creammo uno “a mano” da dare esclusivamente a un paio di siti.

Volevo solo capire di quanto sarebbe aumentata la nostra reach.

Quello che non sapevo di non sapere è che le performance in termini di click in effetti erano alle stelle, ma anche il bounce rate.. così nessuno dei siti volle mai più utilizzarlo dopo 3 giorni di test.

1.3 Disciplina

Credo che tra i 3 sia la più importante. Senza disciplina farai molta più fatica.

Non è il caso in questa sede di dilungarsi sulla disciplina perchè andrebbe dedicato un post intero, ma ti descrivo l’andamento tipico di quando si prova ad introdurre in azienda un approccio (più) Lean.:

A) Che figata la metodologia Lean
b) Implementiamola!
C) Ok scriviamo le nostre ipotesi su un foglio excel e poi partiamo da quella più rischiosa
D) No dai, troppo faticoso, tanto so perfettamente cosa dobbiamo validare
E) Anzi, intanto rilasciamo questa feature che è molto importante, “facciamo Lean” la prossima volta

Non c’è quasi mai un lieto fine…

2. La Metodologia lean Non è 0/1 

Come tutti i metodi si pensa che applicandoli qualcuno prenderà le decisioni al posto tuo o che magicamente i problemi si risolveranno da soli.

Questo è il motivo per cui i libri o i corsi che ti propongono formule segrete hanno così successo.

Il feedback loop (Build, Measure, Learn), è stato sicuramente un elemento di discontinuità e super innovativo, nell’approccio classico Waterfall allo sviluppo di prodotto.

Allo stesso tempo applicarlo pedissequamente guardando solo ai dati in modalità sì / No, 0/1, non ti aiuterà.

“Purtroppo”, e se hai abbastanza esperienza potrai confermarlo, non avrai quasi mai la certezza matematica che ha senso continuare ad andare avanti con i tuoi esperimenti.

Quello che avrai invece è una progressiva riduzione dell’incertezza rispetto al tuo progetto. Alla fine di ogni esperimento avrai maggiore evidenze nel prendere decisioni che fino a qualche tempo prima sarebbero state solo opinioni.

Questo grafico mostra bene l’essenza del modo in cui devi procedere.

3. Pivotare non è cambiare idea o aggiungere feature

Questa è la mia preferita.

Sappiamo quanto i pivot abbiano trasformato prodotti medi in società quotate in Borsa:

  • Slack era uno strumento di comunicazione interno usato da un team che stava sviluppando un gioco.
  • Shopify era un ecommerce di Sci e Snowboard
  • Youtube era un sito di appuntamenti online.

Se non conosci le loro storie ti consiglio di approfondire. Credo che i processi decisionali che hanno accompagnato questi pivot, e le rispettive execution, siano tra le storie più interessanti da studiare (qui quello su Slack).

Il problema è che c’è poca chiarezza su cosa effettivamente sia il Pivot.

Questa parola infatti negli ultimi anni è diventata il più grande alleato per CEO o Manager che:

  1. Cambiano semplicemente idea
  2. Vogliono aggiungere Feature

Se hai letto il post sulla Fabbrica di Funzionalità ormai sarai in grado di riconoscere i segnali di allarme, ma credimi che non è così semplice quando ci sei dentro.

Il concetto di base sul Pivot è che non basta un NO di un cliente o una nuova (apparentemente migliore) opportunità per lasciare il progetto su cui stai lavorando.

Ho visto prodotti davvero fighi essere sostituiti o abbandonati totalmente semplicemente perché stavano sbagliando target.

Un consiglio pratico e super semplice per evitare questi scempi: assicurati di avere estremamente chiaro il problema che vuoi risolvere e per quale gruppo di clienti.

Solo dopo aver iterato su queste due parti prendi in considerazione le altre possibilità. 

Non ti sto dicendo di ignorare le opportunità, ma di prenderle con cautela.

Come esseri umani siamo naturalmente attratti da quello che non abbiamo, per cui quella nuova opportunità, quella nuova soluzione ci sembreranno sempre molto più attraenti di quello che stiamo costruendo specialmente se siamo nella fase primordiale del nostro prodotto.

4. MVP non sono prodotti brutti e che funzionano male.

Abbiamo già spiegato cosa è un Minimum Viable Product, quali sono gli errori da non fare assolutamente prima di arrivare al product / market fit, ci siamo anche spinti oltre affrontando il tema del Minimum Lovable Product ❤️ (il cuore non si può non usare..), ma evidentemente non siamo stati abbastanza chiari.

Questa volta inizio spiegandoti che cosa non è l’MVP

l’MVP non è la prima release.

Il fatto che tu stia rilasciando qualcosa per la prima volta non significa che stai facendo un MVP.

Attenzione: ancora più importante, l’obiettivo non è fare un MVP!!!

L’obiettivo è quello di usare un approccio che ti consenta di minimizzare il rischio di insuccesso, imparare più velocemente possibile cosa ha senso fare con il minimo spreco.

L’MVP è uno dei modi per fare questo.

Quindi se hai speso mesi per costruire software, magari con un intero team dedicato, senza uno straccio di validazione reale non è un MVP, ovvero stai sprecando energie.

l’MVP non è un prodotto brutto.

Il fatto che tu abbia fatto velocemente un prodotto difficile da usare e approssimativo non equivale ad aver fatto un MVP.

L’obiettivo del MVP è l’apprendimento veloce su un obiettivo molto chiaro e misurabile.

Se lo stai già dando in mano ai tuoi utenti questi devono essere in grado di usarlo e nella maggior parte dei casi devono essere disposti a pagare.

5. Un indizio positivo non ti autorizza a scalare.

Probabilmente l’avrò ripetuto in ogni singolo post che ho scritto qui su Product Heroes: non pensare a scalare!

Ho anche scritto un post dedicato su questo:

Credo che uno dei più grandi regali che ci ha fatto Eric Ries sintetizzando la metodologia Lean sia stato quello del concetto di Batch Completo, ma non capisco perchè il 99% delle persone che sviluppano prodotti digitali continua ad ignorarlo.

Non importa quanto veloce vai se stai andando nella direzione sbagliata.

Assicurati sempre di completare fino alla fine un ciclo iterativo, solo dopo aver raccolto le evidenze e averle analizzate muoviti in avanti.

Esempio fresco:

In questi ultimi mesi sto lavorando su un servizio B2B la cui ipotesi più rischiosa (dal mio punto di vista) è il target a cui mi rivolgo.

Tante volte durante gli ultimi 6 mesi mi sono avvicinato alla chiusura del primo batch, ovvero il primo cliente pagante, ma prima di Marzo non era mai successo.

Ho avuto la tentazione più volte di passare alla fase successiva come Go To Market Strategy, Acquisition, etc. ma fortunatamente mi sono sempre fermato. Ho avuto 1000 idee, non stavo nella pelle, ma mi sono sempre trattenuto.

Adesso, col senno di poi, ringrazio le porte in faccia che mi sono preso in passato, che mi hanno aiutato a non fare quel passo in più che mi avrebbe portato a sbagliare target: i potenziali clienti che si sono dimostrati interessati alla fine non hanno mai pagato.

Oggi, dopo aver completato il primo batch ed avendo iniziato l’erogazione del servizio ho chiarissimo il cliente a cui devo rivolgermi e soprattutto quelli da evitare che mi avrebbero fatto sprecare tempo e soldi.

+ 1: La metodologia Lean è solo un metodo

La metodologia Lean è solo un metodo e come tale va inteso.

Diffida sempre da chi ti offre formule magiche o ricette segrete, per cui prendi solo quello che ti serve.

Alcuni sostengono che il concetto di MVP sia ormai obsoleto creando acronimi o altre declinazioni com MLP, MMP, etc.

Altri che La User research, in particolare il Customer Development e le relative iterazioni possa sostituire la produzione di software intermedio.

Altri ancora che l’analisi delle coorti abbia poco senso e l’A/B test vada applicato sempre.

Il mio consiglio: Sono solo metodi. Fatti la tua idea in base a quello che ti serve, non andare avanti a ca**o, ma non farti paralizzare dall’analisi, procedi un po’ alla volta, scegli un approccio e seguilo. Usa sempre il buon senso e tieni un mindset Agile.

Vedrai che con disciplina, coraggio e perseveranza arrivi sempre.

Marco Imperato

Co-Founder e Amministratore di Edgemony, società che fonda nel 2020, con il duplice obiettivo di accelerare lo sviluppo del territorio siciliano grazie alle competenze digitali e aiutare aiuta le aziende italiane, e non, a estendere in Sicilia il proprio Tech Team. Crea Product Heroes a fine 2018, la prima community per Product Manager in Italia che conta 6.000 iscritti alla newsletter. Product Heroes è il punto di riferimento per chi fa prodotto, e ha aiutato fino a oggi oltre 180.000 product lovers grazie al Master in Product Management, Programmi B2B, Contenuti ed Eventi on the ground. Dal 2008 guida il dipartimento di Prodotto e Digital Media di Mosaicoon, dal giorno della creazione fino alla chiusura per fallimento 10 anni dopo.

Le slide sono disponibili per studenti ed ex studenti del Master in Product Management

Accedi a "Agile Starter Kit" Gratis

Iscriviti alla newsletter e accedi ad Agile Starter Kit: la cartella che contiene oltre 70 pagine su Agile, Scrum / Kanban, Organizzazione Team, User Story, Backlog, e tutto ciò che ti serve per partire.

Scarica il post sulle alternative a Scrum

Iscriviti alla newsletter e scarica gratuitamente il post "Agile Scrum: Alternative più flessibili e agili"