Nel libro Growth Engineering la crescita è vista come un sistema integrato: prodotto, dati, codice, esperimenti e responsabilità sul risultato. Qui riprendiamo l’idea senza astrarla: decidere la dimensione del campione è una scelta economica prima ancora che statistica.
Molti test partono senza un’idea chiara dell’effetto che vorrebbero rilevare. Poi, quando il risultato resta incerto, il team allunga il test a caso, senza una strategia.
La tesi
Fare un test senza definire l’MDE è come pescare con una rete di cui non conosci la maglia: non sai se il pesce non c’è o se la rete lascia passare tutto.
Non si tratta di aggiungere uno strumento al marketing o una dashboard al prodotto. L’obiettivo è costruire un meccanismo che accorcia la distanza tra il segnale e la decisione. Un buon sistema di growth non promette certezze, riduce il costo dell’incertezza.
Nel lavoro di tutti i giorni questo cambia anche come scrivi il codice. Una modifica non è completa quando passa in produzione, ma quando puoi osservarla, confrontarla con un’ipotesi e trasformarla in una scelta: rilasciare, iterare, fermare o approfondire.
Schema operativo
- Baseline
- Effetto minimo utile (MDE)
- Potenza statistica
- Livello di errore accettabile
- Durata massima del test
- Decisione di business
Lo schema è semplice di proposito. La complessità arriva quando crescono traffico, segmenti, canali e automazioni. Se il flusso base non si riduce a cinque o sei passaggi chiari, probabilmente il team sta automatizzando un processo che non ha ancora capito.
Esempio pratico
Se il checkout converte al 4% e vuoi rilevare un miglioramento dello 0,1%, potresti aver bisogno di molto più traffico di quanto il business sia disposto ad aspettare.
Il punto non è il singolo intervento, è il legame tra intervento e apprendimento. Se il risultato migliora, il team sa cosa scalare; se non migliora, sa quale convinzione correggere. In entrambi i casi il sistema diventa più intelligente.
Metriche da monitorare
- MDE
- Potenza statistica
- Conversione di baseline
- Costo opportunità del test
Non vanno trattate come decorazioni. Devono stare in una scorecard sintetica, letta con regolarità, con una decisione associata. Se una metrica non influenza nessuna scelta, è probabilmente una metrica di conforto.
Errore tipico da evitare
Inseguire la significatività su effetti troppo piccoli per cambiare qualcosa nel business.
È un errore frequente perché sembra produttivo: genera attività, riunioni, grafici, a volte entusiasmo. Ma il growth engineering non misura il valore sul numero di cose fatte, lo misura sulla qualità del ciclo di apprendimento che rimane.
Checklist per il team
- Quale decisione deve diventare più chiara?
- Quale evento o fonte dati rende osservabile il comportamento?
- Quale rischio non vogliamo peggiorare mentre ottimizziamo?
- Chi può davvero cambiare il processo dopo aver letto il risultato?
Se anche una risposta resta vaga, conviene fermarsi prima di implementare. La velocità vera non è partire subito, è non dover rifare il lavoro per ipotesi, dati o criteri di decisione confusi.
Lettura pratica
In un mondo guidato dall’AI il growth fatto male diventerà ancora più rumoroso. Sarà facile generare idee, testi, segmenti e automazioni, e sempre più raro costruire sistemi che distinguono il segnale dal rumore.
Per questo il growth engineer dei prossimi anni non sarà solo un tecnico, ma anche chi progetta prove, limiti, feedback e memoria operativa. Chi ci riesce non insegue l’AI, la integra in un processo controllabile.
Cosa fare adesso
Prima di mettere mano alla statistica, chiediti: qual è il miglioramento minimo che giustifica implementazione, manutenzione e rischio?
Portare questa domanda in review è già un atto di growth engineering: sposta la conversazione dalle opinioni generiche a un sistema che può imparare.