Cuando el cuello de botella ya no es ingeniería

Hace unas semanas uno de los equipos que apoyo terminó un desarrollo en tres días que habíamos estimado para un sprint entero. Usaron Claude Code, tiraron de agentes para la parte más mecánica, y el resultado era correcto. Tests pasando, funcionalidad completa, listo para review.

Lo siguiente que escuché fue una conversación entre dos ingenieros del equipo: "¿Y ahora qué hacemos?".

Era una pregunta genuina. Habían acabado antes de lo previsto y la siguiente iniciativa no estaba lo suficientemente definida como para empezarla. No por falta de ideas (las había), sino porque la capacidad de validar y definir esas ideas no había escalado al mismo ritmo que la capacidad de construirlas.

Esa frase me lleva dando vueltas desde entonces. Porque no es un problema de ese equipo. Es un cambio de dinámica que creo que va a redefinir cómo trabajamos los próximos años.

El embudo que conocíamos

Si has trabajado en producto digital, conoces esta imagen. Producto es un embudo ancho: muchas ideas, muchas iniciativas, mucha ambición. Ingeniería es el lado estrecho: capacidad finita, sprints limitados, equipos que no dan abasto.

Este desequilibrio ha definido cómo gestionamos equipos durante la última década. Priorizamos con RICE o ICE porque no podemos construir todo. Hacemos roadmaps trimestrales porque hay que decidir qué entra y qué no. La frustración habitual de cualquier Product Manager es esa: "tengo veinte ideas buenas y solo puedo ejecutar tres".

Pero ese modelo tenía una ventaja que no apreciábamos. Si solo puedes construir tres cosas, más te vale elegir bien. El cuello de botella en ingeniería era, sin quererlo, un mecanismo de calidad en las decisiones de producto. Te obligaba a pensar.

Un cambio que no hemos decidido

Claude Code, Copilot, Cursor, agentes que generan PRs completas. No voy a entrar en si la IA va a reemplazar a los desarrolladores (ya he escrito sobre eso). Lo que sí observo, en mi día a día apoyando a siete equipos, es algo más sutil: la capacidad de implementar está creciendo. No para todo, no infinitamente. Pero lo suficiente como para que la dinámica entre producto e ingeniería esté cambiando.

Y este es un cambio que no hemos decidido. No ha venido de una reorganización ni de una nueva metodología. Ha venido de las herramientas. De un día para otro, equipos que tardaban dos semanas en un flujo completo lo tienen en días. Y eso desplaza el cuello de botella: ya no está en cuántas cosas puedes construir, sino en cuántas cosas buenas puedes pensar, validar y definir a tiempo.

Esto no es un problema de nadie en particular. Es un desajuste nuevo entre dos capacidades que hasta ahora estaban razonablemente equilibradas. Y creo que toda la industria se va a encontrar con él.

Las dos respuestas obvias (y por qué ninguna me convence)

Cuando ves que el embudo se ha invertido, hay dos reacciones naturales. Llevo semanas dándole vueltas a ambas y te digo la verdad: ninguna me convence del todo.

Frenar ingeniería para igualar

La primera es ajustar hacia abajo. No construir más rápido solo porque puedes. Mantener el ritmo, usar la capacidad sobrante para refactoring, para slack, para calidad.

Tiene sentido. De hecho, los equipos de élite siempre han operado por debajo del 100% de capacidad. Toyota lo hace deliberadamente: no maximizar la utilización de máquina para maximizar el flujo. El slack no es desperdicio, es lo que permite absorber variabilidad.

Cuando vi lo que pasó con mi equipo, mi primer instinto fue exactamente este. Capacidad sobrante, pendientes de calidad, pues vamos a mejorar cobertura de tests en zonas que lo necesitaban. Y fue útil. No es tiempo perdido.

Pero hay algo que me reconcomía. Teníamos capacidad para construir algo que aportara valor a usuarios, y la redirigimos a mejoras internas. No digo que esté mal, a veces es la mejor decisión. Pero hay un coste de oportunidad real. Si esa capacidad existe y no la aprovechas, alguien en tu mercado sí lo hará.

Y alguien dirá: "bueno, es mejor ir despacio y bien que rápido y mal". De acuerdo. Pero eso no es lo que estoy planteando. Estoy planteando qué haces con la capacidad que has ganado. Desperdiciarla no es la única alternativa a desbocarse.

Acelerar producto para igualar

La segunda reacción es expandir hacia arriba. Si ingeniería puede construir más, generemos más ideas, más iniciativas, más producto. Que la cola no se vacíe.

Esta es la que me preocupa más. Porque es la que ocurre de forma natural, sin que nadie la decida.

He visto este patrón en la industria (y a veces en mí mismo, siendo honesto): ves que el equipo va más rápido con las nuevas herramientas y piensas "genial, podemos meter más iniciativas en el trimestre". Se pasa de tres a seis. ¿Y qué ocurre? A final de trimestre tienes seis cosas al 70% y ninguna al 100%. Ninguna medida, ninguna validada, ninguna con datos de uso reales.

Aquí el símil de la startup que escala demasiado rápido me parece preciso. Una startup levanta una ronda, contrata 50 personas en tres meses. La cultura se degrada, la comunicación se rompe, los nuevos no entienden los porqués.

Con la segunda opción pasa lo mismo, pero con iniciativas en vez de con personas. Metes muchas de golpe, el WIP se dispara, el foco se pierde. Y lo más peligroso: la calidad de las decisiones cae sin que nadie se dé cuenta, porque el volumen de output enmascara la caída de outcome.

Lo que nadie mide: el WIP de producto

Hay un concepto de teoría de colas que creo que es clave aquí: la Ley de Little.

Si aumentas el throughput de implementación pero no aumentas la capacidad de validación, lo que sube no es el valor entregado. Lo que sube es el WIP. Más cosas en progreso. Más cosas a medio pensar. Más cosas que "están hechas" pero nadie ha comprobado si resuelven algo.

El WIP alto tiene un coste brutal que seguro que reconoces: cada nueva iniciativa compite con las demás por atención, por feedback de usuario, por datos. Y como la capacidad de validar no es infinita, lo que acaba pasando es que todas reciben un poco y ninguna recibe lo suficiente.

Un patrón que he visto demasiadas veces: equipo que construye feature, la lanza, y pasa a la siguiente sin mirar métricas. ¿Por qué? Porque ya hay otra cosa esperando en la cola. La presión de throughput mata el aprendizaje.

La opción que no estaba en mi pizarra

Te digo la verdad: cuando dibujé esto en una pizarra solo tenía las dos opciones anteriores. Frenar o acelerar. Y las dos me chirriaban.

La tercera surgió en una conversación con un colega. No iguala los embudos. Los transforma.

La idea es esta: en vez de frenar ingeniería o acelerar producto, redirigir la capacidad sobrante de implementación hacia validación. Usar la capacidad extra no para construir más producto terminado, sino para construir más experimentos. Prototipos desechables. MVPs mínimos. A/B tests. Pruebas de concepto que responden preguntas antes de comprometer un desarrollo completo.

Lo que antes era "tenemos 20 ideas y solo podemos construir 3" se convierte en "tenemos 20 ideas, hemos prototipado 10, hemos descartado 6, y ahora construimos las 4 que sabemos que funcionan".

Eso convierte el cuello de botella de validación en algo que ingeniería puede ayudar a resolver. No generas más ideas. Filtras mejor las que tienes. Y lo haces con lo que sabes hacer: construyendo.

No voy a fingir que esto es una fórmula cerrada. Tiene sus propias preguntas abiertas. ¿Quién decide qué se prototipa y qué no? ¿Cómo evitas que un prototipo se convierta en producto sin pasar por validación real? ¿Cómo mides si un experimento ha respondido la pregunta o ha generado tres más? No lo tengo resuelto. Pero me parece una dirección con más futuro que las otras dos.

La pregunta que importa ahora

El cambio que estoy describiendo no es técnico. Es de mentalidad.

Durante años nos hemos preguntado "¿cómo producimos más?". Más features, más releases, más output. La pregunta ahora es diferente: ¿cómo aprendemos más rápido?

Porque si la implementación ya no es el cuello de botella, lo que separa a los equipos que generan valor de los que solo generan output es la velocidad a la que validan. A la que descartan lo que no funciona y doblan apuesta en lo que sí.

Cuando escuché ese "¿y ahora qué hacemos?", la respuesta que me habría gustado tener preparada no era "mete más features" ni "haz refactoring mientras tanto". Era "ayudadme a responder si lo siguiente que vamos a construir merece ser construido". Que ingeniería ayude a producto a pensar. No a ejecutar más rápido, sino a equivocarse más barato.

No sé si esta es la respuesta definitiva. Probablemente no. Pero sé que seguir con el modelo mental de "ideas sobran, manos faltan" ya no funciona. Las manos ya no faltan. Lo que falta es saber qué hacer con ellas.

Me encantaría saber cómo estáis viviendo esto en vuestros equipos. ¿Os ha pasado algo parecido? ¿Habéis encontrado formas de resolverlo?