Cosa fa davvero un GTM Engineer (e perché il problema non è mai il tuo stack)

Cos'è un GTM Engineer

Il termine è nato nel 2023, coniato nell'ecosistema di Clay, e descrive una figura ibrida che prima semplicemente non aveva un nome. Mette insieme tre competenze che di solito vivono in persone diverse: la comprensione commerciale (come si vende, dove muoiono le trattative, cosa qualifica un lead), la capacità tecnica (API, automazione, un po' di codice, logica dei dati) e il pensiero di sistema (come i pezzi si incastrano in una motion ripetibile).

In concreto, un GTM Engineer costruisce cose come: un motore di outbound che identifica i segnali giusti, arricchisce i contatti con dati affidabili e personalizza il messaggio su scala; la logica che fa fluire i lead nel CRM con lo stato giusto; le automazioni che tolgono lavoro manuale ripetitivo senza togliere il controllo umano; le dashboard di KPI che fanno prendere decisioni invece di decorare una slide.

La differenza con un commerciale che "usa Apollo e Instantly" è netta: il commerciale opera il sistema, il GTM Engineer lo progetta e lo costruisce in modo che regga, si misuri e si possa modificare. È la differenza tra guidare l'auto e progettarla.

GTM Engineer vs RevOps vs Sales Ops

La confusione è normale, perché i tre ruoli si sovrappongono molto — secondo l'analisi di Bloomberry sui job posting, GTM Engineer e RevOps condividono circa nove decimi delle responsabilità, e il titolo è ancora in assestamento. Detto questo, una distinzione utile esiste.

Sales Ops è storicamente focalizzato sull'efficienza del team commerciale: processi, territori, forecast, igiene del CRM. Guarda dentro le vendite.

RevOps allarga lo sguardo: allinea marketing, sales e customer success attorno a un'unica fonte di verità sui ricavi, rompendo i silos tra funzioni. È più strategico e più trasversale.

GTM Engineer è la versione più build-oriented e tecnica: dove RevOps spesso definisce processi e governance, il GTM Engineer scrive l'automazione, integra le API, costruisce il sistema di outbound. Più mani sul motore, meno riunioni di allineamento.

Nella pratica, in un'azienda piccola, la stessa persona fa spesso tutti e tre. La distinzione conta più quando l'organizzazione cresce e i ruoli si specializzano.

Lo stack non è il problema. Il design lo è

Ecco il punto che separa chi capisce questa figura da chi pensa di assumere "uno che smanetta coi tool". Il riflesso più comune, quando il commerciale non funziona, è guardare lo stack: forse serve un CRM migliore, forse questo nuovo strumento di enrichment, forse Instantly invece di un altro. È eccitante quanto inutile, perché sposta il problema dentro un'interfaccia nuova senza risolverlo.

Gli strumenti eseguono la logica che gli dai. Logica rotta in un tool migliore resta logica rotta, solo con una UI più bella e una fattura più alta. Un CRM nuovo non sistema un processo di vendita rotto: ti dà un posto più ordinato dove guardare le stesse trattative arenarsi nello stesso punto. E la migrazione costa settimane di lavoro del team, durante le quali il problema vero resta intatto.

Un GTM Engineer competente fa l'opposto del tool-shopping: definisce prima il sistema — chi contatti, cosa dici, cosa succede dopo la risposta, quali numeri guardi — e poi sceglie lo strumento che esegue quella logica nel modo più economico da mantenere nel tempo. La sequenza è tutto. Lo strumento è una scelta reversibile; il design del sistema è ciò che determina se funziona.

Un esempio: da segnale a ricavo

Per rendere concreto cosa significa "progettare un sistema", ecco la spina dorsale di un motore di outbound vero — mascherato — che ho costruito in un contesto B2B.

Non parte dagli strumenti, parte dalla domanda: chi ha davvero il problema che risolviamo, e da quale segnale osservabile lo riconosco? Definito quello, il sistema identifica le aziende che emettono quel segnale, le arricchisce con dati affidabili secondo regole esplicite, e solo all'ultimo miglio usa l'AI per personalizzare il messaggio su fatti reali — non inventati. Il messaggio porta a un processo che prende la risposta e la accompagna verso la call con passi concordati, non lasciati al caso. Ogni stadio ha un KPI: non "email inviate" (vanità), ma reply rate, SQL, costo per SQL (verità).

Il risultato non era "un'AI che manda email". Era un sistema in cui ogni pezzo aveva una ragione, un numero e un proprietario — e che un'altra persona poteva far girare senza di me. Se togli il modello AI, il sistema regge lo stesso, solo meno fine. Se togli la logica, hai solo un generatore di spam educato.

Le competenze reali (e quando un'azienda ne ha bisogno)

Lo skill set di un GTM Engineer efficace, nella mia esperienza: comprensione del ciclo di vendita end-to-end; padronanza degli strumenti di outbound e dati (Apollo, Instantly, Sales Navigator e simili); automazione (n8n o equivalenti) e quel tanto di codice — SQL, un po' di Python, API/webhook — che serve a connettere ciò che i tool no-code non connettono; e, sopra tutto, il pensiero di sistema che decide cosa va costruito e perché.

Un'azienda ne ha bisogno quando la crescita commerciale smette di essere ripetibile: quando ogni nuovo cliente sembra un caso a sé, quando il team passa più tempo a fare lavoro manuale che a vendere, quando nessuno sa dire con precisione dove muoiono le trattative. Non serve, invece, quando il problema è ancora di posizionamento o di prodotto: lì un GTM Engineer costruirebbe un sistema efficiente per vendere qualcosa che il mercato non ha ancora validato.

FAQ

Qual è la differenza tra GTM Engineer e RevOps?

Si sovrappongono molto. In sintesi: RevOps definisce processi, governance e allineamento tra funzioni; il GTM Engineer è più tecnico e build-oriented, costruisce concretamente automazioni, integrazioni e sistemi di outbound. In aziende piccole spesso è la stessa persona.

Un GTM Engineer deve saper programmare?

Non a livello di un software engineer. Serve abbastanza codice — SQL, Python di base, API e webhook — da connettere ciò che i tool no-code non connettono, e da costruire logica deterministica dove serve. La competenza centrale resta il design del sistema, non il codice in sé.

Perché si dice che il problema non è lo stack?

Perché gli strumenti eseguono la logica che ricevono. Un sistema mal progettato su un tool migliore resta mal progettato. Il valore sta nel definire il sistema — targeting, messaggio, processo, metriche — prima di scegliere gli strumenti che lo eseguono.

Gli strumenti cambiano ogni sei mesi. Il sistema no. Ed è il sistema, non lo stack, ciò che un GTM Engineer è pagato per progettare.