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 + un enfoque de despliegue, y cómo ha evolucionado con el tiempo.
Algo que solíamos menospreciar ahora es la respuesta por defecto
"Ingeniero de despliegue en campo" se ha convertido en la respuesta a casi todas las preguntas difíciles en el go-to-market de la IA. ¿Los despliegues son dolorosos? Contrata FDEs. ¿Los clientes no pueden autoservirse? FDEs. ¿El producto no está listo? FDEs. Tanto Anthropic como OpenAI han creado brazos de despliegue empresarial explícitamente basados en el modelo de Palantir, y cada startup en etapa semilla con la que hablo ahora tiene una vacante de FDE. Las vacantes para este puesto, según se informa, se han disparado varios cientos por ciento en el último año.
Lo extraño es que esto, hasta hace muy poco, 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 con los FDEs es que entregan resultados. Esto es increíble en la era de la IA, porque las empresas pueden no estar seguras de cuál es el camino para llegar al resultado, pero es claro que la IA produce resultados contundentes.
Al mismo tiempo, el rol se está sobreutilizando y no debería ser una muleta para ocultar un problema estructural.
"Los FDEs se comen el dolor y excretan producto"
Palantir (de donde viene mi cofundador @AshwinSreenivas) popularizó este 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 casi dos décadas la visión generalizada de Palantir era que se trataba de una consultoría disfrazada más que de una empresa de tecnología real, y que esa visión se basaba en una observación real: muchos de sus ingenieros pasaban muchísimo tiempo sentados junto a los clientes.
Pero Shyam Sankar, el CTO de Palantir, tenía una frase que repetía constantemente: los FDEs se comen el dolor y excretan producto.
Los primeros despliegues de Gotham de Palantir eran profundamente personalizados, construidos para responder una sola pregunta de inteligencia para una sola unidad. Palantir codificó los problemas que veían como primitivas de plataforma: la ontología, los modelos de objetos, los permisos, los motores de flujo de trabajo y el seguimiento de procedencia. Esas primitivas se convirtieron en Foundry. Foundry se convirtió en lo que se podía vender comercialmente. Apollo y AIP siguieron el mismo camino.
Nada de eso habría existido sin ingenieros que primero se comieran el dolor en el campo. El dolor era la materia prima del producto, no un costo de venta.
A medida que Foundry maduró, los despliegues estandarizados redujeron drásticamente la necesidad de trabajo personalizado, los márgenes brutos subieron hasta el 80 % y Palantir pasó de un enfoque liderado por FDEs a la venta basada en cuentas. Muchos de esos FDEs migraron a la ingeniería central. También es famoso que rechazaron contratos donde el cliente solo quería una 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 CRM SaaS 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 la transferencia de un lead.
Si estás construyendo un agente de IA para contabilidad en 2026, no hay un flujo de trabajo establecido, porque literalmente nadie ha usado uno de estos. Nadie sabe cómo se ve 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 todavía no tiene forma.
Esa es la misma situación en la que empezó Palantir. Lonsdale lo planteaba así: adoptaron el despliegue en campo 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 maneras 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 ahí.
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 sacar a los FDEs.
No vas a querer 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 decisiones 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 decirle que no a nadie. No se toma ninguna decisión arquitectónica dolorosa. El cliente está encantado.
Y ahora tienes todas las desventajas del modelo y ninguno de los beneficios del descubrimiento. Tu costo de servicio no baja. Tus márgenes siguen limitados. Tu crecimiento está limitado por la contratación. Cada arreglo a medida en el campo es una decisión de producto que elegiste no tomar. Cada despliegue debería facilitar el siguiente.
Además, muy pocas startups pueden cerrar acuerdos de ocho cifras como los que Palantir conseguía de entrada, lo que hace que la economía 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 el descubrimiento de una desconocida. Agrupar ambos bajo un mismo título es la forma en que las empresas se convencen de que una organización de servicios en crecimiento es una inversión en 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 ú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 descomponible, y cuando hablamos con empresas, dos cosas siempre se mantienen constantes:
- La velocidad de iteración es clave. Lanzar un agente de IA no es algo que se hace una sola vez. Constantemente necesita ajustes y actualizaciones con el tiempo. Si cada ajuste requiere ingeniería, será demasiado lento y costoso para escalar.
- La dependencia del proveedor y la soberanía. Dadas las experiencias de las organizaciones con el SaaS, nadie quiere quedar atrapado con un proveedor y depender de sus recursos.
Al principio, Ashwin y yo personalmente construíamos 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, todavía nos asociamos con el cliente para entregar el resultado de principio a fin. Sin embargo, incluso durante ese proceso, el desarrollo lo hacemos nosotros, mientras capacitamos a su equipo en nuestro producto y les entregamos las llaves. A medida que el producto ha madurado, el trabajo específico por cliente que ha hecho nuestro equipo de ingeniería ha disminuido drásticamente.
Esa decisión ha tenido sus contrapartidas. Significó no improvisar algo en el campo cuando eso habría sido más rápido. Significó recibir las escalaciones y convertirlas en requisitos en lugar de parches, lo que consume tiempo en el corto plazo.
La recompensa:
- Dos tercios del trabajo de despliegue ahora ocurren de forma autónoma a través de Duet: configuración, iteración, la larga cola de ajustes que solía requerir supervisión humana.
- Ahora solo toma unos pocos días en promedio lanzar el primer AOP, incluso para grandes bancos, aerolíneas, telcos, etc.
Todavía hay mucho trabajo por hacer, pero estamos en el camino.
Entonces: ¿FDE o no FDE?
Adopta el despliegue en campo desde el principio. Capta la señal. Pon a tus ingenieros frente a los clientes para siempre.
Luego hazte las preguntas reales. ¿Lo personalizado 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 se comen el dolor y excretan producto. Si los tuyos se comen el dolor y excretan más dolor, no tienes un equipo de FDEs. Tienes un negocio de servicios.
