Nel libro Growth Engineering la crescita è un lavoro di sistema: tiene insieme prodotto, dati, codice, esperimenti e responsabilità operativa. Riprendo quella prospettiva senza astrarre troppo. La crescita smette di essere un elenco di iniziative e diventa un sistema che produce apprendimento.
Tante aziende chiamano growth qualunque cosa faccia salire traffico o lead per qualche settimana. Il guaio è che appena finisce la spinta il motore si spegne.
La tesi
Una campagna è una torcia: illumina forte, ma per poco. Un sistema di growth è la rete elettrica: progettarla costa di più, però poi alimenta molte decisioni nel tempo.
Non stiamo aggiungendo un tool al marketing o una dashboard al prodotto. L’obiettivo è un meccanismo che rende più rapido il passaggio dal segnale alla decisione. Un buon sistema di growth non promette certezze: riduce il costo dell’incertezza.
E cambia anche il modo di scrivere 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 studiare meglio.
Schema operativo
- Definire il comportamento da migliorare
- Strumentare gli eventi minimi
- Costruire un loop di feedback
- Rilasciare piccoli esperimenti
- Trasformare i risultati in regole riusabili
Lo schema è semplice di proposito. La complessità arriva dopo, quando crescono traffico, segmenti, canali e automazioni. Se il flusso base non sta in cinque o sei passaggi chiari, probabilmente il team sta automatizzando un processo che non ha ancora capito.
Esempio pratico
Un team SaaS non dovrebbe fermarsi a lanciare una promozione. Deve collegare onboarding, eventi prodotto, email, esperimenti e dashboard, così che ogni nuovo utente insegni qualcosa sul prossimo.
La cosa che vale non è il singolo intervento, ma il legame tra intervento e apprendimento. Se il risultato migliora, sai cosa scalare. Se non migliora, sai quale convinzione correggere. In entrambi i casi il sistema diventa più intelligente.
Metriche da guardare
- Activation rate
- Time to value
- Retention a 7 giorni
- Percentuale di esperimenti con decisione chiara
Non sono decorazioni. Devono entrare in una scorecard corta, letta sul serio e con regolarità, a cui è associata una decisione. Una metrica che non cambia nessuna scelta è quasi sempre una metrica di conforto.
Errore tipico da evitare
Confondere la crescita con l’acquisizione. Se entrano più utenti ma il prodotto non impara nulla, stai solo comprando rumore.
L’errore è comune perché sembra produttivo: genera attività, riunioni, grafici e spesso entusiasmo. Ma il growth engineering non misura il valore dal numero di cose fatte, bensì dalla qualità del ciclo di apprendimento che resta.
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ò cambiare davvero 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.
Lettura pratica
In un mondo guidato dall’AI il growth debole diventerà ancora più rumoroso. Generare idee, testi, segmenti e automazioni sarà facile. Costruire sistemi che distinguono il segnale dal rumore resterà molto più raro.
Per questo il growth engineer del futuro non sarà solo una figura tecnica. Sarà qualcuno capace di progettare prove, limiti, feedback e memoria operativa. Chi sa farlo non insegue l’AI: la integra in un processo che resta sotto controllo.
Cosa fare adesso
Scegli un punto del percorso utente e chiediti: quale segnale di oggi può migliorare la decisione di domani?
Portare questa domanda nella prossima review è già un piccolo atto di growth engineering: sposta il discorso dalle opinioni generiche a un sistema che può imparare.