Qué hace un Product Manager de IA

El dolor real: se contrató un título, no un criterio

El patrón se repite en empresas de todos los tamaños. Dirección lee que la competencia ya tiene IA en su producto, se abre una posición con el título de Product Manager de IA, entra un perfil que domina el vocabulario del sector, y el primer entregable es un roadmap con seis funcionalidades que incluyen la palabra asistente. Seis meses después hay un chat dentro del producto, un resumen automático que nadie revisa y un costo mensual de API que sube sin que nadie sepa contra qué resultado se compara.

Lo que falló no fue la tecnología. Falló que nadie definió qué proceso del negocio se estaba rediseñando, qué decisión iba a tomar el sistema en lugar de una persona, y qué pasa cuando esa decisión sale mal. El roadmap tenía funcionalidades, no criterios. La confusión de fondo es tratar la IA como una categoría de features: pasas de un sistema que hace siempre lo mismo a uno que produce salidas variables con una calidad que hay que medir. Quien conduce ese producto necesita otro tipo de decisiones, no otro tipo de tarjetas en el tablero.

Qué hace de verdad: decide bajo incertidumbre y responde por el proceso

Un Product Manager de IA es la persona que decide qué parte de un proceso de negocio va a resolver un sistema de IA, con qué datos, con qué nivel de autonomía y con qué salida esperada. No escribe el modelo ni entrena nada. Define el problema, el alcance, el umbral de calidad aceptable, el camino de escalamiento cuando el sistema no alcanza ese umbral y la forma en que se mide si el proceso mejoró. Es un rol de criterio y de gestión de proceso, apoyado en análisis, no un rol de configuración de herramientas.

Su trabajo diario se parece más al de un gerente de operaciones con criterio de producto que al de un especialista técnico. Se sienta con el área dueña del proceso, entiende cómo se hace hoy la tarea, cuántas veces al día se hace, cuánto cuesta un error y quién lo corrige. Recién con ese mapa decide qué parte vale la pena delegar a un sistema. Ese orden importa: primero el proceso, después la arquitectura, y solo al final el modelo. También administra algo que un PM tradicional casi nunca administra: el costo variable de operar el producto, que escala con la adopción y puede convertir el éxito de uso en un problema de margen.

Lo que cambia respecto de un PM normal: el producto no es determinista

Esta es la diferencia central y casi todo lo demás sale de acá. En software tradicional, la misma entrada produce siempre la misma salida; si no lo hace, es un defecto y se corrige. En un producto con IA, la misma entrada puede producir salidas distintas, y la mayoría son aceptables mientras algunas no lo son. No hay un estado «sin bugs», hay una distribución de calidad que se gestiona. Eso obliga al PM a diseñar explícitamente lo que un PM tradicional da por sentado:

• El comportamiento ante el error del modelo: qué muestra el sistema cuando no tiene suficiente información, cuándo dice que no sabe en vez de inventar, y cuándo pasa el caso a una persona.
• El umbral de calidad aceptable por caso de uso: no es el mismo para redactar un borrador interno que para responderle a un cliente sobre una póliza. El mismo modelo puede ser suficientemente bueno en un flujo e inaceptable en otro.
• El costo del error y quién lo asume: cuánto cuesta, quién lo detecta, en cuánto tiempo y qué se rompe aguas abajo. Un error silencioso que se descubre a los tres meses es más caro que uno visible que se corrige el mismo día.
• La reversibilidad: si el sistema ejecutó una acción equivocada sobre un sistema real, se puede deshacer. Si no se puede deshacer, ese paso no debería ser automático todavía.
• La trazabilidad de la salida: poder reconstruir por qué el sistema respondió lo que respondió, con qué datos y bajo qué instrucción. Sin eso, cualquier reclamo de un cliente se vuelve indefendible.

La segunda consecuencia es en la medición. Un PM normal mide uso: usuarios activos, adopción, retención, conversión. Un PM de IA tiene que medir uso y calidad de salida, porque un producto con mucho uso y mala calidad de salida no es un éxito, es una deuda operativa que alguien está pagando a mano. Si el 30% de las respuestas necesita corrección humana, el sistema no ahorró trabajo: lo movió de lugar y lo hizo menos visible.

La decisión que más valor aporta: qué NO se automatiza

En la mayoría de proyectos que reviso, la decisión con más impacto no fue qué se automatizó, sino qué se dejó deliberadamente en manos de una persona. Es una decisión de producto y le corresponde al PM de IA, no al proveedor. Automatizar todo lo técnicamente posible es la forma más rápida de acumular riesgo sin acumular resultado.

Señales de que un paso no debería automatizarse todavía

• El error no es reversible y afecta directamente a un cliente, a un contrato o a dinero que sale de la empresa.
• El proceso no está definido internamente: si dos personas del equipo lo hacen distinto y ninguna sabe cuál es la forma correcta, el sistema va a codificar la confusión y a escalarla.
• El volumen es bajo. Automatizar una tarea que ocurre cuatro veces al mes casi nunca justifica el costo de construirla, mantenerla y vigilarla.
• El valor de la tarea está en la relación, no en la ejecución: una negociación difícil, una mala noticia a un cliente clave, una decisión con implicancias laborales.
• No existe forma barata de verificar si la salida está bien. Si validar la respuesta cuesta casi lo mismo que producirla a mano, no hubo ahorro y solo se movió el trabajo de lugar.
• Hay una obligación regulatoria o contractual de que una persona responda por la decisión. La responsabilidad no se delega a un modelo.

Decir que no también es proteger el resultado. Un sistema que resuelve bien la mayoría de los casos y deriva limpiamente el resto produce más valor y menos ruido que uno que intenta resolverlo todo y falla de forma impredecible. El primero se defiende ante dirección con números. El segundo se cae la primera vez que un cliente reclama.

Qué NO es un Product Manager de IA (y qué no resuelve)

No es un especialista en prompts con tarjeta de presentación nueva: escribir buenas instrucciones es útil, pero es la parte más pequeña del trabajo y la más fácil de aprender. Tampoco es un científico de datos, no construye ni entrena modelos. Y no es un traductor pasivo que transporta requerimientos de un lado al otro sin criterio propio. Tampoco resuelve lo que no le corresponde: no arregla un proceso que la empresa nunca definió, no reemplaza una decisión de dirección y no compensa la falta de datos limpios. Si la información del negocio vive en hojas de cálculo inconsistentes y en la cabeza de tres personas, ningún rol de producto va a construir un sistema confiable encima de eso.

Cómo se evalúa el rol: resultado y criterio, no títulos ni herramientas

Acá hay una regla que sostengo sin matices: un Product Manager de IA se evalúa por el resultado de negocio que produce y por su capacidad de análisis y de gestión de procesos. No por su título, no por dónde estudió, no por cuántas herramientas domina. Saber nombrar modelos, comparar frameworks y explicar arquitecturas de moda es una señal débil. Es conocimiento de mercado, no criterio de producto, y hoy se adquiere en semanas. Lo que no se adquiere en semanas es la capacidad de mirar un proceso desordenado, entender dónde está el costo real y decidir qué parte vale la pena rediseñar.

Qué mirar de verdad en un perfil

• Capacidad de análisis de proceso: puede describir un flujo de trabajo real de punta a punta, con volúmenes, tiempos, puntos de error y responsables, sin recurrir a generalidades.
• Decisiones documentadas bajo incertidumbre: casos donde eligió un umbral de calidad, definió un camino de escalamiento o frenó una automatización, y puede explicar el razonamiento.
• Relación con el número de negocio: sabe contra qué métrica de operación se compara su trabajo y la puede nombrar sin ayuda.
• Manejo del error en producción: ya vivió una falla real de un sistema en uso, sabe cómo se detectó y qué se cambió después.
• Capacidad de decir que no: puede nombrar cosas que decidió no construir y sostener el porqué frente a presión interna.

Un candidato que domina el vocabulario pero no puede describir un proceso concreto de una empresa donde trabajó va a producir roadmaps que suenan bien y no mueven nada. Uno que viene de operaciones, sabe leer un proceso y entiende lo suficiente de la tecnología para no pedir imposibles suele producir más resultado, aunque en la entrevista use menos siglas.

Errores que veo repetirse en empresas reales

• Armar el roadmap por funcionalidades de IA en vez de por procesos de negocio. La pregunta correcta nunca es «qué feature de IA agregamos», es «qué parte de este proceso está costando tiempo o dinero y puede resolverse con una salida que sepamos verificar».
• No definir el comportamiento de error antes de lanzar. Si nadie decidió qué muestra el sistema cuando no sabe, el modelo va a inventar y el equipo de soporte se va a enterar por un cliente molesto.
• Medir solo adopción. Un asistente con miles de usos al mes y sin ninguna medición de calidad de salida puede estar generando más retrabajo del que ahorra, con el tablero viéndose perfecto.
• Dejar la decisión de qué automatizar en manos del proveedor o del equipo técnico. Ellos evalúan factibilidad, no riesgo de negocio. El alcance es una decisión de producto, y el costo variable ignorado hasta que llega la factura es parte de esa decisión.
• Confiar en una demo interna como validación. Que funcione con diez ejemplos elegidos por el equipo no dice nada sobre cómo se comporta con los casos raros que sí llegan todos los días desde la operación.
• Contratar el rol antes de tener el proceso mapeado, y pedirle que además haga el diagnóstico que nadie quiso hacer. Termina siendo un cargo sin autoridad para decidir nada.

Cómo medir si el rol está funcionando

El rol se mide igual que cualquier función de negocio: contra el proceso que debía mejorar y contra el costo de operarlo. No contra la cantidad de entregas ni contra la sofisticación de lo construido. Estas son las señales que reviso a los tres meses:

• Tiempo de ciclo del proceso intervenido, medido antes y después, con la misma definición en ambos momentos.
• Porcentaje de salidas del sistema que se usan sin corrección humana, revisado sobre una muestra real y no sobre casos elegidos.
• Tasa de escalamiento a una persona, y si esa tasa baja, se estabiliza o sube con el tiempo. Que baje demasiado rápido también es una señal: puede significar que el sistema dejó de derivar casos que debía derivar.
• Costo por transacción del sistema, comparado con el costo de hacer esa misma tarea manualmente.
• Cantidad de incidentes de calidad detectados por la empresa antes que por el cliente. Si los descubre el cliente primero, la instrumentación no existe.
• Uso sostenido pasados los primeros dos meses, cuando ya no hay presión de adopción ni novedad, y decisiones de alcance documentadas: qué se decidió no automatizar y con qué argumento.

Si a los tres meses el PM de IA puede mostrar funcionalidades lanzadas pero ninguna de estas señales se movió, no es un problema del modelo ni del proveedor. Es que el rol se está ejerciendo como gestión de entregables y no como gestión de un proceso de negocio. La corrección no es cambiar de herramienta, es volver al mapa del proceso y elegir de nuevo dónde vale la pena que un sistema decida y dónde no.