Due terzi del nostro lavoro di deploy ora viene svolto in autonomia dal nostro prodotto (tramite Duet).
Questo post spiega perché, qual è la nostra filosofia sul costruire un prodotto e un motion di deploy, e come si è evoluta nel tempo.
Qualcosa che un tempo snobbavamo ora è la risposta predefinita
"Forward deployed engineer" è diventata la risposta a quasi ogni domanda difficile nel go-to-market dell'AI. I deploy sono dolorosi? Assumi FDE. I clienti non riescono a fare da soli? FDE. Il prodotto non è pronto? FDE. Anthropic e OpenAI hanno entrambi creato divisioni di enterprise deployment esplicitamente modellate su Palantir, e ogni startup in fase seed con cui parlo ora ha un annuncio di lavoro per FDE. Le offerte di lavoro per questo ruolo, secondo quanto riportato, sono aumentate di diverse centinaia di punti percentuali nell'ultimo anno.
La cosa strana è che fino a pochissimo tempo fa era una cosa per cui venivi criticato. Piazzare ingegneri presso i clienti era visto come il segno che non avevi un vero prodotto: i tuoi ricavi erano di qualità inferiore e i tuoi margini erano strutturalmente limitati. Nulla è cambiato nell'economia sottostante.
Il punto chiave degli FDE è che producono risultati. Questo è fantastico nell'era dell'AI, perché le aziende potrebbero non sapere con certezza quale sia il percorso per arrivare al risultato, ma è chiaro che l'AI offre risultati convincenti.
Allo stesso tempo, questo ruolo sta diventando abusato e non dovrebbe essere una stampella per nascondere un problema strutturale.
"Gli FDE mangiano dolore ed espellono prodotto"
Palantir (da cui proviene il mio cofondatore @AshwinSreenivas) ha reso popolare questo ruolo a metà degli anni 2000 vendendo Gotham a CIA, NSA e unità di intelligence dell'Esercito. E hanno subito le critiche per molto tempo. Joe Lonsdale, uno dei cofondatori, ha scritto che per gran parte di due decenni la visione mainstream di Palantir era che fosse una consulenza glorificata piuttosto che una vera azienda tecnologica, e che questa visione si basava su un'osservazione vera: molti dei loro ingegneri passavano molto tempo a stretto contatto con i clienti.
Ma Shyam Sankar, CTO di Palantir, aveva una frase che ripeteva in continuazione: gli FDE mangiano dolore ed espellono prodotto.
Le prime implementazioni di Gotham da parte di Palantir erano profondamente su misura, costruite per rispondere a una singola domanda di intelligence per una singola unità. Palantir ha codificato i problemi che ha riscontrato come primitive di piattaforma: ontologia, modelli di oggetti, permessi, motori di workflow, tracciamento della provenienza. Quelle primitive sono diventate Foundry. Foundry è diventato ciò che potevi vendere commercialmente. Apollo e AIP hanno seguito lo stesso percorso.
Niente di tutto ciò sarebbe esistito senza ingegneri che prima si mangiassero il dolore sul campo. Il dolore era l'input del prodotto, non un costo di vendita.
Con la maturità di Foundry, i deploy standardizzati hanno ridotto drasticamente la necessità di lavoro personalizzato, i margini lordi sono saliti oltre l'80% e Palantir è passata da un approccio guidato dagli FDE a uno basato sull'account-based selling. Molti di quegli FDE sono confluiti nel core engineering. È inoltre noto che hanno rifiutato contratti in cui il cliente voleva semplicemente un'Accenture con software migliore.
Il team FDE non era il modello di business. Era il modo per costruire il prodotto giusto.
Perché alcune startup AI hanno davvero bisogno degli FDE adesso
Se nel 2015 stavi costruendo un CRM SaaS, non dovevi scoprire il workflow. Vent'anni di persone avevano già pensato a cos'è una pipeline, cos'è una fase, come appare un passaggio di lead.
Se nel 2026 stai costruendo un agente AI per la contabilità, non esiste un workflow consolidato, perché letteralmente nessuno ha mai usato uno di questi. Nessuno sa come sia il percorso dell'utente — non tu, e soprattutto non il tuo cliente. Non possono dirti cosa vogliono, perché la cosa che vorrebbero non ha ancora una forma.
È la stessa situazione in cui è partita Palantir. La lettura di Lonsdale era che erano andati forward-deployed per necessità: avevano una tecnologia forte e nessuna idea di come funzionassero davvero i loro primi clienti nel settore difesa e intelligence.
Quindi sì, manda ingegneri. Siediti nella stanza. Guarda la tua creatura rompersi in modi che i tuoi test non avrebbero mai immaginato. In una categoria davvero nuova, l'ultimo miglio non è un problema di consegna, ma di scoperta, e non c'è sostituto dell'essere lì.
La trappola non è iniziare. È non smettere.
Una volta che sai quali sono realmente i percorsi degli utenti, dovresti iniziare a fare a meno degli FDE.
Non vorrai farlo. Non perché qualcuno prenda una decisione sbagliata, ma perché tenerli è più facile in ogni singolo sprint.
Gli FDE ti permettono di evitare ogni difficile compromesso di prodotto. Non devi mai decidere cosa fa il prodotto, o quale di due richieste dei clienti vince, o dove finisce lo spazio di configurazione. Sembra non costare nulla. Nessuno deve dire no a nessuno. Nessuna dolorosa decisione architetturale viene presa. Il cliente è entusiasta.
E ora hai tutti gli svantaggi del modello e nessuno dei benefici della scoperta. Il tuo costo di servizio non diminuisce. I tuoi margini restano limitati. La tua crescita è vincolata alle assunzioni. Ogni fix su misura sul campo è una decisione di prodotto che hai scelto di non prendere. Ogni deploy dovrebbe rendere il successivo più facile.
Inoltre, pochissime startup riescono a chiudere gli accordi a otto cifre che Palantir otteneva fin da subito, il che rende l'economia ancora più difficile da sostenere.
Un'altra cosa da non confondere
L'FDE non è nemmeno la stessa cosa dell'implementazione. "Costruisci questa integrazione nel loro sistema di ticketing" è un lavoro reale e necessario, ma è esecuzione rispetto a una specifica nota, non scoperta di una specifica sconosciuta. Mettere entrambe le cose sotto un unico titolo è il modo in cui le aziende convincono se stesse che un'organizzazione di servizi in crescita sia un investimento sul prodotto.
I modelli scrivono codice abbastanza bene ormai che gran parte di ciò che un team di implementazione faceva nel 2023 sta diventando qualcosa che il prodotto fa da solo. Alla fine potrai costruire un agente che svolga tutto il lavoro dell'ultimo miglio end-to-end. Potrà osservare i workflow e persino intervistare i clienti.
Cosa abbiamo fatto, invece
Nel nostro caso specifico con @DecagonAI, crediamo fermamente che l'approccio product-driven sia la risposta, piuttosto che un approccio basato sui servizi o sugli FDE. L'assistenza clienti è ad alto volume, ripetibile e scomponibile, e quando parliamo con le aziende, due cose sono sempre costanti:
- La velocità di iterazione è fondamentale. Rilasciare un agente AI non è un'operazione una tantum. Deve essere costantemente ottimizzato e aggiornato nel tempo. Se ogni modifica richiede interventi di ingegneria, sarà troppo lento e costoso per scalare.
- Vendor lock-in e sovranità. Data l'esperienza delle organizzazioni con i SaaS, nessuno vuole essere vincolato a un fornitore e dipendere dalle sue risorse.
Agli inizi, io e Ashwin costruivamo personalmente qualsiasi cosa i clienti chiedessero. Quando il prodotto ha cominciato a decollare, abbiamo preso la decisione esplicita che la nostra proposta di valore centrale sarebbe stata avere il miglior prodotto.
Per essere chiari, collaboriamo ancora con il cliente per fornire il risultato end-to-end. Tuttavia, anche in questo processo, lo sviluppo resta nelle nostre mani, mentre abilitiamo il loro team sul nostro prodotto e diamo loro le chiavi. Con la maturità del prodotto, il lavoro specifico per il cliente svolto dal nostro team di ingegneria è diminuito drasticamente.
Quella decisione ha avuto i suoi compromessi. Ha significato non mettere insieme alla meno peggio qualcosa sul campo quando sarebbe stato più veloce. Ha significato prendere le escalation e trasformarle in requisiti anziché in patch, il che richiede tempo nel breve termine.
Il beneficio:
- Due terzi del lavoro di deploy ora avviene in autonomia tramite Duet: configurazione, iterazione, la lunga coda di ottimizzazioni che prima richiedeva una persona nel loop.
- Ora bastano in media pochi giorni per lanciare il primo AOP, anche per grandi banche, compagnie aeree, telco, ecc.
C'è ancora molto lavoro da fare, ma siamo in cammino.
Quindi: FDE, sì o no?
Inizia subito con l'approccio forward-deployed. Cogli il segnale. Metti i tuoi ingegneri davanti ai clienti per sempre.
Poi fai le domande vere. Il lavoro su misura sta nell'ambiente del tuo cliente o nei gap del tuo prodotto? L'ultimo miglio è irriducibile o semplicemente non è stato ancora costruito? I tuoi FDE stanno scoprendo qualcosa o assorbendo qualcosa? E cosa è stato integrato nel prodotto l'ultima volta che uno di loro è tornato?
Usa gli FDE per capire cosa deve esistere nel prodotto. Gli FDE mangiano dolore ed espellono prodotto. Se i tuoi stanno mangiando dolore ed espellendo altro dolore, non hai un team FDE. Hai un'azienda di servizi.
