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

Cómo detecté que la landing hablaba a todo el mundo y no le decía nada a nadie. Y lo que hice para arreglarlo.

Savia llevaba unos días en producción y algo no cuadraba. Las visitas llegaban — mucho más de lo que esperaba para ser un proyecto que acabo de lanzar. Pero esas visitas venían de mis redes y de esta newsletter. Gente que me sigue, que quería ver qué estaba montando, pero que no tenía en muchos casos una intención real de registrarse. Era curiosidad, no demanda. Y eso era completamente normal y esperado.

Lo que no era normal era que, entre los que sí tenían intención, la conversión era bajísima. Un 17%. No tenía claro cuál era el problema exacto. Así que antes de tocar una sola línea de código, había que invertir tiempo en entender qué estaba pasando.

Esta era la landing en aquel momento, para que entiendas al final todos los errores que cometí y que no vi a tiempo.

Antes de tocar nada, hicimos wireframes y preguntamos

Diseñé tres versiones alternativas de la landing con conceptos y copy distintos para entender qué funcionaba y qué no, y qué dirección merecía la pena explorar antes de invertir tiempo en implementación.

Un concepto más funcional y directo. Uno con más voz personal, casi narrativo. Y uno híbrido que intentaba combinar lo mejor de los dos.

Con los tres conceptos listos, los mandé a una pequeña encuesta. La conclusión cuantitativa decía que la landing actual era la que más claridad y confianza generaba. Pero cuando leí los comentarios abiertos, vi algo diferente:

«El titular de la actual + el contenido de la versión híbrida». «Me gusta la fuerza del mensaje actual, pero la otra explica mejor cómo funciona». «Las frases que hablan a dos personas distintas a la vez no casan».

Y entre las respuestas, un tuit de David Alarcón, un ex-compañero de Factorial y un máquina de hacer landing pages, que me lo dijo sin filtros: «Tu landing habla a dos públicos a la vez. La información está mezclada.»

Yo había pensado en eso al diseñarla. Había procurado poner titulares que hablasen a los dos targets a la vez. Había puesto una sección que diferenciaba explícitamente entre mentor y mentorizado. Lo había resuelto, pensé. Pero era obvio que no.

Lo que se me había escapado es que esa sección diferenciada estaba demasiado abajo en el scroll. Todo lo que venía antes — el hero, el mensaje principal, la primera impresión — hablaba principalmente a uno de los dos públicos. Epic fail. El que llegaba con el interés equivocado se iba antes de llegar a la parte que era para él.

Eso es lo más valioso que puede salir de una encuesta pequeña: no el dato, sino el patrón. Y aquí el patrón era clarísimo: hablar a dos audiencias en el mismo espacio, sin separación explícita, no le habla a ninguna.

El insight que cambió la dirección

El aprendizaje que más me quedó es deceptivamente sencillo: un hero, un target. Cuando intentas hablar a dos audiencias en el mismo párrafo, no le hablas a ninguna.

Cada persona que llega a tu landing busca verse reflejada — quiere leer algo y pensar «esto es para mí». Si el primer mensaje que recibe mezcla dos necesidades distintas, ninguno de los dos se siente interpelado.

Para un marketplace two-sided como Savia, esto es especialmente relevante. Necesitas atraer a los dos lados. Pero intentar hacerlo simultáneamente, en el mismo espacio, con el mismo copy, no funciona.

Tienes dos audiencias con problemas y motivaciones completamente distintas, y una sola landing para captarlas. La tentación es hablar a las dos a la vez para no dejar a nadie fuera. El resultado es que no conectas con ninguna.

Lo que decidí hacer

Haciendo research de landings dirigidas a dos públicos distintos, encontré un patrón que resolvía exactamente esto: una sola landing con dos narrativas completas que se alternan según quién está mirando.

No dos páginas distintas. No dos rutas distintas. Una sola página que cambia todo su contenido — hero, explicación, pasos, CTA — dependiendo de si quien la visita es mentor o mentorizado. Y lo hace de forma explícita, con un toggle visible que dice: «Quiero mentorizar» / «Busco un mentor».

Es un patrón que tiene mucho sentido para nuestro caso. Cada audiencia ve exactamente lo que necesita ver. El mentor no tiene que filtrar información que no le es relevante. El mentorizado tampoco. Y nosotros no tenemos que elegir a cuál de los dos le hablamos — les hablamos a los dos, pero por separado.

El proceso de escribir el copy para cada versión me obligó a frenar y reflexionar. Cuando te obligas a pensar solo en el mentor, la pregunta cambia: ¿por qué alguien con experiencia debería dedicar tiempo a esto? La respuesta no es la misma que ¿por qué alguien que busca orientación debería fiarse de Savia? Son conversaciones distintas, y merecen contenidos distintos.

Después de muchas iteraciones de copy — más de las que me gustaría admitir — llegamos a los titulares que mejor capturaban cada perspectiva:

  • Para el mentorizado: «Aprende de quien ya está donde tú quieres llegar.»

  • Para el mentor: «Si crees que tu experiencia puede ayudar a alguien, probablemente tengas razón.»

Son frases que hablan a una sola persona. Y eso, al final, era lo que necesitábamos. La conversión ha mejorado. El feedback de personas a las que les pasé el resultado final es que funciona mucho mejor para entender de un vistazo que Savia va de dos tipos de personas que quieren hablar entre sí.

Si tienes curiosidad por ver cómo quedó completa, puedes verla en savia.company. De paso, puedes registrarte si te apetece mentorizar a alguien o ser mentorizado. O incluso si quieres ser la dos cosas 😉 Y si estás construyendo algo con dos audiencias distintas y tienes dudas de cómo comunicar a las dos sin diluir el mensaje, me encantaría saber cómo lo estás pensando.

Artículos anteriores de la serie: