El valor de un PM nunca estuvo en gestionar el backlog. La IA solo lo hace evidente.

Esta semana vi una entrevista de Lenny Rachitsky a Cat Wu, Head of Product de Claude Code en Anthropic. Y me dejó dando vueltas a algo que llevo tiempo masticando. No sobre hacia dónde va el rol de producto — sino sobre dónde estuvo siempre su valor real.

Cat Wu entrevistada por Lenny Rachitsky

Cat Wu trabaja junto a Boris Cherny, el creador de Claude Code. Ella lo describe como una dinámica de complementos: uno más visionario, otro más ejecutor. Y lo que dice de esa relación me parece importante porque pone sobre la mesa algo que muchas veces se ignora: en producto hacen falta tanto personas que digan hacia dónde ir como personas que sepan construirlo. Visionarios y ejecutores. Las dos cosas.

El criterio siempre fue lo que importaba

Lo que más me resonó de toda la conversación es su visión de qué define a un PM exitoso: alguien con fantástico product taste. Alguien que demuestra buen criterio sobre en qué problemas enfocarse.

No alguien que gestione un backlog. No alguien que pase horas coordinando a medio mundo. No alguien que trabaje en roadmaps a 12 meses. Y esto no es nuevo.

El valor real de un PM siempre estuvo en identificar los problemas que merece la pena resolver.

Es algo sobre lo que ya escribí hace tiempo: el trabajo de un PM no es gestionar un backlog, es asegurarse de que estamos construyendo productos que resuelven problemas por los que un número suficiente de clientes está dispuesto a pagar. Lo que pasa es que durante años, el día a día se llenó de gestión: mover tickets, alinear stakeholders, mantener roadmaps actualizados. Tareas necesarias, pero que no son el trabajo — son la burocracia alrededor del trabajo. Si dedicas tu día a eso, no haces product management, haces bullshit management.

La IA no cambia lo que un PM debería ser. Acelera que el foco se ponga donde siempre debió estar. Porque un PM que solo gestione backlog y mueva tareas va a ser reemplazable por una skill de Claude. Literalmente. No es una metáfora.

Mi querido Máximo Gavete lleva tiempo explorando esta idea en su newsletter. En la edición 290 — «Frente al vértigo, criterio» — lo dice de una forma que se me quedó grabada: «donde reside nuestro valor diferencial frente a la respuesta artificial de la máquina, es nuestro criterio.»

Y describe cómo los roles tradicionales — producto, diseño, ingeniería — se están difuminando, y cómo eso no es una amenaza sino una maduración: «cuando el rol deja de ser una coartada, el trabajo recupera una dimensión más honesta.»

Cat Wu dice lo mismo desde la trinchera de Anthropic. La IA puede generar, sintetizar, ejecutar. Pero decidir qué merece ser construido sigue siendo humano.

Pensar en semanas, no en trimestres

Cat Wu describe un cambio de cadencia radical en Anthropic: de ciclos de meses a semanas a días. Y lo que propone no es simplemente «ir más rápido» — es cambiar la unidad de planificación.

En vez de alineamiento por OKRs trimestrales y roadmaps por Q, la pregunta es otra: en qué métrica quiero impactar esta semana y cuál es la forma más rápida de validar una idea y ponerla en manos de los usuarios.

Acortar el tiempo entre idea y producto en manos del cliente. Eso es todo.

Para eso un PM necesita dos cosas.

  • Claridad absoluta en su ICP y en el problema que resuelve. Saber cuáles son sus goals y las áreas de negocio donde se espera su impacto.

  • Ayudar al equipo a ir más rápido en todo el proceso end-to-end de construir producto.

El definition of done de un PM no es feature shipped

Y aquí hay un matiz que me parece clave. El definition of done no termina cuando se entrega la funcionalidad. El E2E de verdad es: ingeniería desarrolla, la feature está lista para lanzar, se prepara la documentación (FAQs, help center), se preparan los materiales de product marketing, se coordina el lanzamiento. El definition of done llega hasta que el cliente conoce y ha probado la funcionalidad.

La métrica que importa no es cuántas features entregas. Es feature activation y retention. ¿Cuántos usuarios han descubierto, probado y adoptado lo que has construido? Si la respuesta es «no lo sé» o «pocos», da igual lo rápido que hayas entregado.

Lo que viene: más velocidad, ¿menos consistencia?

Cat Wu también habla del futuro de los equipos de producto. Más ingenieros con product taste. Más PMs que guíen a ingeniería. Más roles híbridos donde producto, diseño e ingeniería se difuminan — exactamente lo que Máximo describe como esa disolución de silos que da vértigo pero también libera.

Pero hay un lado B que me parece honesto y que no muchos mencionan: product consistency. Cuando tienes mucha gente probando muchas cosas a la vez, muchos prototipos rápidos, muchas features llegando a manos de clientes… el producto se vuelve menos consistente. Los usuarios tienen más dificultad para estar al día en todo lo que tu producto saca. Y eso obliga a poner foco en algo que hasta ahora en muchos equipos podía ser (era) secundario: feature discoverability.

A cambio, la promesa es real: la capacidad de resolver los problemas de tus clientes más rápido que nunca.

Es una tensión que no tiene solución limpia. Más velocidad implica más riesgo de fragmentación. Pero la alternativa — ir despacio en un mundo que se mueve así — tampoco es opción.

Lo que me quedo de esta conversación es que la IA no está redefiniendo el rol de PM. Está quitando las capas que lo tapaban. Debajo de la gestión, los procesos y los roadmaps bonitos, lo que siempre importó fue el criterio para decidir qué construir. Eso no ha cambiado. Lo que ha cambiado es que ya no puedes esconderte detrás del resto.

Y tú… ¿sientes que tu día a día se parece más a gestionar procesos o a tomar decisiones? ¿En cuál de las dos cosas eres realmente bueno?


La entrevista completa: How Anthropic’s product team moves faster than anyone else | Cat Wu — Lenny’s Podcast