Para animarte a experimentar con IA no hace falta un problema grande. Hace falta uno tonto.

Ayer fue el #nosday26. He pasado el fin de semana en Santiago y me lo he pasado bomba. Me invitaron Alex y Sandra, y no pude negarme a venir. Era una excusa perfecta para ver a Moi, desvirtualizar a Maxi, abrazar a Cousi o enredar un rato con Miguel y muchos más.

Más allá de dar la brasa con una charla que titulé “En esto mi madre no tenía razón”, donde hablé de cómo meter la cabeza en producto, conté algunos de los retos que me he encontrado construyendo productos durante mi trayectoria estos años y lo que he aprendido a nivel personal.

La conversación que se repitió varias veces

Como siempre, una de las mejores cosas de los eventos es el networking: el tiempo compartido con gente a la que ya conoces y con gente que tienes la suerte de conocer ahí.

Hablando con algunos de los asistentes, le dimos vueltas a por qué hay mucha gente usando la IA para tareas concretas (escribir un email, hacer un resumen de una reunión, revisar un texto en inglés) pero sin coger demasiado nivel de profundidad. Algunos decían que el problema es que a muchos no se les ocurre un problema propio que probar a resolver con IA ellos solos. O sea, que es más falta de iniciativa, o de ideas que te fuercen a ir más allá, que falta de capacidad.

No necesitas un problema grande. Necesitas uno tonto

Y ahí es donde le doy la vuelta yo. Creo que el bloqueo no es la falta de un problema importante, es justo lo contrario. Un problema grande pide tiempo, alcance, un plan. Se pospone solo.

Lo que sí funciona es empezar por algo tonto. Una tarea que te fastidie a ti en concreto, un día cualquiera. Algo tan pequeño que no tengas excusa para no probarlo esta misma semana. Te cuento cuál fue la primera tontería que hice yo con IA.

“¿Se va a estar en la playa hoy bien?”

Durante los veranos en Zahara de los Atunes le hago esa pregunta a Aroa demasiadas veces. En la costa de Cádiz la respuesta no es tan trivial como parece. Menos aún para alguien como yo, criada lejos del mar, ajena a mareas, vientos y a lo que realmente significa que “haga Levante”.

Estar bien en la playa depende de la dirección y velocidad del viento, de cómo esté la marea a la hora en la que bajas, de si es Levante o Poniente. Levante con rachas de más de 30 km/h, olvídate. Levante por debajo de eso y mareas bajas, bien. Poniente al atardecer, puede que la sudadera no te sobre.

Así que mi problema tonto para jugar con IA fue ese: ¿Bajamos a la playa? Una pequeña aplicación que me responde. Que mira viento, marea y temperatura, y me dice si se estará bien en la playa hoy hora por hora, mañana, y a grandes rasgos el resto de la semana.

La construí en una mañana, con Claude. Lo más “caro” no fue el código: fue calcular la marea. Probé varias APIs de marea antes de rendirme pero todas o cobraban o daban un dato a medias. Al final tuve que sacarla yo misma a partir de la curva de nivel del mar que sí da gratis un servicio meteorológico marino, detectando dónde sube y dónde baja. Y a lo que más tiempo dediqué fue a entender qué datos miraba Aroa, cómo los interpretaba para decidir y traducir todo eso en el mini-cerebro que te responde.

La invitación

No cuento esto porque conocer este mini proyecto vaya a cambiarle la vida a nadie. La cuento porque fue mi manera de salir de “tradúceme este documento” y “resúmeme esta reunión” y meterme, aunque fuera con algo mínimo, en construir de verdad. Y quiero que hagas lo mismo tú.

No necesitas una idea buena. No necesitas que sirva para nadie más que para ti. No necesitas saber programar (yo tampoco sabía ni sé ahora). Necesitas, solo, una tontería que te fastidie lo suficiente como para dedicarle una tarde. O algo que te genere curiosidad y quieras explorar.

Así que la invitación es esa: coge tu pregunta tonta. La que le haces a alguien todos los veranos, la que repites cada lunes, la que resuelves siempre a ojo porque nunca te has parado a automatizarla. Ábrete un chat con la IA que uses y prueba a trabajar sobre ello. No hace falta que salga bien, ni que sirva para nada más que para aprender y atreverte.

Si te animas y haces algo (o si lo has hecho ya), respóndeme a este email contándome qué hiciste y qué tal fue. Quizás podemos compartir ideas más chulas y así hacemos que otros también se animen.

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