¿Qué es un Product Manager «Forward Deployed» y por qué las empresas de IA lo contratan?

El artículo, firmado por Caroline Clark en Mind the Product (19 de octubre de 2026), explica en qué consiste el Forward Deployed Product Manager (FDPM), un perfil que gana peso con la llegada de los productos de IA. La definición es la siguiente: un PM empleado por un proveedor que trabaja dentro de la organización del cliente, junto a las personas que usan el producto, para que funcione en ese contexto. Pertenece a una empresa pero está integrado en otra, y responde de cómo funciona el producto en el mundo de ese cliente. Según la compañía, puede cubrir un único cliente o una pequeña cartera de cuentas.

La autora arranca con una anécdota personal de hace diez años. Como Technical Product Manager, lideraba un equipo de ingenieros de backend que integraba la API de su producto en los sistemas de reservas de un minorista de viajes. Surgieron problemas que no podían diagnosticar en remoto y que les costaban ingresos. Fueron a una tienda con su ingeniero jefe y los resolvieron observando lo que ocurría en directo. Funcionó, pero solo porque no les quedaban otras opciones. Hoy, plantea el texto, hacerlo de forma deliberada es un puesto en sí mismo.

La clave del rol es la proximidad. En lugar de depender de entrevistas, tickets de soporte o videollamadas con pantalla compartida, el FDPM ve de primera mano cómo aparece un problema y cómo lo sortean los usuarios. Después hace dos cosas. Primero, determina qué hará exitoso a ese cliente, a menudo configurando la plataforma y prototipando soluciones funcionales con usuarios reales. Segundo, devuelve lo aprendido al equipo que construye el producto central, para que se beneficien los demás clientes. Lo habitual es que trabaje junto a un Forward Deployed Engineer (FDE), que se encarga de la construcción técnica, mientras el FDPM se ocupa de qué necesita el cliente y por qué.

El término viene del ámbito militar, donde el despliegue avanzado significa situar fuerzas cerca de donde pueden hacer falta. Según el artículo, Palantir lo trasladó al software hacia 2010 con la figura del Forward Deployed Engineer, en entornos complejos como defensa, inteligencia, sanidad y aviación. Hasta entonces las empresas de software construían productos estandarizados (escalables y más baratos) o soluciones a medida (difíciles de escalar y caras). Palantir se situó en medio: configuraba su plataforma estándar para cada cliente, desarrollaba funciones a medida cuando hacía falta e incorporaba lo que funcionaba a la plataforma para todos. Ese ciclo de desplegar, aprender y generalizar es lo que hereda el FDPM.

¿Por qué ahora? El texto sostiene que los productos de IA no son de estantería y que la brecha entre un modelo capaz y un despliegue que funcione se ha convertido en el cuello de botella. Un modelo solo aporta valor real cuando se conecta con los datos, flujos de trabajo, permisos, sistemas y personas del cliente, y cuando estas confían en él. Hacerlo desde fuera es difícil, así que el FDPM pretende acortar un bucle de retroalimentación doloroso: el cliente encuentra un problema, se lo explica al proveedor por teléfono, el proveedor construye algo y el cliente intenta implantarlo por su cuenta.

El artículo afirma que OpenAI, Anthropic, AWS, Microsoft y SAP han anunciado programas de este tipo y están contratando de forma intensiva. Cita a The Bench, un portal de empleo sobre empresas tecnológicas europeas, que contabilizó 170 ofertas activas con «Forward Deployed» en el título en 98 compañías a finales de julio de 2026. Las nuevas publicaciones pasaron de una en enero a 62 en julio. La mayoría son puestos de ingeniería, y los de FDPM serían un subconjunto visible; entre las empresas que los anuncian figuran Scale AI, Salesforce y Adobe.

Si el despliegue de IA es sobre todo un problema de ingeniería, ¿para qué un PM? Porque cada proyecto embebido genera un flujo de peticiones y alguien debe decidir cuáles revelan un patrón que merece incorporarse al producto y cuáles son particulares de un cliente. Algunos profesionales, recoge el texto, sostienen que lo difícil es decidir qué merece la pena construir y si compensa. Ese criterio, junto con la confianza de los directivos de ambas partes, es lo que justifica al PM junto al FDE.

El día a día combina observación y prototipado. El FDPM observa cómo interactúan los usuarios con los sistemas y flujos del cliente, y aprende mucho en momentos informales, como las pausas del té en la cocina. Algunos incluso se forman para operar los sistemas del cliente, por ejemplo trabajando unos días como agente de un centro de atención telefónica: la experiencia de primera mano supera a la descripción de segunda mano. Después diseñan y prueban prototipos y configuraciones rápidos con los futuros usuarios, a menudo con ayuda de herramientas de IA, y documentan flujos, prototipos y resultados para alimentar la priorización y hacer explícitos los compromisos entre soluciones. Las soluciones exitosas vuelven al equipo de la plataforma central para valorar su extensión a todos.

Para ilustrarlo, la autora imagina que en su caso del minorista de viajes hubiera habido un FDPM desde el primer día. En la primera semana se sentaría junto a los asesores y observaría reservas reales antes de cualquier trabajo de integración. Notaría dos cosas: los asesores no reservan en línea recta, sino que saltan entre partes del proceso según avanza la conversación con el cliente, y se saltan la página de ventas adicionales para llegar al pago, con lo que la oportunidad suele perderse. Al preguntar por qué, emergería un aspecto de psicología del comprador: la reserva es solo un momento del viaje del cliente, y al asesor le interesa más conocer la experiencia que desea que vender extras en el momento del pago. La solución sería, junto con el FDE, un recorrido de «eje y radios» que permita moverse libremente entre secciones y un flujo que envíe ofertas adicionales por correo tras la reserva. Luego llega el juicio de producto: ¿es algo específico de este minorista o reservan así otros clientes? Si es común, el FDPM lleva la evidencia al equipo central y recomienda cambiar el comportamiento por defecto para todos. El «trío de producto» típico es el FDPM, un FDE y un PM de la plataforma central que hace de enlace.

La diferencia principal con un PM tradicional es lo que posee cada uno: el PM tradicional es responsable de un producto, y el FDPM de los resultados de una cuenta de cliente. Frente a roles vecinos, el texto distingue: el FDE se ocupa del «cómo» (escribir y desplegar la solución técnica), mientras el FDPM del «qué» y el «por qué»; el arquitecto de soluciones diseña la mejor implementación del producto existente para un cliente, mientras el FDPM decide cómo debe cambiar el propio producto a partir de lo que esas implementaciones revelan; el consultor tiende a recomendar y marcharse, mientras el FDPM permanece hasta que el producto aporta valor, responde de los resultados y tiene el deber de devolver el aprendizaje al producto; y el PM de IA construye funciones de IA para un mercado de clientes, mientras el FDPM busca que el producto funcione para clientes concretos.

El artículo añade una advertencia: parte de esto es reetiquetado. Citando un texto de Ben Hollands en el Substack de a16z, indica que Palantir usó el título para elevar el estatus de roles de cara al cliente que antes se trataban como prescindibles, un movimiento que el texto llama «arbitraje de títulos». Por eso conviene leer la descripción del puesto y no fiarse solo del nombre.

En cuanto a competencias, se parte de los fundamentos de PM: resolver problemas con creatividad, priorizar por impacto, responsabilizarse del descubrimiento y la entrega, y distinguir entre lo que el cliente pide, su problema real y lo que debería hacer la plataforma. A ello se suman tres cosas. La primera, profundidad técnica: lo bastante para debatir arquitectura y viabilidad con ingenieros y leer registros y datos directamente; en productos de IA, entender modelos, evaluaciones, salvaguardas, alucinaciones y estructuración de datos, además de prototipar con distintos modelos y flujos de agentes, sin necesidad de entregar código de producción. La segunda, criterio comercial y capacidad de decir que no: decidir qué se queda a medida y qué pasa al equipo central es el núcleo del rol, y una disciplina sugerida es fijar el umbral de antemano (por ejemplo, la misma necesidad en varias cuentas no relacionadas) para que la hoja de ruta no quede capturada por quien más grita. La tercera, habilidades de relación: comunicación, negociación, persuasión y construcción de confianza con todos los niveles, además de saber moverse por la burocracia organizativa como compras, revisiones de seguridad y política del cliente.

Antes de aceptar un puesto así, el artículo recomienda preguntar cómo llega una función necesaria a la hoja de trabajo del producto central, cuánta capacidad de ingeniería se reserva para las iniciativas que uno devuelve, cómo se medirá el rendimiento, cuánta autonomía hay para crear funciones y configuraciones a medida, y si se tiene autoridad para asumir compromisos sobre el producto central y si los equipos de funcionalidades los respetarán. También conviene sopesar honestamente los pros y contras. Entre las ventajas, la exposición a una variedad de problemas y entornos de clientes y un aprendizaje rápido, sobre todo en IA. Entre los inconvenientes, que la profundidad en una cuenta puede ir en detrimento de la estrategia de producto a largo plazo, que uno puede acabar cumpliendo promesas hechas en otra parte de la empresa, y que estar muy pegado a un proyecto dificulta ver el producto en conjunto.

La conclusión vuelve a la anécdota inicial: el problema nunca fue la falta de gente inteligente, sino la distancia entre quienes construían y el problema por resolver. El FDPM es el rol diseñado para cerrar esa distancia.