Gestión de producto de IA en Spotify: tres capas, tres formas de entender el trabajo de un PM

El artículo, publicado en el blog de ingeniería de Spotify, parte de una crítica a cómo se habla del tema: casi todos los textos y pódcast sobre producto e IA se refieren a «el PM de IA» como si fuera un único puesto. Tres Principal Product Managers de la misma organización (Personalización), con el mismo stack tecnológico y las mismas prioridades corporativas, sostienen que el trabajo cambia mucho según lo que se construye. Cada uno describe una capa distinta: investigación, modelo y experiencia de usuario.

Los tres usan el mismo vocabulario («calidad», «evals», «shipping»), pero el significado cambia según el problema que cada uno posee. También cambia la idea de impacto. En investigación puede ser que la organización modifique lo que cree o dónde invierte. Para el PM de modelo, es que una mejora del modelo se traduzca en mejores recomendaciones en varias experiencias. Para el PM de experiencia, es que los usuarios quieran el producto y vuelvan. Los autores recuerdan que los fundamentos de la gestión de producto siguen vigentes y que lo que cambia es la especialización según lo que se posee.

Capa de investigación: el producto como palanca técnica. Henok lidera producto en Tech Research y lo define como «palanca técnica»: aplicar conocimiento científico donde pueda cambiar lo que Spotify construye o la confianza con la que lo construye. Destaca tres ideas.

La primera es que la IA cambia qué problemas necesitan investigación. Con mejores modelos y herramientas, los equipos de producto pueden hacer por sí mismos trabajo que antes requería a investigación. Esta se centra entonces en métodos compartidos, diseño de sistemas y capacidades emergentes donde el enfoque correcto aún no está claro. Cita dos ejemplos: cómo evaluar el comportamiento abierto de un modelo y cómo representar usuarios y contenido de forma que varios productos puedan aprovecharlo. Advierte de que es fácil construir un prototipo atractivo, pero que la distancia hasta un producto fiable para cientos de millones de usuarios puede ser grande. Un modelo más complejo puede lucir en una demo sin aportar diferencias reales en las tareas de producción. Por eso la evaluación, la latencia, el coste, los datos y la integración forman parte de la pregunta de investigación.

La segunda es que una arquitectura prometedora no es una hoja de ruta. Henok describe una exploración de una arquitectura que reúne capacidades hoy repartidas en distintos sistemas. Al principio la cuestión era si podía funcionar. Al acumularse la evidencia surgió otra más difícil: qué debe hacer la organización con ella. Su trabajo consiste en convertir la idea grande en decisiones razonables: empezar por un problema concreto, encontrar una prueba útil y acordar qué evidencia justificaría el siguiente paso. No es todo o nada, porque los métodos y componentes desarrollados por el camino ya pueden mejorar sistemas existentes y orientar a los equipos de modelo y de experiencia, aunque la cuestión de la arquitectura completa siga abierta.

La tercera es la combinación de ciclos de retroalimentación largos con un campo que se mueve rápido. El impacto de la investigación puede tardar meses en aparecer, a menudo en la hoja de ruta o las métricas de otro equipo, y mientras tanto cambian la tecnología y las prioridades. Por eso la influencia es central. Dentro del equipo aporta contexto de producto y estrategia sin prescribir la respuesta. Fuera, conecta el trabajo con las decisiones, implica pronto a los equipos relevantes y deja claro qué demuestra y qué no demuestra la evidencia. Si eso empieza solo al terminar la investigación, la ventana de decisión puede haberse cerrado. También exige entender la tecnología más a fondo que en otros roles de PM; se apoya en herramientas de IA para trabajar con artículos y prototipos y se mantiene cerca de uno o dos proyectos a la vez.

Capa de modelo: la capacidad como producto y otro equipo como cliente. Divita lidera producto de un modelo fundacional, un modelo de lenguaje diseñado específicamente para recomendaciones y capaz de referenciar elementos reales de Spotify. Como en cualquier plataforma, lo que construye llega al usuario a través de otros equipos. Lo distintivo es que el comportamiento se moldea con datos, las salidas son probabilísticas y la calidad significa algo distinto para cada equipo que lo integra. Sus clientes son equipos internos con sus propias hojas de ruta y métricas, y el mismo modelo debe servir a definiciones distintas de una buena recomendación. Su tarea es entender esas necesidades y decidir dónde una capacidad compartida puede servirlas bien; una petición de un equipo puede señalar algo útil para varias experiencias. Los fundamentos se vuelven concretos: el ajuste producto-mercado es saber qué problemas pueden resolver los equipos con el modelo, la propuesta de valor es explicar qué ofrece para su experiencia concreta y el impacto de negocio llega a través de lo que lanzan con él.

Su primera idea es que el comportamiento de un modelo no se especifica: se moldea y después se demuestra que importa. En un rol tradicional se define qué debe hacer el sistema y se trabaja con ingenieros para construirlo. Aquí el comportamiento se aprende mediante entrenamiento, no se escribe en código. Las dos palancas reales son qué se enseña al modelo y cómo se comprueba lo aprendido: datos y evals. Gran parte de su trabajo es decidir qué deben medir esas evaluaciones. Una recomendación plausible es solo el punto de partida; hay que valorar cómo encaja con el contexto del oyente, cómo equilibra familiaridad y descubrimiento y si sigue siendo relevante con el tiempo. Después hay que conectar lo que se mide en el modelo con lo que viven los oyentes: las evaluaciones offline explican el comportamiento del modelo y las métricas online muestran cómo se traduce en experiencia. Lo aprendido con los equipos socios sirve para priorizar el siguiente ciclo de entrenamiento.

Su segunda idea es mostrar qué hace posible un modelo compartido. La promesa es que una mejora beneficie a varias experiencias, pero cada equipo ya tiene un sistema optimizado para sus necesidades. Lo primero es demostrar que el modelo compartido cumple los requisitos de calidad, latencia y coste de cada experiencia, con criterios definidos y acordados con los socios. Lo segundo, a más largo plazo, es qué ganan los equipos al construir sobre el mismo modelo: si lo aprendido en una experiencia mejora otra, o si un equipo puede probar algo nuevo apoyándose en una capacidad existente. Convierte esa promesa en preguntas concretas y comprobables, y sigue cómo evoluciona el modelo entre ciclos de entrenamiento y cómo se traducen los cambios entre experiencias, para distinguir un resultado prometedor de un patrón sobre el que planificar.

Su tercera idea es que un buen modelo no basta si nadie lanza nada con él. El éxito es que otros equipos lancen productos con el modelo. Buena parte del trabajo se parece poco a trabajo de modelo: encontrar un equipo cuyo sistema actual ha tocado techo en una métrica que le importa, hacer del modelo un camino práctico y convincente, acordar qué debe entregar la capacidad, definir el contrato de integración y probar las hipótesis más arriesgadas antes de pedir compromiso al socio. Su mejor resultado del año vino de un equipo de superficie que quería un resultado que ellos podían entregar, y funcionó porque acordaron cómo medir el éxito antes de acordar la arquitectura.

Capa de experiencia: el usuario es el cliente y el modelo es un ingrediente más. Humberto construye el producto con el que interactúan directamente los usuarios: la superficie donde un estado de ánimo vago se convierte en un conjunto de canciones y donde el sistema debe hacer algo útil aunque la petición sea ambigua. Sus clientes son los usuarios, y eso lo cambia casi todo. Las capas de investigación y modelo son su tecnología base y su trabajo es convertirla en algo agradable. Al estar más cerca del usuario, ve con más claridad qué carencias del modelo y qué preguntas de investigación importan más ahora, de modo que la dependencia de las otras capas funciona más como señal compartida de priorización que como cuello de botella.

Su primera idea es diseñar para una entrada infinita. En un producto tradicional la acción del usuario está acotada (pulsar un botón, elegir en un menú, teclear una palabra clave), la respuesta es predecible y se puede verificar. En una experiencia de IA la entrada es abierta: peticiones vagas, poco especificadas o complejas que no corresponden a una única entidad del catálogo, y los agentes interpretan lo que el usuario probablemente quiso decir. Eso replantea restricciones que parecían fijas; una latencia inaceptable en una búsqueda por palabras clave puede ser tolerable en una conversación, porque el usuario entiende que pide algo más difícil. Pero cómo responder cuando el sistema no está seguro y cómo recuperarse de un error no tienen respuestas estables, y pertenecen al producto, no al modelo.

Su segunda idea es que la evaluación es un producto, no solo un proceso. Los tests A/B y la evaluación offline siguen siendo útiles, pero no bastan cuando no se pueden predefinir todos los escenarios. Su equipo construye nuevos instrumentos: conjuntos de datos a partir de patrones reales de uso, bucles de retroalimentación que muestran dónde el sistema malinterpretó una petición, y jueces basados en LLM y evaluadores a medida para las interacciones concretas del producto, con los que miden si un cambio es una mejora real o solo una diferencia. La evaluación no es una fase previa al lanzamiento, sino un producto continuo. Una evaluación general válida para los muchos usos del modelo fundacional es un punto de partida; el equipo de experiencia debe cerrar la brecha entre «el modelo es bueno en general» y «esta interacción fue buena para este usuario».

Su tercera idea es que la conversación hace natural el feedback. En un producto conversacional los usuarios hablan con el sistema y, cuando algo va mal, lo dicen con sus palabras y en tiempo real, algo que no existía en superficies anteriores. Una frase como «eso no es lo que quería decir» es información sobre la experiencia, el modelo y potencialmente los datos de entrenamiento a la vez. El trabajo consiste en construir mecanismos que detecten esa señal a escala, la interpreten y la devuelvan por la cadena de colaboración para que todas las capas mejoren. Humberto resume el rol así: es la línea más directa con el usuario y la propiedad más tangible del resultado, pero se construye sobre sistemas que se influyen sin controlarlos, para usuarios cuyas expectativas moldea en tiempo real cada otro producto de IA que usan. El oficio es lograr algo fiable con ingredientes probabilísticos por naturaleza.

Reflexión final. Los autores concluyen que no existe un único conjunto de habilidades nuevo de «PM de IA». La gestión de producto sigue siendo el mismo oficio: definir bien el problema, conocer a fondo al cliente, medir lo que importa y construir convicción con evidencia y no con entusiasmo. Lo que añade el stack de IA es una capa de especialización sobre esos fundamentos, que viene en más variantes de lo que se suele pensar y cambia de un producto a otro.

Nota editorial: el texto es una reflexión de experiencia interna de tres responsables de producto, sin cifras de resultados ni métricas concretas publicadas; sus afirmaciones son cualitativas y describen enfoques y aprendizajes, no evidencia cuantitativa.