Dos tercios de nuestro trabajo de despliegue ahora los realiza de forma autónoma nuestro propio producto (a través de Duet).
Este post trata sobre por qué es así, nuestra filosofía para construir un producto + una estrategia de despliegue, y cómo ha evolucionado con el tiempo.
Algo que solíamos despreciar ahora es la respuesta por defecto
El "forward deployed engineer" (ingeniero de despliegue en el cliente) se ha convertido en la respuesta a casi todas las preguntas difíciles en el go-to-market de IA. ¿Los despliegues son dolorosos? Contrata FDEs. ¿Los clientes no pueden autogestionarse? FDEs. ¿El producto no está listo? FDEs. Tanto Anthropic como OpenAI han creado unidades de despliegue empresarial modeladas explícitamente a partir de Palantir, y toda startup en fase semilla con la que hablo ahora tiene una oferta de empleo para FDE. Según los informes, las ofertas de empleo para este puesto han aumentado varios cientos por ciento en el último año.
Lo extraño es que, hasta hace muy poco, esto era algo por lo que te criticaban. Desplegar ingenieros en los clientes se veía como una señal de que no tenías un producto real: tus ingresos eran de menor calidad y tus márgenes estaban estructuralmente limitados. Nada de la economía subyacente ha cambiado.
La clave de los FDEs es que generan resultados. Esto es fantástico en la era de la IA, porque las empresas pueden no estar seguras de cuál es el camino para lograr el resultado, pero está claro que la IA produce resultados convincentes.
Al mismo tiempo, el rol se está sobreutilizando y no debería ser una muleta para ocultar un problema estructural.
"Los FDEs comen dolor y excretan producto"
Palantir (de donde proviene mi cofundador @AshwinSreenivas) popularizó el rol a mediados de los 2000 vendiendo Gotham a la CIA, la NSA y las unidades de inteligencia del Ejército. Y aguantaron las críticas durante mucho tiempo. Joe Lonsdale, uno de los cofundadores, ha escrito que durante la mayor parte de dos décadas la visión predominante de Palantir era que se trataba de una consultora glorificada más que de una empresa tecnológica real, y que esa visión se basaba en una observación cierta: muchos de sus ingenieros pasaban mucho tiempo sentados con los clientes.
Pero Shyam Sankar, CTO de Palantir, tenía una frase que repetía constantemente: los FDEs comen dolor y excretan producto.
Los primeros despliegues de Gotham de Palantir eran profundamente a medida, construidos para responder a una pregunta de inteligencia para una sola unidad. Palantir codificó los problemas que veía como primitivas de plataforma: la ontología, los modelos de objetos, la gestión de permisos, los motores de flujo de trabajo, el seguimiento de procedencia. Esas primitivas se convirtieron en Foundry. Foundry se convirtió en aquello que podías vender comercialmente. Apollo y AIP siguieron el mismo camino.
Nada de eso habría existido sin ingenieros comiendo dolor en el terreno primero. El dolor era el insumo del producto, no un costo de venta.
A medida que Foundry maduraba, los despliegues estandarizados redujeron drásticamente la necesidad de trabajo personalizado, los márgenes brutos subieron hasta el entorno del 80%, y Palantir pasó de un modelo liderado por FDEs a una venta basada en cuentas. Muchos de esos FDEs migraron a la ingeniería central. También es famoso que rechazaron contratos en los que el cliente solo quería un Accenture con mejor software.
El equipo de FDEs no era el modelo de negocio. Era la forma de construir el producto correcto.
Por qué algunas startups de IA realmente necesitan FDEs ahora mismo
Si estuvieras construyendo un SaaS de CRM en 2015, no necesitabas descubrir el flujo de trabajo. Durante veinte años, mucha gente ya había pensado en qué es un pipeline, qué es una etapa y cómo se ve un traspaso de leads.
Si estás construyendo un agente de IA para contabilidad en 2026, no existe un flujo de trabajo establecido, porque literalmente nadie ha usado nunca uno de estos. Nadie sabe cómo es el recorrido del usuario — ni tú y, lo que es más importante, tampoco tu cliente. No pueden decirte lo que quieren, porque lo que querrían aún no tiene forma.
Esa es la misma situación en la que empezó Palantir. El planteamiento de Lonsdale era que recurrieron al despliegue en el cliente por necesidad: tenían una tecnología sólida y ninguna idea de cómo trabajaban realmente sus primeros clientes de defensa e inteligencia.
Así que sí, envía ingenieros. Siéntate en la sala. Mira cómo tu producto se rompe de formas que tus pruebas nunca imaginaron. En una categoría genuinamente nueva, la última milla no es un problema de entrega, es un problema de descubrimiento, y no hay sustituto para estar allí.
La trampa no es empezar. Es no parar.
Una vez que sabes cuáles son realmente los recorridos de los usuarios, deberías empezar a retirar a los FDEs.
No querrás hacerlo. No porque alguien tome una mala decisión, sino porque mantenerlos es más fácil en cada sprint.
Los FDEs te permiten evitar todas las disyuntivas difíciles de producto. Nunca tienes que decidir qué hace el producto, ni cuál de dos solicitudes de clientes gana, ni dónde termina la superficie de configuración. Se siente gratis. Nadie tiene que decir que no a nadie. No se toma ninguna decisión arquitectónica dolorosa. El cliente está encantado.
Y ahora tienes todos los inconvenientes del modelo y ninguno de los beneficios del descubrimiento. Tu costo de servicio no disminuye. Tus márgenes siguen topados. Tu crecimiento está limitado por la contratación. Cada solución a medida en el terreno es una decisión de producto que elegiste no tomar. Cada despliegue debería hacer que el siguiente sea más fácil.
Además, muy pocas startups pueden cerrar los acuerdos de ocho cifras que Palantir conseguía de entrada, lo que hace que la economía del modelo sea aún más difícil de sostener.
Una cosa más que no debes confundir
FDE tampoco es lo mismo que implementación. "Construye esta integración en su sistema de tickets" es un trabajo real y necesario, pero es ejecución contra una especificación conocida, no descubrimiento de una desconocida. Agrupar ambos bajo un mismo título es como las empresas se convencen de que una organización de servicios en crecimiento es una inversión de producto.
Los modelos ya escriben código lo suficientemente bien como para que gran parte de lo que un equipo de implementación hacía en 2023 se esté convirtiendo en algo que el producto hace por sí mismo. Con el tiempo, podrás construir un agente que pueda hacer todo el trabajo de la última milla de principio a fin. Puede observar flujos de trabajo e incluso entrevistar a clientes.
Lo que hicimos en su lugar
En nuestro caso específico con @DecagonAI, creemos fundamentalmente que un enfoque impulsado por el producto es la respuesta, más que uno impulsado por servicios o por FDEs. El servicio al cliente es de alto volumen, repetible y desglosable, y cuando hablamos con empresas, hay dos cosas que se mantienen siempre constantes:
- La velocidad de iteración es clave. Lanzar un agente de IA no es algo de una sola vez. Constantemente necesita ser ajustado y actualizado con el tiempo. Si cada ajuste requiere ingeniería, será demasiado lento y caro para escalar.
- Bloqueo de proveedor y soberanía. Dadas las experiencias de las organizaciones con el SaaS, nadie quiere quedar bloqueado por un proveedor y depender de sus recursos.
En los primeros días, Ashwin y yo construíamos personalmente lo que los clientes pidieran. A medida que el producto despegó, tomamos la decisión explícita de que nuestra propuesta de valor central sería tener el mejor producto.
Para ser claros, seguimos asociándonos con el cliente para entregar el resultado de principio a fin. Sin embargo, incluso en ese proceso, somos dueños del desarrollo, mientras formamos a su equipo en nuestro producto y les damos las llaves. A medida que el producto ha madurado, el trabajo específico para clientes que ha realizado nuestro equipo de ingeniería ha disminuido drásticamente.
Esa decisión ha tenido sus contrapartidas. Significó no improvisar una solución en el terreno cuando eso habría sido más rápido. Significó tomar las escalaciones y convertirlas en requisitos en lugar de parches, lo que toma tiempo a corto plazo.
La recompensa:
- Dos tercios del trabajo de despliegue ahora se realizan de forma autónoma a través de Duet: configuración, iteración, la larga cola de ajustes que solía requerir un humano en el bucle.
- Ahora, lanzar el primer AOP toma apenas unos días en promedio, incluso para grandes bancos, aerolíneas, telecos, etc.
Todavía queda mucho trabajo por hacer, pero estamos en el camino.
Entonces: ¿FDE o no FDE?
Opta por el despliegue en el cliente desde el principio. Capta las señales. Pon a tus ingenieros frente a los clientes para siempre.
Luego hazte las preguntas reales. ¿Lo hecho a medida está en el entorno de tu cliente o en las brechas de tu propio producto? ¿La última milla es irreducible o simplemente no está construida? ¿Tus FDEs están descubriendo algo o absorbiendo algo? ¿Y qué se construyó en el producto la última vez que uno de ellos regresó?
Usa los FDEs para descubrir qué necesita existir en el producto. Los FDEs comen dolor y excretan producto. Si los tuyos están comiendo dolor y excretando más dolor, no tienes un equipo de FDEs. Tienes un negocio de servicios.
