Dois terços do nosso trabalho de implantação agora são feitos de forma autônoma pelo nosso próprio produto (via Duet).
Este post é sobre o porquê disso, nossa filosofia para construir um produto e nossa abordagem de implantação, e como isso evoluiu ao longo do tempo.
Algo que costumávamos desprezar agora é a resposta padrão
"Forward deployed engineer" se tornou a resposta para quase todas as perguntas difíceis no go-to-market de IA. Implantações são dolorosas? Contrate FDEs. Clientes não conseguem se autoatender? FDEs. Produto não está pronto? FDEs. A Anthropic e a OpenAI criaram braços de implantação empresarial explicitamente modelados na Palantir, e toda empresa em estágio seed com quem converso agora tem uma vaga de FDE aberta. As vagas para esse cargo supostamente cresceram várias centenas de por cento no último ano.
O que é estranho é que isso, até muito recentemente, era algo pelo qual você era criticado. Implantar engenheiros nos clientes era visto como sinal de que você não tinha um produto de verdade: sua receita era de menor qualidade e suas margens eram estruturalmente limitadas. Nada mudou na economia subjacente.
O ponto-chave dos FDEs é que eles entregam resultados. Isso é incrível na era da IA, porque as empresas podem não ter certeza de qual é o caminho para chegar ao resultado, mas é claro que a IA produz resultados convincentes.
Ao mesmo tempo, o papel está se tornando superutilizado e não deveria ser uma muleta para esconder um problema estrutural.
"FDEs comem dor e excretam produto"
A Palantir (de onde veio meu cofundador @AshwinSreenivas) popularizou o papel em meados dos anos 2000 vendendo o Gotham para a CIA, a NSA e unidades de inteligência do Exército. E eles aguentaram as críticas por muito tempo. Joe Lonsdale, um dos cofundadores, escreveu que, durante quase duas décadas, a visão dominante sobre a Palantir era que ela era uma consultoria glorificada em vez de uma empresa de tecnologia de verdade, e que essa visão se baseava em uma observação verdadeira: muitos dos seus engenheiros passavam muito tempo sentados com clientes.
Mas Shyam Sankar, CTO da Palantir, tinha uma frase que repetia constantemente: FDEs comem dor e excretam produto.
As primeiras implantações do Gotham na Palantir eram profundamente sob medida, construídas para responder a uma pergunta de inteligência para uma unidade específica. A Palantir codificou os problemas que via como primitivas de plataforma: ontologia, modelos de objetos, permissões, mecanismos de workflow, rastreamento de proveniência. Essas primitivas se tornaram o Foundry. O Foundry se tornou o que você podia vender comercialmente. Apollo e AIP seguiram o mesmo caminho.
Nada disso teria existido sem engenheiros comendo dor em campo primeiro. A dor era o insumo do produto, não um custo de venda.
Conforme o Foundry amadureceu, as implantações padronizadas reduziram drasticamente a necessidade de trabalho customizado, as margens brutas subiram para a casa dos 80%, e a Palantir migrou de uma abordagem liderada por FDEs para vendas baseadas em contas. Muitos desses FDEs migraram para a engenharia principal. Eles também ficaram famosos por recusar contratos em que o cliente só queria uma Accenture com software melhor.
O time de FDEs não era o modelo de negócios. Era o caminho para construir o produto certo.
Por que algumas startups de IA realmente precisam de FDEs agora
Se você estivesse construindo um CRM SaaS em 2015, não precisava descobrir o workflow. Vinte anos de pessoas já tinham pensado sobre o que é um pipeline, o que é um estágio, como é uma transferência de lead.
Se você está construindo um agente de IA para contabilidade em 2026, não existe um workflow estabelecido, porque literalmente ninguém nunca usou um desses. Ninguém sabe como é a jornada do usuário — nem você e, importante, nem o seu cliente. Eles não conseguem te dizer o que querem, porque a coisa que eles iriam querer ainda não tem forma.
É a mesma situação em que a Palantir começou. A leitura de Lonsdale era que eles partiram para o modelo forward-deployed por necessidade: tinham tecnologia forte e nenhuma ideia de como seus primeiros clientes de defesa e inteligência realmente funcionavam.
Então sim, mande engenheiros. Sente na sala. Veja sua solução quebrar de maneiras que seus testes nunca imaginaram. Em uma categoria genuinamente nova, a última milha não é um problema de entrega, é um problema de descoberta, e não há substituto para estar lá.
A armadilha não é começar. É não parar.
Quando você sabe quais são as jornadas do usuário de verdade, deve começar a tirar os FDEs do campo.
Você não vai querer. Não porque alguém toma uma decisão ruim, mas porque mantê-los é mais fácil em cada sprint.
FDEs permitem que você evite todo tradeoff difícil de produto. Você nunca precisa decidir o que o produto faz, qual das duas solicitações de clientes vence ou onde termina a superfície de configuração. Parece grátis. Ninguém precisa dizer não para ninguém. Nenhuma decisão arquitetural dolorosa é tomada. O cliente fica encantado.
E agora você tem todas as desvantagens do modelo e nenhum dos benefícios da descoberta. Seu custo de atendimento não cai. Suas margens permanecem limitadas. Seu crescimento é limitado por contratações. Cada correção sob medida em campo é uma decisão de produto que você escolheu não tomar. Cada implantação deve tornar a próxima mais fácil.
Além disso, pouquíssimas startups conseguem fechar os negócios de 8 dígitos que a Palantir fechava logo de cara, o que torna a economia ainda mais difícil de sustentar.
Mais uma coisa para não confundir
FDE também não é a mesma coisa que implementação. "Construir essa integração no sistema de ticketing deles" é um trabalho real e necessário, mas é execução contra uma especificação conhecida, não descoberta de uma desconhecida. Agrupar os dois sob um mesmo cargo é como as empresas se convencem de que uma organização de serviços em crescimento é um investimento em produto.
Os modelos já escrevem código bem o suficiente para que muito do que um time de implementação fazia em 2023 esteja se tornando algo que o próprio produto faz. Eventualmente, você será capaz de construir um agente que faz todo o trabalho de última milha de ponta a ponta. Ele pode observar workflows e até entrevistar clientes.
O que fizemos em vez disso
No nosso caso específico com a @DecagonAI, acreditamos fundamentalmente que uma abordagem orientada a produto é a resposta, em vez de uma orientada a serviços ou a FDEs. Atendimento ao cliente é de alto volume, repetível e decomponível, e quando falamos com empresas, duas coisas são sempre consistentes:
- Velocidade de iteração é essencial. Lançar um agente de IA não é uma coisa pontual. Ele precisa ser constantemente ajustado e atualizado ao longo do tempo. Se cada ajuste exigir engenharia, será lento demais e caro demais para escalar.
- Vendor lock-in e soberania. Dada a experiência das organizações com SaaS, ninguém quer ficar preso a um fornecedor e depender dos recursos dele.
Nos primeiros dias, eu e o Ashwin construíamos pessoalmente o que os clientes pedissem. Conforme o produto decolou, tomamos a decisão explícita de que nossa proposta de valor central seria ter o melhor produto.
Para ser claro, ainda fazemos parceria com o cliente para entregar o resultado de ponta a ponta. No entanto, mesmo nesse processo, somos donos da construção, enquanto capacitamos o time deles no nosso produto e damos a eles as chaves. Conforme o produto amadureceu, o trabalho específico para clientes que nosso time de engenharia fazia caiu drasticamente.
Essa decisão teve seus tradeoffs. Significou não fazer algo improvisado em campo quando isso teria sido mais rápido. Significou pegar escalações e transformá-las em requisitos em vez de patches, o que leva tempo no curto prazo.
O retorno:
- Dois terços do trabalho de implantação agora acontecem de forma autônoma através do Duet: configuração, iteração, a cauda longa de ajustes que costumava exigir um humano no circuito.
- Agora leva apenas alguns dias, em média, para lançar o primeiro AOP, até para grandes bancos, companhias aéreas, operadoras de telecom, etc.
Ainda há muito trabalho a fazer, mas estamos na jornada.
Então: FDE ou não FDE?
Vá de forward-deployed cedo. Capte o sinal. Coloque seus engenheiros na frente dos clientes para sempre.
Então faça as perguntas reais. O trabalho sob medida está no ambiente do cliente ou nas lacunas do seu próprio produto? A última milha é irredutível ou simplesmente ainda não foi construída? Seus FDEs estão descobrindo algo ou absorvendo algo? E o que foi construído no produto da última vez que um deles voltou?
Use FDEs para descobrir o que precisa existir no produto. FDEs comem dor e excretam produto. Se os seus estão comendo dor e excretando mais dor, você não tem um time de FDEs. Você tem um negócio de serviços.
