Growth, Lean, Agile: qual è il legame tra questi mondi?

Introduzione

Osserva per un attimo lo schema in basso. Noti qualcosa? La somiglianza tra il ciclo di Growth Hacking, quello dello sviluppo Agile e quello della metodologia Lean Startup è incredibilmente simile, vero?

La ragione è presto detta, tutte queste metodologie, così come altre che non approfondirò in questo post (come Design Thinking, DevOps e altre emerse negli ultimi anni), hanno radici comuni e si basano su principi di base molto simili, ma applicati in contesti diversi: l’iterazione continua, i cicli rapidi di feedback, la centralità dell’utente, le decisioni data-driven e così via.

Agile e Lean sono due mondi che hanno molto in comune ed è interessante fare un passettino indietro per capire in che modo i loro principi abbiano influenzato poi la nascita del Growth Hacking.

La nascita della metodologia di sviluppo Agile

Ken Collier descrive l’approccio Agile come “una metodologia di sviluppo software nella quale requisiti e soluzioni si evolvono tramite l’effort collaborativo di team autogestiti e cross-funzionali e l’interazione continua con gli utenti”.

Anche se le sue origini vanno indietro fino agli anni 70, con la nascita di movimenti come evolutionary project management e adaptive software development, l’esplosione di Agile è avvenuta nel 2001 quando un gruppo di 17 sviluppatori di software si radunarono nello stato americano dello Utah per scrivere l’Agile Manifesto basato su 12 principi e 4 valori chiave.

Non è tra gli obiettivi di questo post illustrare l’intera metodologia Agile, ma tra i 4 valori chiave ce ne sono due che meritano sicuramente di essere citati e che più avanti torneranno utili:

• Gli individui e le interazioni più che i processi e gli strumenti
• Rispondere al cambiamento più che seguire un piano

Esistono diverse implementazioni dei principi Agile con differenze più o meno rilevanti (in base alla scuola di pensiero o al framework utilizzato per implementarlo), ma in linea di massima i passi del suo ciclo sono 6:

1. Analisi dei requisiti. Il team lavora con gli utenti e gli altri stakeholder per identificare quali sono i requisiti del progetto che si andrà a sviluppare: chi userà il prodotto, in che modo, con quali esigenze e così via.
2. Pianificazione. A questo punto si passa dallo scenario macro (le informazioni raccolte nel punto 1) allo scenario micro, ossia suddividere il progetto in funzionalità, definire le priorità e assegnare i task.
3. Design. Definite le funzionalità, c’è uno step che precede l’implementazione vera e propria ed è la fase di design, in cui avviene la progettazione e si iniziano a standardizzare i processi e i flussi.
4. Implementazione. Chiamata anche “sviluppo” è la fase nella quale si passa a lavorare concretamente sul progetto realizzando le funzionalità individuate al punto 2 e progettate al punto 3. Solitamente questa fase include anche il testing delle suddette funzionalità.
5. Rilascio. Una volta che il progetto (o meglio, una parte di esso) è pronto lo si rilascia per farvi accedere gli utenti o un gruppo di essi. Questo passo non è assolutamente la fine perché si tratta di un ciclo.
6. Analisi. La fase di analisi o monitoraggio è probabilmente la più importante, perché è quella dove si osservano gli utenti mentre usano il prodotto e questo ci permette di raccogliere informazioni per ricominciare il ciclo.

La nascita del movimento Lean Startup

Eric Ries nel suo best seller “The Lean Startup” (in italiano Partire Leggeri) definisce Lean Startup come “una metodologia di sviluppo business che ha l’obiettivo di accorciare i tempi di sviluppo e scoprire il più rapidamente possibile se un business model è adatto”.

Ciò viene ottenuto con una combinazione di sperimentazioni basate su ipotesi e di feedback raccolti tramite validazione.

Come nel caso di Agile, anche qui possiamo ricondurre le origini di questa metodologia a qualche decennio prima e in particolar modo agli anni 70-80 con il lean manufacturing, un sistema di produzione ideato da Toyota atto a diminuire gli sprechi.

I principi lean erano in giro nella Silicon Valley già a metà degli anni 2000 grazie al guru Steve Blank e al suo libro “The Four Steps to the Epiphany”, ma l’esposizione massima è avvenuta con la pubblicazione del già citato libro di Eric Ries nel 2011. Tra i vari principi del movimento ce ne sono, ancora una volta, due che vale la pena citare e che sono strettamente legati al tema principale di questo post:

• L’apprendimento deve essere validato dagli esperimenti
• La validazione va fatta tramite un ciclo di feedback

Diamo un’occhiata più da vicino al ciclo di lean startup (detto anche Build-Measure-Learn), analizzando velocemente i 3 step che lo compongono:

1. Costruisci. Il primo passo è quello di rilasciare qualcosa sul mercato per farlo provare a utenti reali. Qui la parola chiave è velocità. Non ci interessa che sia il prodotto finito, ma che sia quello realizzabile più velocemente per ottenere feedback validi dagli utenti (tecnicamente chiamato MVP).
2. Misura. Una volta che gli utenti iniziano a interagire con il nostro MVP abbiamo la possibilità di raccogliere informazioni, fare dei test, monitorarne l’utilizzo e così via. Grazie a questi dati possiamo passare all’ultimo step.
3. Impara. Trattandosi di un ciclo è fondamentale che i dati del punto 2 vengano trasformati in insegnamenti che ci permettano di intervenire concretamente sul prodotto, con dei piccoli aggiustamenti o, quando necessario, con dei grossi cambiamenti.

Volendo semplificare in maniera estrema si potrebbe dire che Lean si concentra maggiormente sull’ottimizzazione dell’efficienza di un processo, mentre Agile sposta il focus sulla velocità di un progetto.

Col passare degli anni questi due mondi si sono contaminati a vicenda, spesso le parole lean e agile vengono usate (erroneamente) in maniera intercambiabile e sono nate branche di uno o dell’altro movimento, come agile marketing e lean software development, che provano ad applicare i principi di base in contesti diversi da quelli iniziali.

La nascita del Growth Hacking

Il termine Growth Hacking viene coniato da Sean Ellis nel 2010 con un post sul suo blog nel quale descrive un approccio cross-funzionale alla crescita che lui stesso applicava, come consulente, nelle più importanti startup della Silicon Valley.

In quel post Ellis raccontava di come portava in azienda un team con competenze variegate formato da programmatori, marketer, data analyst, esperti di psicologia, designer e altri.

In questo suo approccio cross-funzionale, la crescita non era più legata unicamente agli aspetti di marketing, ma veniva affrontata in maniera olistica coinvolgendo qualsiasi reparto dell’azienda e in particolar modo il prodotto. È infatti proprio il legame che c’è tra marketing e prodotto a essere uno dei cambi di paradigma più importanti portati dal Growth Hacking. 

Tra i vari principi descritti da Sean Ellis ce ne sono tre sicuramente degni di nota:

• L’approccio alla crescita in modo cross-funzionale
• L’utilizzo di dati qualitativi e quantitativi per prendere decisioni
• La generazione continua di nuove idee da sperimentare

Così come abbiamo fatto per agile e lean startup, osserviamo da vicino i 4 momenti presenti all’interno del ciclo di Growth Hacking:

1. Analisi. Tutto inizia con il raccogliere informazioni, quelli che nel growth hacking vengono chiamati stimoli. Abbiamo stimoli interni come il team, l’esperienza, gli esperimenti condotti in passato e così via, poi abbiamo gli stimoli esterni che sono rappresentati dai competitor, il mercato, i clienti e altro.
2. Ideazione. Nella seconda fase si prendono tutte le informazioni raccolte nel punto precedente e si “condiscono” con una buona dose di creatività per tirare fuori idee da sperimentare.
3. Prioritizzazione. Una volta che abbiamo sul tavolo 20, 50 o 100 idee da testare, come decidiamo da quali partire? Il Growth Hacking utilizza dei framework di prioritizzazione per decidere quali idee scartare, quali promuovere e con quale ordine testarle.
4. Implementazione. Una volta che abbiamo la nostra classifica di esperimenti da fare, si passa alla fase di esecuzione vera e propria. In alcune versioni del ciclo di Growth Hacking questo punto è suddiviso in due parti dove la fase di design è considerata in maniera indipendente. Anche in questo caso la fase di design non è altro che la progettazione dell’esperimento che precede la sua esecuzione vera e propria.

Ho voluto approfondire questi tre mondi e, in particolar modo, scendere nel dettaglio dei vari cicli perché solo mettendoli nero su bianco ed esplodendoli si iniziano a notare delle somiglianze.

Le hai notate anche tu? Alcuni concetti come design, analisi, pianificazione e apprendimento tornano di continuo. Il motivo è presto detto: c’è un altro ciclo a cui tutti i precedenti si ispirano.

PDCA, il padre di tutti i cicli

Faccio un ultimo passettino indietro per illustrare quello che è il padre di tutti i cicli, PDCA chiamato anche “ciclo di Deming”, in onore dello statistico americano William Edwards Deming che, tra le mille attività svolte, si è occupato anche di consulenza di management, guarda un po’, in Giappone.

Deming definì 14 princìpi alla base del suo approccio al management e come sempre ne vorrei estrarre alcuni che a mio avviso sono fondamentali per quello che sto cercando di illustrare in questo post:

• Migliora costantemente e per sempre
• Abbatti le barriere tra i dipartimenti
• La trasformazione dell’azienda è un lavoro che riguarda tutti

Il ciclo PDCA (a volte noto come PDSA) è un metodo di management utilizzato per il controllo e miglioramento sia dei prodotti che dei processi basato su 4 fasi:

1. Pianificare (Plan). È lo step nel quale si definiscono gli obiettivi del progetto, si analizza il problema di partenza, si scelgono i metodi da utilizzare e la strategia da seguire per i prossimi passi.
2. Fare (Do). Una volta completata la pianificazione si passa all’esecuzione vera e propria che, come potrai ormai intuire, non è né completa, né definitiva, ma include quel tanto che basta a raccogliere i dati per il passo successivo.
3. Controllare (Check). Con le informazioni raccolte nel punto 2 siamo in grado di fare un’attività di monitoraggio e controllo per capire cosa ha funzionato e cosa no, su quali aspetti intervenire, cosa eliminare e cosa migliorare. Nella versione PSDA questo passaggio è chiamato “Studiare” invece di “Controllare”, ma il succo è lo stesso.
4. Agire (Act). Ora che abbiamo capito dove sono gli errori e le problematiche possiamo intervenire concretamente per migliorare il prodotto con delle azioni correttive e far si che la prossima iterazione sia migliore della precedente.

Mi fa sempre sorridere la scena in cui qualcuno mi dice con la fronte corrugata “Ma allora il Growth Hacking non ha inventato niente di nuovo!?”.

Mi fa sorridere perché è vero al 100% e questo non ne mina per nulla la sua validità o la sua legittimità.

Si potrebbe obiettare che nessuno crea veramente qualcosa di nuovo, andando a scomodare Antoine-Laurent Lavoisier con il suo famoso “nulla si crea, nulla si distrugge, tutto si trasforma”.

La verità è che il Growth Hacking poggia su delle basi solide, che hanno origini molto lontane e che, col senno di poi potremmo quasi definire come buon senso misto a best practice.

Il senso di questo post è proprio di dimostrare che tutte queste metodologie non sono altro che gli stessi concetti che da decenni applichiamo ad ambiti diversi, adattandoli in base alle esigenze: business, sviluppo, design, marketing, crescita e chi più ne ha più ne metta.

Se vuoi approfondire ulteriormente il tema ti consiglio di dare un’occhiata al mio libro Growth Hacking Mindset.