Cuando construir se abarata, decidir se encarece

Todos los equipos de producto lo han sentido este año: una función que llevaba un sprint lleva una tarde, y el backlog se vacía más rápido de lo que nadie puede rellenarlo con cosas que merezcan construirse. Este artículo responde a qué hace eso con el rol de producto, con las mediciones publicadas hasta ahora y con la muestra y la fecha junto a cada cifra.

¿De verdad construir es más barato?

Sí, y la cifra honesta es menor que la sensación. El informe DORA 2025, publicado por Google Cloud el 23 de septiembre de 2025 con casi 5.000 encuestados, encuentra que el 90 % usa IA en el trabajo y, por primera vez, una relación positiva entre la adopción de IA y el rendimiento de entrega. El mismo informe encuentra que la adopción de IA sigue teniendo una relación negativa con la estabilidad de la entrega: se envían más cambios, y más de ellos se rompen.

La encuesta de Lenny Rachitsky y Noam Segal a 1.750 product managers, desarrolladores, diseñadores y fundadores, publicada el 23 de diciembre de 2025, halló que más de la mitad ahorra al menos medio día a la semana en sus tareas más importantes. La misma encuesta halló que el 92,4 % señala al menos un inconveniente significativo de las herramientas. Ambas cifras son ciertas a la vez, y un equipo que solo cita la primera planifica sobre una ficción.

¿Por qué la ganancia parece mayor de lo que es?

Porque quienes la experimentan se equivocan en la misma dirección. METR realizó un ensayo controlado aleatorizado, publicado el 10 de julio de 2025: dieciséis desarrolladores experimentados de código abierto, 246 tareas reales de sus propios repositorios, cada tarea asignada al azar a permitir o prohibir herramientas de IA. Con IA permitida, los desarrolladores tardaron un 19 % más. Antes del estudio habían previsto ir un 24 % más rápido, y tras vivir la ralentización seguían creyendo que la IA les había hecho un 20 % más rápidos.

Dieciséis desarrolladores son una muestra pequeña y las herramientas eran modelos de principios de 2025, cosa que los propios autores escriben. Lo que el ensayo establece es más estrecho y más útil que un veredicto sobre la IA: la velocidad percibida es un instrumento poco fiable. Un equipo de producto que quiera conocer su velocidad real tiene que medirla — tiempo de entrega, tasa de fallos por cambio, las cuatro métricas DORA — con las herramientas activadas y desactivadas.

¿Adónde se mueve el cuello de botella?

Al criterio. Cuando la producción deja de ser el límite, tres decisiones fijan el resultado, y ninguna se acelera con un asistente de código.

• Qué construir: qué problema, para quién, con qué frecuencia ocurre y qué cuesta esperar tres meses.
• Cómo sabrás que funcionó: la cifra que tiene que moverse, escrita antes de construir, con la fecha en que se leerá.
• Si un usuario puede fiarse: para una función de IA, los casos en que puede responder, los casos en que debe abstenerse y cómo se muestra la confianza.

Marty Cagan escribió el 30 de diciembre de 2024 que «the PM role becomes more essential but also more difficult with generative AI-powered products, not less», y reservó su entusiasmo para la combinación de «someone with very strong judgement» y las herramientas. Teresa Torres dijo lo mismo desde el lado del discovery en abril de 2026: «Building is very cheap now. That doesn’t mean we should build every idea we have.» Ambos describen un rol cuyo insumo escaso es el criterio sobre qué merece existir.

¿Qué hace un equipo de producto con esto?

De aquí salen tres movimientos prácticos, y cada uno es barato de empezar.

• Mide la velocidad con las herramientas activadas y desactivadas durante un mes, y lee la tasa de fallos por cambio junto al rendimiento. El hallazgo de DORA sobre la estabilidad es el que la mayoría de los equipos descubre tarde.
• Escribe la decisión antes de construir: una página con el problema, las alternativas sobre la mesa, lo que se dejó de lado y lo que tiene que ser cierto dentro de dos meses.
• Dedica las horas liberadas al discovery y a los evals. Una entrevista sintetizada por una persona y después por un modelo, y una función de IA especificada como casos de prueba antes del primer prompt, es adonde va ahora la semana.

El método de priorización está descrito en decidir qué construir a continuación. Para un fundador con runway limitado, la misma lógica decide qué tiene que demostrar la primera construcción, y la página para fundadores expone esa secuencia.

Así trabaja el estudio con esto

La respuesta de Torn Studio es un modelo de entrega: una persona sostiene el rol de producto y construye con herramientas de IA, de modo que una decisión tomada el lunes está en código la misma semana. El coste se dice tan claro como la ganancia. La semana de una persona es la capacidad, y a un equipo que necesita tres roles de producto en paralelo le conviene contratarlos. El Product Management se cobra por proyecto, con el alcance definido de antemano y el precio fijado antes de empezar.