Cómo es diferente construir productos de IA—y por qué los equipos de producto deben evolucionar

Galen Low: ¿Realmente existe algo tan diferente en el proceso de desarrollar un producto con funcionalidad nativa de IA frente a otros productos que simplemente integran tecnología de IA existente?

Jyothi Nookula: Sí. Cuando estás construyendo un producto nativo de IA, lidias con tres factores distintos. Primero, la IA es fundamentalmente impredecible.

Galen Low: ¿Cuál es lo primero que haces como líder cuando notas que un equipo quizá no tiene el mismo nivel cuando se trata de entender, aplicar o incluso solo aceptar tecnologías emergentes como la IA?

Jyothi Nookula: Divido el problema en dos cuestiones distintas. El primer aspecto es la competencia. El segundo es la disposición. Si tratas un problema de disposición como si fuera de competencia, solo lo empeorarás.

Galen Low: ¿Cuáles son los aspectos principales que un gerente de producto interesado en desarrollar productos de IA necesita tener en su currículum o portafolio para destacar?

Jyothi Nookula: Uno es evidencia de haber construido algo con IA, no solo hablar de ello. Lo segundo es…

Galen Low: Bienvenido al pódcast de Digital Project Manager: el programa que ayuda a líderes de delivery a trabajar de manera más inteligente, entregar más rápido y liderar mejor en la era de la IA. Soy Galen, y cada semana nos sumergimos en estrategias reales, nuevas herramientas, marcos probados y ocasionalmente una historia de guerra desde la primera línea de los proyectos. Ya sea que estés dirigiendo proyectos de transformación masiva, gestionando flujos de trabajo de IA o simplemente tratando de mantener el caos bajo control, estás en el lugar correcto. Vamos a ello.

Hoy hablamos del futuro del gerente de producto, qué se necesita para desarrollar productos de IA, cómo se usa la IA para optimizar el proceso de desarrollo y lanzamiento de productos, y qué pueden hacer los líderes de equipo cuando sus equipos de producto tienen distintas competencias y actitudes frente a tecnologías emergentes como la IA.

Conmigo hoy en el estudio está Jyothi Nookula. Jyothi tiene más de 13 años de experiencia impulsando innovación en productos y plataformas de IA en empresas como Netflix, Meta, Amazon AWS y Etsy. También posee 12 patentes de aprendizaje automático y ha orientado a más de 1500 gerentes de producto en su transición a roles de IA a través de su empresa educativa, Next Gen Product Manager.

Jyothi, muchas gracias por acompañarme hoy.

Jyothi Nookula: Hola a todos. Estoy muy emocionada de estar aquí hoy.

Galen Low: Yo también estoy emocionado y he estado esperando esto por semanas. Cuando tú y yo hablamos por primera vez, lo primero al ver tu perfil fue un “wow, Jyothi es una potencia”. Hay muchas marcas y tecnologías en tu perfil que dan envidia.

Y tengo debilidad por quienes buscan ayudar a la próxima generación de cualquier oficio a crecer en un mundo cada vez más tecnológico y ahora también orientado a la IA. Así que cuando conversamos pensé: tenemos tanto en común. Yo estoy más del lado de proyectos, tú más del lado de producto. Pero me emociona analizar cómo están cambiando las cosas y algunas lecciones que has aprendido a lo largo de tu trayectoria en productos de IA y aprendizaje automático.

Sé que probablemente nos desviaremos en algunos temas interesantes y valiosos, así que ojalá lo hagamos. Pero el gerente de proyectos en mí armó este roadmap para hoy. Para empezar, quería sacar una gran pregunta incómoda pero urgente, esa que creo que todos quieren conocer.

Luego me gustaría ampliar y hablar sobre tres temas. Primero, identificar y cerrar brechas de habilidades en tus equipos de productos al trabajar con productos que aprovechan funcionalidades de IA y machine learning. Después, explorar ejemplos de cómo tus equipos usan herramientas de IA en el proceso de desarrollo de productos, sea para investigación, análisis de datos, diseño, ingeniería, pruebas de usuario u otra cosa completamente distinta.

Y finalmente, explorar cómo se ve el futuro para el rol de gestión de productos: qué necesita un currículum o portafolio para ser considerado en lugares como Meta, AWS, Netflix, Etsy y otras marcas líderes en IA.

Jyothi Nookula: Me encanta. Estoy interesada. Es el tema más candente. Me fascina.

Galen Low: Genial. Empecemos con esa gran pregunta. Mi pregunta para enmarcar todo esto es, claro, sobre la IA. Porque tienes mucha experiencia trabajando con equipos de producto para desarrollar soluciones basadas en IA y aprendizaje automático para gigantes como Meta, Amazon, Etsy y Netflix. Mi pregunta es: ¿realmente hay algo tan diferente en el proceso de desarrollar un producto con funcionalidad nativa de IA frente a otros productos que solo integran tecnología de IA existente?

Jyothi Nookula: Es una gran pregunta, porque va al corazón de lo que realmente está cambiando en el desarrollo de productos hoy. Y la respuesta sincera es sí, pero no en la forma en que la gente lo piensa. Esto es lo que quiero decir. Cuando construyes un producto nativo de IA, trabajas con tres cosas diferentes a diferencia del software tradicional o incluso productos que solo integran IA mediante una API.

La primera es que la IA es fundamentalmente impredecible, así que tu desarrollo tradicional de producto… Escribes código determinista, tipo “si pasa esto, haz esto otro”. O si hago clic en ese botón, lleva a la siguiente pantalla. Cada vez que hago clic en ese botón hará lo mismo. Pero con productos nativos de IA, trabajas con sistemas probabilísticos, así que tu función de IA puede funcionar diferente cada vez que se ejecuta.

Esto significa que todo tu proceso de aseguramiento de calidad, manejo de casos límite, garantías de confiabilidad, todo ello debe ser completamente repensado porque no solo pruebas si algo funciona; pruebas si funciona lo suficientemente bien y de forma consistente cada vez en una distribución de resultados.

Lo primero que es fundamentalmente diferente es esa imprevisibilidad, ese determinismo versus probabilismo. Lo segundo es que ahora construyes productos en terreno inestable porque los modelos subyacentes evolucionan de maneras que no controlas. Por ejemplo, un nuevo modelo puede cambiar comportamientos.

Quizá no sea un cambio crucial, pero altera el comportamiento, amplía capacidades o introduce nuevos modos de falla. Y esto ocurre de la noche a la mañana al ritmo en que avanza todo. Así que, a diferencia de las dependencias tradicionales donde controlabas versiones, documentabas actualizaciones, estos modelos evolucionan más rápido de lo que puedes registrar.

Y lo tercero, que es clave, es que tus métricas de éxito deben ser diferentes. Ya no puedes solo medir si la función se ejecutó correctamente. Ahora debes medir cosas como: ¿el resultado fue útil? No es solo que se ejecutó, ¿fue útil? ¿Coincidió con la intención del usuario? ¿La pregunta que hizo? ¿Cómo defines “bueno” para tu caso de uso? Terminas necesitando bucles de retroalimentación mucho más cortos con tus usuarios y tienes que integrar estos mecanismos de evaluación al desarrollo del producto, lo cual es muy diferente a cómo se desarrolla tradicionalmente.

Esas son las tres cosas muy diferentes. Los productos que solo integran IA (como agregar integración con ChatGPT) pueden ser tradicionales. Aun así manejas métricas de éxito y evaluaciones, pero al menos aquí tienes un contrato. Cuando construyes tu producto como nativo de IA desde cero, es totalmente diferente. Y es ahí donde estos tres factores impactan aún más en el desarrollo de producto.

Galen Low: Me parece divertido porque antes pensaba que me dirías que sí, que es lo mismo salvo por algunos detalles. Pero en realidad eso lo cambia todo.

Me encanta lo que dices sobre medir la intención y el tema de la medición, porque vengo del mundo de proyectos, sabes, tenemos nuestro documento de requisitos. Es binario: ¿hizo lo que decía la especificación funcional? Pero luego hay toda esa ambigüedad. A) porque es probabilístico y el resultado no será el mismo cada vez.

Y B) porque la arquitectura subyacente en cierto modo es una caja negra, evolucionando más rápido que la capacidad humana de entenderla. Y digo: esto sí es muy diferente a como se han creado la mayoría de los productos digitales en la historia reciente. Pero tiene sentido. Pienso en mi cabeza:

Tienes más de una década de experiencia trabajando con aprendizaje automático e IA. Mucha gente solo lleva dos años empezando. Es nuevo para ellos desde hace dos años o así. ChatGPT le mostró al mundo cómo se puede usar la IA, pero ha estado en el software y en nuestros productos digitales desde hace tiempo.

Y lo que se me ocurre es: porque viste Netflix, parece tan simple y seguramente no lo es. Ese algoritmo, el aprendizaje automático, toda la analítica de datos en segundo plano… No es solo que todo en Netflix tenga una taxonomía. No son simplemente “enlaces relacionados” como en una web.

En realidad se trata de comportamiento e intención, y es fácil equivocarte. Incluso es fácil no enterarte nunca que está mal hasta que recibes ese tuit que dice: “mi Netflix nunca acierta porque vi esto y ahora me sugiere lo que sea, 18 temporadas de Barney”.

Jyothi Nookula: Incluso con los reels de Instagram y TikTok pasa todo el tiempo. Veo un video de alguien esquiando y luego estoy inundada de vídeos de esquí. Sí.

Galen Low: Y creo que lo damos demasiado por sentado. Sería fácil, incluyéndome, pensar: “No sé, eso parece fácil, lo mismo de siempre”. Pero cuando lo desglosas, no es así. Quisiera ampliarlo un poco, porque además de tu impresionante trayectoria liderando productos digitales para empresas como Amazon, Meta, Netflix y Etsy, también eres fundadora de Next Gen Product Manager que, entre otras ofertas educativas, tiene un bootcamp de cinco semanas para pasar de la gestión convencional de productos a la gestión de productos de IA.

Y sinceramente, que tu curso exista ya me dice que las habilidades convencionales de gestión de producto ya no son suficientes. Se requiere una mentalidad y competencias más avanzadas. Y, aunque seguramente has podido elegir los integrantes de tus equipos, es lógico pensar que no todos tus equipos tenían las mismas competencias y actitudes frente a la IA y otras tecnologías emergentes. Mi pregunta es: ¿qué es lo primero que haces como líder cuando notas que un equipo no tiene el mismo nivel al entender, aplicar o incluso aceptar tecnologías emergentes como la IA?

Jyothi Nookula: Sí, y es un reto muy práctico y real, algo con lo que he lidiado mucho y sigo haciéndolo. He sido líder de personas gestionando equipos de distintos tamaños, desde tres hasta doce personas. He pasado por ese espectro y veo que la brecha de habilidades y de comodidad con la IA es la mayor que he visto con cualquier cambio tecnológico en mi carrera.

Esto es lo primero que hago: separo el problema en dos cuestiones distintas. La primera es competencia, donde la gente no sabe cómo trabajar de manera efectiva con IA. La segunda es disposición, donde las personas están escépticas, resistentes o incluso ansiosas al respecto.

Debes diagnosticar cuál de las dos te encuentras o si tienes ambas. Es importante identificar qué problema abordas porque, si tratas un problema de disposición como si fuera de competencia, lo empeorarás. Para brechas de competencia, mi primer acción es crear un contexto compartido a través de la práctica, no solo mediante el aprendizaje.

Este es el mismo enfoque que enseño en mi curso de cinco semanas de gestión de productos de IA: aprender haciendo. No me gusta enviar a la gente a formaciones o pedirles que vean tutoriales. En cambio, integro la IA en nuestros flujos de trabajo y tareas cotidianas: uso herramientas como Claude o GPT para escribir retrospectivas de sprint, sintetizar temas, hacer investigación profunda, elaborar resúmenes de user research, etc. Los equipos ven que la herramienta les ahorra trabajo real y no simplemente los reemplaza. En dos semanas pregunto en la reunión: “¿En qué te ayudó la IA?”, o “¿Qué descubrimiento hiciste gracias a la IA que no habrías detectado?”. Esas experiencias compartidas se convierten en la base para incrementar la competencia.

Para los problemas de disposición, más relacionados con el rechazo o el miedo, la mejor vía es liderar con curiosidad, no con evangelización. Suelo preguntar en las reuniones uno a uno: “¿Cuál es tu preocupación?” y escucho sin interrumpir. Usualmente, surgen cosas legítimas: “Siento que esto va a devaluar mi oficio”, o “No confío en los resultados porque no puedo verificarlos del todo”, o “Siento que me estoy quedando atrás y es abrumador”. Son preocupaciones reales. Y ahí entendí que a alguien no se le convence de sus miedos con lógica; lo que puedes hacer es reconocerlo, normalizarlo y mostrar un camino a seguir.

Si alguien teme que desvaloricen su trabajo, le enseño cómo la IA ayuda con el andamiaje pero ahora su juicio profesional puede centrarse en trabajos más complejos. Si le preocupa la verificación, trabajamos juntos en los mecanismos de evaluación y él o ella pasan a ser expertos en la garantía de calidad de la IA.

También me ha funcionado identificar rápidamente a esas personas-puente. Siempre hay alguien curioso por la IA, que experimenta y obtiene resultados. Les doy permiso explícito para compartir “lo que funciona” en sesiones informales, en stand-ups o en show & tell. Así se genera aprendizaje entre pares, porque al ver a un colega obteniendo resultados, estarán más dispuestos a intentarlo que si su jefe se los impone de arriba a abajo.

Y esto puede ser polémico: avanzo rápido hacia establecer que la fluidez con la IA ya es una expectativa básica. Soy empática con la curva de aprendizaje y paciente con el proceso, pero dejo claro que no es opcional. Así como todos tuvimos que aprender la metodología ágil, analítica o diseño, esto ya es parte del trabajo.

Combinar alto apoyo con altas expectativas, y expresarlas de forma clara, reduce la ansiedad. Los equipos que veo que más sufren son donde el liderazgo es poco claro en expectativas y tampoco da apoyo real: ahí surge resentimiento porque hay desamparo.

La meta no es que todos estén al mismo nivel, sino que todos avancen en la misma dirección, con seguridad psicológica y herramientas prácticas.

Galen Low: Me encanta. Sobre todo esa distinción entre competencia y disposición. Me alegro de que hablaras de eso. Mientras lo describías pensé: esto es una mezcla de gestión del cambio y trabajo en equipo en tiempo real.

Tendemos a pensar en gestión de cambio como algo que solo ocurre ante cambios grandes, casi como una iniciativa de una sola vez, cuando en realidad es una gestión del cambio continua, todos los días, en el equipo. Y, como dices, no es solo “anda y aprende solo porque sí” y sin claridad. Así se construye la competencia colectiva y la disposición compartida, porque es más horizontal y con más apoyo de pares.

Compartimos conocimiento, información, y me encanta que reconozcas las ansiedades legítimas ante la IA: miedo a quedarse atrás, falta de tiempo, percepción de desvalorización, y que la mejor vía es ver a los pares afrontarlo y ponerlo en práctica. No es teórico: lo hacéis juntos. Soy fan de aprender haciendo, así que me alegra saber que así enseñas también. Me resuena el tema de la claridad: altas expectativas y alto apoyo, pero la claridad es lo que nos impulsa adelante.

Porque la decisión de si esto es una moda pasajera o una nueva normalidad (como escribir en un teclado), ya está tomada. No puedes ignorar la IA. Debemos avanzar juntos.

Jyothi Nookula: Sí.

Galen Low: Mencionaste que parte clave son esos pequeños experimentos, pilotos, para que la gente experimente la IA, gane competencia y confianza. Imagino que hay un amplio espectro de cómo y dónde se puede usar IA en el desarrollo de productos que también son productos de IA.

¿Podrías darnos algunos ejemplos de cómo tus equipos han estado usando IA en el diseño y desarrollo de los productos?

Jyothi Nookula: Sí. Puedo darte ejemplos concretos a lo largo de todo el ciclo de vida del desarrollo de productos.

Galen Low: Me encanta.

Jyothi Nookula: Empezando por la investigación: usamos IA para comprimir mucho la generación de hallazgos. Normalmente hacemos muchas entrevistas, unas 15 o 20. En lugar de pasar una semana identificando patrones, alimentamos las transcripciones en Claude y le pedimos identificar patrones, contradicciones o casos extremos.

Pero aquí es clave: no tomamos el resultado directamente. El investigador revisa, desafía y refina los hallazgos, así que el humano sigue siendo crucial. La IA da un primer borrador sólido en una hora en lugar de una semana, y el investigador se centra en el juicio, decidiendo qué hallazgos importan.

Lo mismo con los tickets de soporte: cuando el producto ya está en el mercado, el volumen de soporte puede ser enorme. En vez de revisarlos manualmente, analizamos miles de conversaciones con IA para identificar puntos de dolor, su alcance, y frecuencia. La IA permite ver patrones imposibles de ver manualmente.

Así, el gerente de producto puede priorizar mejor qué arreglar y cuál funcionalidad priorizar en el roadmap. Hasta en documentación y comunicación, la IA elimina el trabajo pesado: se usa para escribir PRDs, resumir revisiones de sprint y crear reportes para stakeholders. Todo esto puede ser el primer borrador y, como me decía una PM, antes dedicaba el 30% de su tiempo a redactar; ahora lo dedica a editar, lo cual es más valioso pues parte de una buena base.

También usamos IA para hacer más accesible la documentación. Alguien puede preguntar “¿qué decidimos sobre este rediseño del flujo de pago?” y recibir una respuesta sintetizada de distintos canales (Slack, reuniones, PRDs). Así la IA ayuda a democratizar el conocimiento.

A lo largo de todo el ciclo, del prototipo a la documentación e interacción con ingeniería, la IA está presente. Donde antes el PM redactaba PRDs y estos no van a desaparecer, ahora se agrega el componente de prototipo, porque ¿para qué dar solo historias cuando puedes mostrar un prototipo e ir validando producto-mercado? El PRD contiene visión, criterios de evaluación, funcionamiento ideal, casos de éxito y fallo, pero también ese prototipo que muestra la interacción e imaginación del producto. Así que vemos IA en todas las fases.

Galen Low: Genial que hayas hablado de eso, porque justo la semana pasada debatíamos si el PRD está muerto.

Conversando con una PM, ella decía que no, porque igual necesitas plasmar los argumentos y el porqué del producto, features, prioridades, etc. Incluso tiene una app que ayuda a argumentar el encaje del producto y qué funcionalidades priorizar.

Atado a la prototipación, la visión sigue siendo clave, la IA no da todas las respuestas, y eso es bueno. Pero ese shift en la labor del PM —otro ejemplo: quienes nunca documentaron nada antes ahora deben documentar para aprovechar la IA. En cierta forma, los PM llevan ventaja, y la IA es una máquina de primeros borradores. Pero tenía una duda: porque en proyectos mucha gente usa la IA para ese primer borrador y ya. ¿Tus equipos usan solo ese primer borrador y continúan, o alimentan el feedback para mejorar sus resultados?

Jyothi Nookula: Llamamos a esto “one shot”. Muchos piensan que basta alimentar a la IA una vez para obtener un informe listo que puedas usar, lo cual raras veces ocurre. Normalmente es solo un buen primer borrador, pero luego tú aportas tus ideas, le das feedback, y la IA te devuelve observaciones. Es como tener un compañero para refinar hasta que quedes satisfecho.

Si tratas al sistema de IA como “le doy algo y me devuelve una respuesta cerrada”, rara vez resulta útil. Lo que aporta valor es trabajar iterativamente. Por eso decimos que es fácil enseñar el “cómo”, pero el “gusto”, el criterio, sigue siendo dominio del PM.

Galen Low: Me gusta eso, el “gusto”. ¿Crees que ahora el 30% del trabajo ya no solo es editar documentación, sino interactuar con un robot? Porque muchas funciones de PM implican lo humano: entrevistas de usuario, research, datos… Pero ¿crees que se pierde humanidad en la gestión de producto desde la óptica del que teme pasar el día enseñando a una máquina en vez de interactuar con humanos?

Jyothi Nookula: No sé si es tanto hablar con un robot, porque como dije, si solo interactúas tú y la IA, vale. Pero igual tienes que convencer stakeholders, hablar con ingenieros. El PM es el centro de conexión con todos los equipos. Así que más que un robot, es un asistente útil para intercambiar ideas. Veo que mis PM, líderes y colegas lo usan para “pensar en voz alta”, para brainstorming, no de forma robótica, sino como un compañero 24/7.

Galen Low: Jugando al abogado del diablo, has trabajado en lugares donde probablemente alguien te haya preguntado: “Jyothi, ¿por qué no automatizamos todo este proceso?” ¿Hace falta alguien en el bucle humano? ¿No podríamos pasar todos los tickets de soporte, priorizar features y lanzar nuevas funciones todo con IA, sin humanos? No tienes que contarme si ha pasado, pero: ¿cómo respondes a ese enfoque tech first en vez de centrado en el usuario, especialmente en grandes tecnológicas donde hay presión por usar IA a toda costa?

¿Cómo argumentas a favor del componente humano en el proceso ante esa presión?

Jyothi Nookula: Sí, me topo mucho con esa situación, incluso asesorando empresas o conversando con alumnos: “¿Cómo lo manejo?” Es casi una epidemia: todos quieren empezar por la IA y, para bien o mal, a veces se olvida al usuario, empezando por la tecnología, lo cual es muy poco intuitivo.

Es difícil contrarrestar esa tendencia porque los incentivos conducen en sentido contrario: directivos leyendo los mismos tres artículos sobre IA como cuestión existencial, inversores preguntando por la estrategia IA en cada llamada y los ingenieros emocionados. La presión por hacer “algo IA” es enorme. Por eso, vuelvo a los principios de producto: empezar por el usuario y el problema antes que el algoritmo. Siempre lo digo en clase: usuarios antes que algoritmos. Si un VP llega emocionado diciendo “hay que usar esta nueva capacidad de IA”, no puedes decir simplemente “no”. En vez de eso, lo reformulo: “Interesante tecnología, ¿qué problema buscamos resolver?” Los hago articular el problema, no de modo desafiante, sino: “Cuéntame el día a día del usuario. ¿Dónde encaja esto? ¿Qué hacen ahora? ¿Qué alternativa tendrían si esto no existiera?”.

Generalmente pasa una de tres cosas. Uno: descubren que es la solución buscando un problema, y la idea pierde fuerza porque no logran articular una necesidad real. Segundo: identifican un problema real, pero la IA quizá no es la mejor solución, bastaría mejor UX, onboarding, o arreglar procesos obsoletos y, de hecho, sería más fácil con tecnología determinista. Tercero (mejor de los casos): identifican un problema real donde la IA desbloquea algo nuevo; ahí sí hay innovación.

En Amazon, algo que hacemos mucho es el proceso working backwards: escribir un comunicado de prensa simulado. Hago que mis PM (o colegas) redacten ese comunicado, argumentando el impacto del producto y con testimonios de usuarios. Es muy difícil fingir que algo es asombroso si pasas ese filtro. Esto me ha resultado útil para gestionar esas conversaciones.

A veces la presión viene desde arriba y no puedes luchar con el CTO. En esos casos, cambio el enfoque: si vamos a hacerlo, al menos que sea útil. Busquemos el verdadero problema a resolver. Así digo: “Sí, usemos IA, pero aquí hay un problema más urgente o adecuado, tenemos los datos y el caso de uso, el ROI, etc.”. Así canalizo las ideas hacia algo con sentido. Antes creía que mi función era proteger la visión de producto; ahora entiendo que es canalizar la energía, guiarla hacia usos útiles para el usuario.

El tema no es el entusiasmo, sino cómo canalizarlo para que sirva al usuario. Vuelvo siempre a los principios: usuarios y problemas antes que tecnología. Nadie abre un Word vacío solo para preguntarse “¿qué escribo?”.

Galen Low: ¿Dónde está Clippy cuando lo necesitamos? Esa es toda una masterclass sobre cómo navegar la política del producto, porque muchas veces pensamos que somos guardianes, puertas de entrada, el “no” institucional. Me gusta esa idea de canalizar energía, ya que puede traer cosas buenas. Lo del “bueno, hagámoslo útil” no lo oigo a menudo, pero es muy realista porque así funcionan las compañías: a veces no tienes opción. No siempre hay que dejar una constancia por escrito para luego decir “te lo dije”, también se puede construir.

La energía puede beneficiar y, viniendo del diseño centrado en el usuario, me emociona escuchar a gente volver recurrentemente al beneficio e impacto en el usuario. Qué útil ese giro: “¿Qué problema estamos resolviendo?” e invitar a razonar juntos. Ni de lejos es solo un “rechaza y bloquea”, es construir una solución compartida.

Por cierto, el ejercicio del comunicado me lo apropio: trabajamos backwards, pero no solemos llegar hasta ese comunicado y realmente fuerza el razonamiento y la visión del impacto, no solo lanzar la funcionalidad. Qué buen método para pensar en el resultado, no solo en el delivery. Qué vamos a hacer por la gente, de qué estaremos orgullosos. Es genial.

Jyothi Nookula: Sí, amo ese ejercicio de comunicado. Lo sigo usando después de años de dejar AWS. Aporta perspectiva.

Galen Low: Me encanta. Es súper útil.

Si te parece, cerremos mirando al futuro, porque ha quedado claro que la gestión de productos está cambiando mucho. Los productos cambian, las herramientas y métodos se transforman, y también las expectativas técnicas, de negocio y de delivery.

¿Cuáles son tus tres o cuatro cosas principales que un PM interesado en desarrollar productos de IA necesita mostrar en su CV o portafolio para destacar?

Jyothi Nookula: Gracias por preguntar esto, porque es muy práctico y honestamente, lo que busco en un currículum ha cambiado mucho en dos años.

Esto es lo que realmente hace destacar a alguien ahora mismo. Uno: evidencia de haber construido algo con IA, no solo hablar de ello. Como recruiter buscamos cubrir una vacante real, no es un tema de investigación; quiero ver que realmente lanzaste una función de IA nativa. No solo “trabajé en un equipo con IA” o “contribuí con una estrategia”, sino: ¿qué problema resolviste con el producto de IA?, ¿qué hacía la IA?, ¿cómo lo evaluaste?, ¿qué aprendiste que te sorprendió? Para quien ya desarrolló productos de IA, esto tiene sentido, pero para muchos otros no; por eso aconsejo construir tus propios proyectos paralelos, algo que hacemos en mi curso, donde crean un kit de portafolio real.

Y les insisto: no basta con hacerlo y cerrar el portátil, hay que convertirlo de un proyecto a un producto, compartirlo con amigos y la comunidad, recibir feedback y mejorarlo, incluso ponerle un cobro aunque sea simbólico. Eso tiene impacto real en el CV, más que decir sólo “trabajé en un proyecto de IA”. Hay que generar productos, sea en el trabajo o fuera de él.

Segundo: mostrar fluidez técnica. No hace falta ser ingeniero de ML ni saber programar, pero sí demostrar que puedes mantener conversaciones técnicas creíbles con ingenieros sobre cómo funcionan esos sistemas. En el currículum esto puede aparecer como frameworks de evaluación, pruebas A/B, decisiones sobre latencia/calidad, coste/capacidad, modelos, arquitecturas concretas. El vocabulario importa: es distinto decir “usé IA para mejorar UX” que decir “desarrollamos una arquitectura rag para reducir alucinaciones en respuestas de soporte, mejorando la precisión de X a Y” - ahora sé lo que hiciste.

La prueba que uso es: ¿puedes explicarle a un ingeniero por qué hay que usar la técnica A en vez de la B en este caso? ¿Y puedes explicarle a un stakeholder de negocio por qué esa decisión técnica impacta en resultados? El PM de IA es ese nexo: traduce posibilidades técnicas a valor de negocio y lo revierte en decisiones técnicas.

Por último, tener experiencia navegando la ambigüedad y la iteración rápida. Los productos de IA son distintos, los modelos cambian, las capacidades evolucionan. Así que debes sentirte cómodo en la ambigüedad, y esto debe verse en tu CV: por ejemplo, lanzar productos de cero a uno, entornos rápidos, mindset de experimentación y prototipado, incluso en proyectos personales.

Eso hace destacar al candidato. Lo que no busco: sopa de buzzwords (“usé IA/ML para potenciar sinergias”, etc.) o hacer seis cursos online certificados; tampoco decir “apasionado por la IA”… Eso no destaca. El patrón que busco es velocidad de aprendizaje: ¿qué tan rápido puedes aprender y qué profundidad técnica alcanzas? Si quieres entrar en la gestión de productos de IA y no tienes experiencia directa, créala tú mismo. Nadie impide construir, escribir, hacer case studies o tear downs de productos que admires; hoy la barrera de entrada es bajísima. Además, casi nadie tiene 10 años de experiencia en IA, todos estamos aprendiendo. Lo que realmente diferencia es quién se arremanga y quién espera permiso.

Galen Low: Es una explicación buenísima de ese dilema. Seguro lo escuchas: “soy PM, no debería tener que programar”, pero tú has definido muy bien esa capa intermedia. Sí, no tienes que programar pero sí tener el vocabulario y el entendimiento para traducir entre el negocio, el usuario y la técnica. Y una mentalidad de builder, para saber dónde están los puntos de fricción. No basta con decir que trabajaste en tal empresa, sino que demuestres si sabes navegar la ambigüedad, entender al usuario y comunicarte con equipos diversos. Solo así sé si eres proactivo, valiente y aprendes rápido, en vez de limitarte a “hacer lo que te dicen” en una gran empresa.

Jyothi Nookula: Por eso digo: no esperes permiso, hazlo. La barrera para intentarlo es muy baja ahora.

Galen Low: Jyothi, muchas gracias por estar hoy conmigo. Fue genial. Antes de despedirte, ¿dónde puede la gente saber más de ti?

Jyothi Nookula: Sí, pueden buscarme en LinkedIn como Jyothi Nookula. O visitar nextgenproductmanager.com donde encontrarán mis cursos de gestión de productos IA, IA agentica y PM Accelerator.

Galen Low: Genial. Pondré esos enlaces en las notas. Jyothi, gracias de nuevo.

Jyothi Nookula: Muchísimas gracias. Me divertí mucho.

Galen Low: Bueno amigos, esto fue todo por el episodio de hoy en Digital Project Manager Podcast. Si te gustó la conversación, suscríbete donde sea que escuches. Si quieres aún más estrategias, casos, y playbooks, visita thedigitalprojectmanager.com. Hasta la próxima, gracias por escuchar.