Un growth engineer non è uno sviluppatore prestato al marketing, e non è nemmeno un data analyst con accesso al codice. È chi costruisce prodotti pensati per imparare dal comportamento reale degli utenti, e per trasformare l’incertezza in informazioni che servono a decidere.
Con gli agenti AI questo ruolo conta ancora di più. Un agente AI non è solo una funzionalità in più: è un sistema che osserva, decide, usa strumenti e produce effetti sul prodotto. Qualcuno deve renderlo misurabile, tenerlo sotto controllo e migliorarlo nel tempo.
Cosa fa davvero
Il lavoro quotidiano tocca molte cose:
- strumentazione eventi;
- pipeline dati;
- esperimenti;
- feature flag;
- integrazione strumenti;
- guardrail;
- valutazione output;
- rollout graduali;
- debugging di comportamenti inattesi.
E sotto a tutto questo c’è una domanda che non lo abbandona mai mentre scrive codice: come faremo a capire se questa cosa funziona?
Velocità e rigore
Nel growth alcune soluzioni nascono per imparare in fretta. Veloce, però, non vuol dire casuale. Anche un prototipo di agente AI deve avere:
- perimetro chiaro;
- log minimi;
- dati autorizzati;
- fallback;
- metrica di successo;
- guardrail.
Sono questi elementi a separare un prototipo utile dal caos.
Collaborazione
Il growth engineer traduce le domande di business in sistemi misurabili, e lo fa lavorando fianco a fianco con PM, designer, analyst, marketing e supporto. Una richiesta come “Vogliamo un agente che migliori l’onboarding” va smontata in domande precise:
- quale segmento di utenti?
- in quale momento?
- per quale task?
- quale evento di attivazione?
- quali rischi?
- quale test?
Questa traduzione è il cuore del mestiere.
Nuove competenze
Con l’AI entrano in gioco competenze nuove:
- comprendere i limiti dei modelli;
- progettare prompt robusti;
- gestire tool calling;
- valutare output non deterministici;
- prevenire prompt injection;
- progettare human-in-the-loop.
Non serve diventare ricercatori AI. Serve saper ingegnerizzare sistemi che usano modelli intelligenti.
Come applicarlo senza complicare il lavoro
Non partire dallo strumento più nuovo. Parti dal punto in cui il team perde tempo, discute senza dati o decide con informazioni incomplete. Solo lì capisci se il tema ha un valore operativo o è una bella idea da slide.
Un esperimento non serve a dimostrare che avevi ragione. Serve a ridurre l’incertezza, a proteggere il budget e a trasformare una discussione in una decisione che puoi osservare.
Una sequenza utile:
- scrivi un’ipotesi falsificabile;
- scegli una metrica primaria e una guardrail;
- definisci durata minima, campione atteso e criterio di stop;
- documenta anche i risultati neutri.
Cosa misurare per capire se funziona
La domanda giusta non è “abbiamo usato AI?” o “abbiamo aggiunto una dashboard?”. È un’altra: quale decisione è diventata più veloce, più chiara o più sicura? Se non cambia una decisione, il progetto rischia di restare una decorazione tecnica.
Misura almeno tre livelli: il tempo operativo risparmiato, la qualità del risultato e la fiducia del team nel processo. Il tempo da solo inganna, e anche la qualità da sola inganna. Un flusso più rapido ma meno controllabile non è un miglioramento, così come un sistema perfetto ma troppo lento non entra mai nel lavoro quotidiano.
Poi c’è un controllo concreto: chiedi a chi userà il processo cosa farebbe domani con questa informazione. Se la risposta è vaga, manca il collegamento chiaro tra dato, responsabilità e azione.
Collegamento con il percorso ginnytech
Per trasformare questo ragionamento in competenza pratica, collega questo articolo al percorso Learning Path GinnyTech. L’obiettivo è costruire un modo di lavorare in cui dati, modelli e persone collaborano senza perdere il controllo.
La riflessione
Il growth engineer dei prossimi anni non misura solo i funnel, ma i cicli di apprendimento. Il suo valore non sta nello spedire più feature, ma nel costruire prodotti che a ogni iterazione diventano più chiari, più affidabili e più utili. L’AI non cancella questo ruolo, lo rende più strategico.