Cómo sobreviví los últimos 3 años en liderazgo de producto

Lee la transcripción:

Estamos probando transcribir nuestros pódcast con un programa de software. Por favor, perdona cualquier error, ya que el bot no es correcto el 100% del tiempo.

Hannah Clark: Aquí tienes un ejercicio interesante. Intenta imaginarte un día en tu propia vida hace tres años. En 2022, los grandes temas del momento eran cosas como el crecimiento guiado por producto versus el crecimiento guiado por ventas y el debate sobre volver a la oficina versus teletrabajo desde el inicio. La IA parecía una misión secundaria opcional, y el panorama laboral parecía un mercado de compradores para quienes buscaban empleo. Vaya cómo han cambiado las cosas en tan poco tiempo.

Pero otra diferencia era que este programa tenía una presentadora diferente: y ese antiguo anfitrión es mi invitado de hoy. Michael Luchen ha pasado los últimos tres años enfocándose en liderazgo de producto, y como Arquitecto de Transformación de Producto, ha estado en la trinchera durante un tiempo crucial en el que lo único constante ha sido el cambio, tanto fuera como dentro de los equipos de producto.

En el episodio de hoy, vamos a reflexionar sobre las apuestas estratégicas y tácticas que ha hecho en los últimos años, las que funcionaron, las que no, y hacia dónde sopla el viento para la gestión de producto al entrar en la segunda mitad de 2025. Empecemos.

Por cierto, mantenemos conversaciones como esta cada semana. Así que si esto te parece interesante, ¿por qué no te suscribes? Muy bien, ahora sí, empecemos. Bienvenido nuevamente al podcast de Product Manager. Hoy estoy aquí con Michael Luchen, a quien algunos de ustedes quizá recuerden.

Michael, gracias por acompañarnos hoy.

Michael Luchen: Gracias, Hannah. Encantado de estar aquí de nuevo.

Hannah Clark: Sí. Para empezar, ¿puedes contarnos un poco sobre tu trayectoria y cómo llegaste hasta donde estás hoy?

Michael Luchen: Claro, hola a todos. Soy Michael, antiguo anfitrión de este pódcast, pero últimamente me considero un arquitecto de transformación de producto. Y mi enfoque ha sido ayudar a empresas en etapa de crecimiento a construir organizaciones de producto que entregan resultados como startups y escalan como grandes empresas. Personalmente, tengo más de 12 años de experiencia trabajando en más de 50 productos, desde startups de 10 personas hasta marcas globales como Adidas.

En este tiempo he aprendido que las empresas que ganan no sólo están llenas de ideas, sino que son impulsadas por sistemas. Así que, por mi experiencia, los grandes sistemas de producto convierten la visión en ejecución repetible. Esta percepción proviene de liderar productos en todo tipo de contexto y estructura organizacional, cada uno enseñándome nuevos patrones sobre lo que realmente funciona.

Recientemente fui director de producto en Float, donde transformé una organización de producto que pasaba de lanzamientos irregulares a una cadencia continua de entregas en todos los equipos, lo que ayudó a alcanzar un crecimiento significativo en ARR y la posición número uno en G2. Antes, pasé nueve años en Crema, una agencia digital de productos fantástica, liderando su práctica de gestión de producto tanto para la agencia como para clientes, desde firmas consultoras élite hasta startups en etapa temprana.

A nivel personal, soy un pensador de sistemas nato. Ya sea diseñando operaciones de producto, enmarcando una toma con mi Fuji, o construyendo Lego con mis hijos, siempre exploro cómo encajan las piezas. Eso crea un conjunto mayor que la suma de sus partes.

Hannah Clark: Muy interesante. Y hemos estado hablando mucho últimamente sobre el pensamiento sistémico en el programa, así que esto encaja perfectamente con nuestra temática.

Así que, de hecho, fuiste el presentador fundador del podcast Product Manager. Así que gracias por sentar las bases aquí para el programa. Fue, quiero decir, en 2022. No hace tanto tiempo, pero en tierra de producto eso parece décadas ahora. La disciplina se veía completamente distinta. Así que, ¿cuáles crees que han sido los mayores cambios desde entonces hasta ahora?

Retrocede en el tiempo y compara cómo era la disciplina antes y qué estás viendo actualmente en el campo.

Michael Luchen: Sí, es una muy buena pregunta porque creo que en nuestra industria sentimos esa constante ola de cambio que tenemos que surfear. No hay un proceso, estructura o manera fija en la que colaboremos siendo product managers y con equipos de producto para lograr un gran trabajo y entregarlo a nuestros clientes.

Así que es muy difícil responder esta pregunta porque, honestamente, mientras la contesto, estoy pensando en lo que viene. ¿Cómo ha sido ese cambio? Cuando empecé a presentar este pódcast, en ese periodo existían dos corrientes de pensamiento enfrentadas.

O eras del tipo fábrica de funcionalidades, con un proceso muy definido para bien o para mal. O bien eras del tipo agile scrum en casi un culto a la metodología. Los equipos debían elegir su veneno o, si estabas en una gran empresa, era SAFe. Y ahora veo que eso ha pasado a segundo plano.

Esos procesos siguen ahí. El waterfall sigue, scrum sigue, SAFe sigue estando para bien o para mal. Pero lo que veo que están haciendo los equipos que tienen éxito es mirar a su propia cultura de producto, su forma de pensar, y eligen y combinan piezas de cada proceso sin etiquetarlo como proceso.

Realmente crean una manera sistemática de enfocar la construcción de gran producto y de divertirse en el proceso, lo que lleva a ese descubrimiento y entrega continuos.

Hannah Clark: Bien. Quiero cambiar un poco de tema y hablar de algo que no solemos tratar en el programa, pero que creo que es muy interesante: una historia de fracaso.

Mencionaste antes, en una conversación previa, que tuviste una iniciativa de transformación en Float que fracasó la primera vez. ¿Qué sucedió? ¿Cuál es la autopsia de esto y qué has aprendido tras ello?

Michael Luchen: Sí, empecé en Float después de mis nueve años en el mundo de agencia, teniendo el privilegio de trabajar con tantas organizaciones distintas.

Vi de todo en patrones de pequeñas empresas, grandes empresas, empresas superando esa barrera de crecimiento. Así que llegué a Float y observé algunos de esos patrones. Estuve hablando con todos, arriba, abajo, y a lo largo de la organización. Todos coincidían en los puntos de dolor sobre el proceso.

Y lo que frenaba nuestra capacidad de entregar buen trabajo. Así que llegué, me gané la confianza del CEO y de los dos cofundadores para dar una presentación en persona en el primer encuentro de toda la empresa, pocos meses en el puesto. Les dije: vamos a pasar a squads (escuadrones). Va a ser genial.

La presentación fue muy buena. A todos les gustó, incluidos los dos cofundadores. Todos durante ese encuentro decían que esto realmente resonaba, que resolvería todos nuestros problemas. Pero, en los meses posteriores, todo se disipó y volvimos a nuestras viejas formas de trabajar. Me di cuenta, mirando hacia atrás, de que aunque llegué diciendo cuál era el problema y todos estaban de acuerdo, y con la manera de solucionarlo, la realidad es que no era el momento adecuado para un cambio tan grande de procesos.

Parte de eso era por cómo había crecido la organización y por la especialización de roles, como en ingeniería. Entonces, si necesitábamos un perfil muy específico para una funcionalidad, sólo había una persona que podía hacerla, y eso siempre complicaba cualquier intento de squads sostenibles.

La otra lección es que el cambio cultural toma tiempo. No es sólo una presentación, aunque todos lo aprueben. Requiere una serie de conversaciones continuas, matizadas, a nivel individual y de equipo. Nunca lo olvidaré.

Es curioso, porque hablando luego con el CEO sobre eso, hoy lo recordamos con humor, como ese arranque con todas las ganas de cambiar... y luego nada pasó.

Hannah Clark: Supongo que esto es como el pensamiento de sistemas: tienes que considerar todos los motivos por los que algo podría no funcionar y, luego, evaluar qué otros factores contextuales pueden informar cómo volver a intentarlo en el futuro.

Ahora quiero hablar del lado práctico de la transformación. Desarrollaste un marco para mapear puntos de dolor en toda la organización usando Miro, una herramienta muy conocida. ¿Cómo identificaste, cuál fue el proceso para detectar los puntos de fricción más allá del producto y cómo era el día a día de ese proceso?

Michael Luchen: Sí. Creo que incluso antes de meterte en las herramientas, debes tener curiosidad y empatía. Recuerdo que cuando empecé en Float, y esto vale igual para otros clientes en Crema, escuchas muchos dolores y desafíos como "tarda mucho en llegar el diseño para poder programar".

O tal vez no están alineados con lo que queremos construir, o no hay alineación clara en el alcance o definición de hecho. Todos esos puntos de dolor que sentimos a diario y que nos dice nuestro equipo. Es fácil actuar por impulso y usar eso para forzar una solución específica si eres líder de ese equipo.

A mí, como director de producto en Float, supervisando managers, data, UX research y, por un tiempo, el diseño antes de que se convirtiera en su propio departamento... Naturalmente, mi instinto es proteger a mi equipo, pero tuve que dejar eso de lado para este ejercicio y reunirme uno a uno con gente de toda la organización: ingenieros, marketing, customer success y ventas. ¿Qué funciona bien? ¿Qué te falta? ¿Qué puntos de dolor tienes y cómo impacta en el producto y su comunicación al cliente? Es sólo una conversación honesta, sin juzgar ni buscar culpables.

Si lo planteas así, consigues mucha información que luego puedes plasmar en notas en una pizarra Miro y empezar a identificar los patrones. Cuando tienes eso, comparas el proceso establecido y es fácil ver las discrepancias.

A partir de ahí, mapeo esas discrepancias y los temas en un nuevo proceso visual. Eso lo uso como base para lograr alineamiento con quienes participé, pero también con toda la organización, arriba y abajo, sobre los cambios de proceso que queremos probar.

Cuando tienes ese respaldo, porque lo construiste sobre problemas reales de la organización, casi no hay resistencia.

Hannah Clark: Genial. Quería insistir en ese punto porque creo que conseguir ese respaldo suele ser lo más difícil.

Aunque la solución propuesta en la superficie traerá alivio, el cambio es difícil. Es muy difícil modificar los hábitos y formas de trabajar. Por ejemplo, mencionaste antes que Float tenía una cultura de ingeniería muy especializada, así que pasar a squads transversales fue recibido con cierta tensión.

¿Cómo gestionas situaciones como esa y facilitas cambios al intentar transformar y mejorar la vida del equipo? ¿Cómo consigues ese respaldo cuando hay tensiones?

Michael Luchen: Buena pregunta. Y aquí es donde entra, sin quererlo, la propia intención de Float como producto: la gestión de recursos.

Y tener esas conversaciones que llevan a claridad y respeto. Sin líneas claras de comunicación y respeto mutuo con socios de la organización, surgen las fricciones, pero si te enfocas en la colaboración, por ejemplo, si hay una persona muy especializada que queremos dedicar a un squad, pero también apoya una infraestructura clave, no hay una respuesta blanco o negro. Las opciones suelen ser contratar a alguien, pero incorporar a alguien con la calidad y nivel de Float lleva tiempo.

Entonces, ¿cuál es el plan B? Ahí es donde entra la planificación de capacidad y gestión de recursos y el alineamiento en esos compromisos. Esto tiene dos ángulos. Uno, la persona en sí: ¿se siente cómoda con esa asignación a medio tiempo, tiempo completo...? ¿Cómo sirve a las necesidades específicas de soporte/mentoría en la organización? ¿Estamos de acuerdo en ese compromiso? A menudo la respuesta es que no queremos dividir el foco. Así que todo vuelve al roadmap de producto. Aquí es donde veo el valor de la combinación de ops y producto: no puedes decidir cómo asignar a alguien sin el contexto de las prioridades de producto y las decisiones o postergaciones que implica nuestra estrategia de squads.

Hannah Clark: Muy buen punto. ¿Cómo encajan los rituales prácticos en ese escenario? Creaste algo llamado Un Equipo, Un Roadmap y diseñaste sprints de diseño asíncronos para facilitar esto.

¿Cómo evolucionó y cuáles fueron los aprendizajes clave de ese tiempo?

Michael Luchen: Sí. Un equipo, un roadmap fue la culminación de mi trabajo de transformación de producto en Float. Después de aquel fallido intento de squads, que más adelante se convirtió en una implementación exitosa y duradera cuando hicimos la inversión cultural y de contratación. Pero "Un equipo, un roadmap" surgió cuando Float estaba escalando: teníamos squads de producto, squads de plataforma, trabajo de marketing...

Ahora los de marketing de producto preguntaban: ¿qué se viene? Ventas preguntaba: ¿cómo cuento de manera auténtica lo que se está por lanzar o no? ¿Cómo involucrar a los PMs como referentes en nuevas oportunidades de clientes? Y los cofundadores: ¿cómo presupuestamos bien?

"Un equipo, un roadmap" consistía en que cada squad y equipo de plataforma gestionaba su propio roadmap de manera separada y lineal. Decidimos unificarlos en una forma sistemática, lo más lean posible, brindando el máximo contexto actualizado y quitando la menor cantidad de tiempo posible de quienes participan.

Primero la parte de sistemas: usando las funciones de roadmap más nuevas de Linear, creamos excelentes vistas guardadas de todos los flujos en curso de producto, plataforma, etc. Esto fue útil porque los equipos sólo debían actualizar el estado en Linear de manera liviana. Esas actualizaciones se enviaban automáticamente a un canal de Slack. Cualquiera en la organización podía suscribirse y ver qué pasaba aunque estuviera lejos del trabajo de producto. Ese canal incluía un demo de Loom o un enlace a un entorno de pruebas para experimentar.

Junto a eso, organicé un product huddle mensual de 60 minutos centrados sólo en demos: los PMs compartían y celebraban el trabajo de su equipo, los de plataforma también. Aunque eran quincenales, la asistencia era mensual porque teníamos miembros en más de 15 husos horarios. Así alternábamos horarios y respetábamos al máximo el tiempo de todos.

Esta transparencia radical que se compartía en esos huddles y actualizaciones automáticas creaba confianza, una cultura de entendimiento compartido para tomar juntos decisiones efectivas entre equipos.

Hannah Clark: Sí, y percibo un gran nivel de empatía hacia los distintos estilos de aprendizaje de las personas y su capacidad de integrarse a la estrategia a su ritmo, logrando varios niveles de participación según los distintos stakeholders. Aprecio este enfoque por capas.

Michael Luchen: Eso también enlaza con lo que comentabas de sprints de diseño. En Crema pasé años liderando design sprints con clientes y equipos nuevos, y creo que hoy no hace falta seguir el sprint de diseño al pie de la letra, sino combinar herramientas y personalizar el proceso para ese alineamiento.

Así que en Float trasladé eso a sprints asíncronos: una pizarra en Figjam, por ejemplo, donde una semana de ejercicios pasaba a dos semanas asíncronas; gente de un hemisferio contribuye mientras el otro duerme, revisa y comenta después. Esto permite mayor participación, cada uno aporta desde su contexto y entorno con seguridad y puede dejar comentarios.

Y si surgía algún tema conflictivo, se podía elevar a una reunión sincrónica.

Hannah Clark: Suena casi a una dinámica tipo "amigo por correspondencia" versus "clase presencial": más seguridad psicológica y menos juicio inmediato en compartir ideas.

Michael Luchen: Exactamente, sí. Y poder alternar entre ambos enfoques, en función de lo que convenga mejor al equipo.

Hannah Clark: Muy bien. Voy a cambiar de tema porque no podemos terminar sin mencionar la palabra de dos letras favorita de todos: IA, por supuesto. Cuando presentabas el programa, nadie hablaba en serio de IA, y ahora es lo único de lo que quiere hablar la gente.

En ese momento hablábamos de la IA como una posibilidad, pero no parecía que la tecnología estuviera lista para ser útil, y ahora todos corren por adoptar IA en cada flujo de trabajo y producto. En Float, ¿cuál fue el enfoque para integrar IA? Es un tema enorme y tú estuviste muy involucrado. ¿Cómo gestionaste eso?

Michael Luchen: Es muy interesante porque cuando salió ChatGPT me quedé impresionado y fascinado por el producto, como todos.

Empecé a experimentar y a investigar oportunidades de producto más por interés personal. Luego pensé: ¿cómo aplicar esto al producto de Float? Así que empecé a mapear ideas y derivó en un proyecto personal en el que elaboré un informe en Notion con mis propias creencias de hacia dónde iría la tecnología LLM, cómo impactaría en tres, seis, doce meses, tres años y en particular en SaaS B2B como Float.

Agregué referencias de la industria: ¿en qué apuestas de producto hay que invertir ahora, cuándo es el mejor momento, sin dejar de lado todo lo demás para lanzarse sólo a IA? Incluí bocetos, mapeos de datos y la API para pensar: si esto estuviera disponible para LLM, ¿qué podríamos hacer?

Todo era curiosidad, pero el documento generó emoción y respaldo en el equipo directivo. Consultamos con una consultora de IA generativa en Melbourne, Move 37, que nos guió sobre cómo abordar la IA de manera alineada con el valor que queremos ofrecer al usuario. Lo primero fue diferenciar datos estructurados de no estructurados.

Estábamos mejorando el producto de reportes, que puede hacerse sólo con datos estructurados y cambios en la base de datos. Lo no estructurado es lo ambiguo, lo propio de ChatGPT o Claude, donde la IA generativa aporta más valor. Así que separamos los experimentos.

El punto central fue enfocarse en los flujos de agentes. Nos ayudaron a crear un "playground" de agente para experimentar y ver cómo podríamos implementar eso en producto. Así que ahora, como product manager, ya no sólo veo el flujo de usuario (el usuario hace X para conseguir Y), sino también el flujo de agente: lo que la IA hace detrás para ayudar al usuario.

Esto difiere de muchos otros lugares, donde todo se reduce a una caja de chat. Esos métodos son válidos y rápidos para interactuar con datos, pero no es la experiencia de usuario ideal donde la IA puede integrarse y mejorar con el tiempo, aunque el usuario ni siquiera sepa que está usando IA.

Hannah Clark: Cambiando de tema una vez más, hablemos de cómo los PM deben actuar hoy, porque estamos viviendo transformaciones a todos los niveles, tanto culturalmente como en la industria, y en el propio rol de product manager, que paso de ser muy ejecutor a mucho más estratégico.

Desde tu experiencia liderando transformaciones, ¿cómo recomiendas que los líderes de producto ayuden a sus PMs a ajustar su enfoque y adoptar estos cambios, a veces muy radicales, en competencias y foco?

Michael Luchen: Aquí viene una opinión polémica que siempre he defendido y mantengo aún más hoy: Un gran product manager, o quien ocupe ese rol, debe mantener ejecución y estrategia al mismo tiempo. Y sé que parece polémico porque suele decirse, y tu pregunta lo sugiere, que si sólo ejecutas, eres un gestor de proyectos glorificado; y si sólo eres estratégico, eres un pequeño CEO. Creo que ambos planteamientos son tóxicos.

Lo bueno es que el PM tiene hoy una habilidad única para guiar una organización equilibrando ambas cosas: ¿Cómo ejecutamos eficazmente, sumando las capacidades de todo el equipo (dev, diseño, QA...) y sirviendo estratégicamente las oportunidades del negocio, el mercado y el cliente?

Esto es fácil de decir y difícil de hacer. Por eso surgieron esas posturas extremas, diciendo que ejecución y estrategia son incompatibles. No estoy de acuerdo, porque creo que, como conté en mis historias, cuando lideras con empatía y curiosidad, tienes todo el contexto ante ti. Usando una pizarra Miro o Figjam llena de notas, vas moviendo piezas como un arquitecto y encuentras la mejor y más eficiente manera de ejecutar una estrategia que garantice resultados y respete el tiempo de todos.

Esto significa que, para los más orientados a ejecución, deben abrirse a la curiosidad y pensar estratégicamente: ¿qué escuchan de ingeniería sobre deuda técnica u oportunidades nuevas, qué trae diseño en stack o enfoque metodológico, y qué escucha producto del cliente y el negocio? Juntando todo eso puedes tener una gran ejecución mientras avanzas estratégicamente.

Hannah Clark: No creo que sea polémico, ¡creo que es una excelente opinión! Ahora terminemos con algo más personal y ligero. Me contaste que haces proyectos de IA con tu hijo, lo cual me parece genial.

Cuéntame, porque hemos charlado en el newsletter —suscríbanse si no lo han hecho— sobre cómo la paternidad puede informar tu enfoque como product manager y líder de producto. ¿Cómo tu vida como padre ha influido en tu estilo de liderazgo y transformación?

Michael Luchen: Intento dejar que ambas facetas de mi vida se influyan mutuamente. Me gustaría presumir de tener un balance perfecto, pero lo cierto es que mi trabajo también es mi pasión personal, así que intento unir ambos mundos. Mi hijo tiene cinco años y medio, y un día vino diciendo: "Papá, ¿podemos hacer un videojuego ninja para la PlayStation?"

Podía decirle: sí, lo pensamos, o sí, ¡averigüémoslo! Nunca había hecho desarrollo de videojuegos, pero pensé que podía usar la experimentación que hago en el trabajo con él. Así que le dije: usemos esta tecnología nueva llamada IA en el ordenador de papá y lo hacemos.

Le pedí que dibujara cómo sería el personaje y la jugabilidad (ideación y descubrimiento). Juntó una montaña de hojas. Más tarde nos sentamos, le hice preguntas sobre el juego, grabé la entrevista con transcripción automática, y la puse en ChatGPT, pidiéndole que generara un documento de desarrollo de juego, orientado a un programador junior.

Eso es como la recogida de requerimientos. Después copié el prompt en Bolt y lo ajusté un poco, se generó el juego y ahora lo testeamos. Mi hijo decía que el sonido no funcionaba, los controles estaban raros... Así que dimos feedback y fuimos iterando: loop de producto. Al final, él emocionado lo compartió con familia y amigos. Luego quiso convertirlo en película 3D, así que usamos VO de Google. Y así sigue la iteración.

Le apliqué el pensamiento de producto. Al final, pensar en producto se basa en el método científico y la formulación de hipótesis, así que trato de unir ambos mundos en mi día a día.

Hannah Clark: ¡Es un ejemplo mucho más completo de lo que solemos oír! La mayoría habla de persuadir a los niños para que coman brócoli, pero en tu caso tu hijo tendrá currículo de desarrollo de producto antes de saber leer. ¡Muy impresionante!

Michael Luchen: Recuerdo que cuando tenía su edad soñaba con trabajar en Nintendo, leía Nintendo Power... Ahora no hace falta, él puede decir lo que quiere y hacerlo realidad. Es increíble.

Hannah Clark: ¡Gracias! Es un ejemplo asombroso y, como madre, muy inspirador. Tengo que anotar nuevas ideas para días de lluvia.

Michael Luchen: Sí, claro. Es una buena opción.

Hannah Clark: Muchísimas gracias por volver, ponernos al día y contarnos en qué has estado. ¿Dónde te puede seguir la gente en Internet?

Michael Luchen: Sí, pueden ir a michaelluchen.com y allí están todos mis enlaces. Encantado de conectar, no duden en contactarme.

Hannah Clark: Muchas gracias, Michael.

Michael Luchen: Genial, gracias Hannah. Encantado de volver.

Hannah Clark: Gracias por escuchar. Para más ideas, guías prácticas y reseñas de herramientas, suscríbete a nuestro boletín en theproductmanager.com/subscribe. Puedes escuchar más conversaciones como esta suscribiéndote a The CPO Club donde sea que escuches tus pódcast.