Ayer a las 22:47, estaba en la cama con auriculares, Lost On You de fondo, una coquita fría en mano… y me convertí en eso que juré destruir: el famoso «en mi local funciona».
Después de un año boludeando con IA, haciendo 800 trillones de web apps, jueguitos y la mar en coche, me propuse probar Claude Code en serio. El resultado? Saqué mi primer PR a producción en Inbound Tools. Hoy lo mostré en la demo, y me sentí rarísimo estando del otro lado.
Pero lo importante no es el PR. Es lo que esto expone cuando el costo de shippear se vuelve ridículamente bajo.
El problema que nadie quiere admitir: la priorización es una mierda
Si ahora «cualquiera puede shippear» mucho más rápido… los PM con mal criterio de priorización quedan en bolas.
Porque antes podías esconderte atrás de:
- «no hay tiempo»
- «no hay recursos»
- «no hay tu tía»
Ahora, si elegís mal qué construir, queda expuesto en tiempo récord.
Y acá está el verdadero insight: cuando herramientas como Claude Code, Cursor, y toda la familia de IA generativa bajan el costo de desarrollo casi a cero, lo que queda como bottleneck no es el código. Es el criterio.
Como señala Atlassian en su guía de priorización, concentrarse solo en agregar features sin pensar en el outcome deseado no lleva a ningún lado. Y con IA acelerando todo, esos errores de priorización duelen más rápido.
Mi papelón: mejorar la tabla de campañas
Bueno, no hice un PMF generator como primer PR… mejoré la tabla de campañas para ver cuáles andaban bien sin abrirlas una por una.
Sí, un papelón. Y no es mi primer producto con campañas, eh.
Pero siempre aparecía «algo más importante» para shippear.
Mientras tanto, el equipo perdía 15–20 minutos al pedo por día revisando 30 campañas a mano. Karma puro.
Esto pasa todo el tiempo en equipos de producto. Priorizamos lo sexy, lo que se ve bien en la roadmap, lo que el CEO mencionó en el all-hands. Pero las pequeñas fricciones que joden la vida del equipo todos los días quedan enterradas bajo la pila de «nice to have».
¿El resultado? Acumulás deuda de experiencia. No técnica, experiencia. Y eso cansa, quema, desmoraliza.
Cómo shippeé en 90 minutos (y qué aprendí)
Después de la learning session del workflow con Tomi (maestro), me puse auriculares, y en 1h30:
- Bajé el repo, hice branch, conecté Claude
- Le pasé un PRD en plan mode, aprobé, ejecutó
- Probé en local, subí
- Hoy el dev revisó, ajustamos conflictos
- A prod
Fast forward hoy a la mañana: Tomi me dijo «en prod, ingeniero». Qué linda sensación.
Pero acá está la movida: no fue magia. Fue un problema pequeño, bien definido, con scope claro. La IA no resolvió el «qué», resolvió el «cómo».
Y eso cambia todo el juego para los equipos de producto, porque ahora el cuello de botella no está en escribir código. Está en saber qué carajo construir primero.
El gap ya no está en el código. Está en el criterio.
Cuando el costo de shippear se vuelve ridículo, lo caro no es construir. Lo caro es decidir qué vale la pena.
Esto es algo que vemos constantemente en SquadS Ventures, donde trabajamos con equipos de producto que enfrentan este dilema todos los días: ¿construimos esto o aquello? ¿le metemos a esta feature o a la otra?
Las herramientas de IA ya están acá. Claude Code, GitHub Copilot, Cursor… todas aceleran el desarrollo. Pero ninguna te dice qué priorizar.
Si sos PM, líder de producto, o fundador técnico, tu trabajo cambió. Ya no es conseguir recursos para construir. Es decidir brutalmente bien qué se construye.
Porque si elegís mal, ahora lo vas a saber en una semana, no en tres meses.
¿Y vos? ¿Cómo estás priorizando en tu equipo? ¿Sentís que la velocidad de desarrollo te está exponiendo gaps en tu criterio de producto? Me encantaría saber qué están viendo del otro lado.
