Nel libro Growth Engineering la crescita è un sistema integrato, dove prodotto, dati, codice, esperimenti e responsabilità operativa stanno insieme. Qui riprendo quella prospettiva senza farne teoria astratta. Un esperimento condotto bene riduce l’incertezza, e lo fa anche quando non fa salire di un punto i numeri.
Molti team trattano gli A/B test come gare di bellezza. Variante A contro variante B, chi vince si prende la roadmap. È un modo limitato di guardarli.
La tesi
Un test non è una slot machine. È più simile a un microscopio: serve a vedere meglio un meccanismo che prima restava nascosto.
Il punto non è aggiungere l’ennesimo strumento al marketing o un’altra dashboard al prodotto. Voglio un meccanismo che acceleri il passaggio dal segnale alla decisione. Un buon sistema di growth non promette certezze. Abbassa il costo dell’incertezza, che è una cosa diversa.
Anche il modo di scrivere codice cambia, di conseguenza. Una modifica non è finita quando la rilasci. È finita quando puoi osservarla, confrontarla con un’ipotesi e trasformarla in una scelta: rilasciare, iterare, fermare o approfondire.
Schema operativo
- Domanda
- Ipotesi causale
- Intervento
- Metrica primaria
- Guardrail
- Decisione possibile
Lo schema è semplice di proposito. La complessità arriva dopo, quando crescono traffico, segmenti, canali e automazioni. Se il flusso di base non sta in cinque o sei passaggi chiari, di solito vuol dire che stai automatizzando un processo che non hai ancora capito.
Esempio pratico
Mettiamo che una nuova checklist di onboarding non sposti l’activation. Può comunque dirti qualcosa di utile: magari il problema non era la sequenza dei passi ma la qualità del dato importato.
La parte che conta non è il singolo intervento, è il filo che lega l’intervento all’apprendimento. Se il risultato migliora sai cosa scalare. Se non migliora sai quale convinzione devi correggere. In tutti e due i casi il sistema impara qualcosa.
Metriche da guardare
- Decision rate
- Learning rate
- Uplift stimato
- Impatto sui guardrail
Non sono numeri decorativi. Devono stare in una scorecard corta, che qualcuno legge davvero a cadenza regolare, e ognuna deve essere legata a una decisione. Se una metrica non cambia mai una scelta, è solo una metrica di conforto.
Errore tipico da evitare
Lanciare esperimenti senza sapere già che decisione ci tireremo fuori. Se non sai cosa farai dei risultati, stai solo producendo grafici.
Capita spesso perché sembra produttivo. Genera attività, riunioni, grafici, a volte pure entusiasmo. Ma nel growth engineering il valore non si misura da quante cose hai fatto, si misura da quanto ti resta in mano alla fine del ciclo di apprendimento.
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 sola risposta resta vaga, conviene fermarsi prima di implementare. La velocità vera non è partire subito. È non dover rifare il lavoro perché ipotesi, dati o criteri di decisione erano confusi in partenza.
Lettura pratica
Con l’AI ovunque, il growth fatto male diventerà ancora più rumoroso. Generare idee, testi, segmenti e automazioni costerà quasi niente. Costruire sistemi che separano il segnale dal rumore resterà raro.
Ecco perché il growth engineer del prossimo ciclo non sarà solo un tecnico. Sarà qualcuno che sa progettare prove, limiti, feedback e una memoria operativa. Chi ci riesce non insegue l’AI, se la mette dentro un processo che controlla.
Cosa fare adesso
Prima di ogni test, scrivilo nero su bianco: se vince A faremo X, se vince B faremo Y, se non cambia nulla impareremo Z.
Portare questa domanda nella prossima review è già un piccolo atto di growth engineering. Sposta la conversazione dalle opinioni generiche a un sistema che può imparare.