
Desde hace años he sido muy estricto con reducir al mínimo el alcance de las nuevas funcionalidades que hacemos. No por capricho, sino porque, en mi experiencia, cuando ampliamos demasiado el alcance desde el inicio, acabamos construyendo cosas que no son útiles para el usuario, o invirtiendo tiempo sobre una base de la que todavía no tenemos suficiente certidumbre. Además, el coste de oportunidad es enorme: por intentar cubrir muy bien una funcionalidad, dejamos de hacer lo importante de otras partes del negocio o del producto.
Cierto es, como me recordaba mi anterior equipo, que volver a una funcionalidad tras varios meses para iterarla implica cambio de contexto, reaprendizaje, retomar lógica de negocio y decisiones de diseño. Y si hay personas nuevas en el equipo, aún peor. Ese coste no es trivial. Y también es cierto que nuestros usuarios pueden sentir que, al ser tan lean en las primeras versiones, parece que todo está por hacer. Nunca hay una sensación de que algo está realmente terminado. Y es comprensible: cuando haces un alcance muy reducido en muchas áreas, es fácil que falten opciones para cubrir diferentes combinaciones de uso o flujos menos frecuentes.
En los últimos meses, tras vivir la velocidad de desarrollo con la IA, me estoy replanteando cuál es realmente el alcance mínimo. Hasta hace poco, dejar mejoras “para más adelante” tenía todo el sentido del mundo. Con IA, de repente es viable avanzar mucho más rápido. En una misma semana, puedes hacer un scope mayor que lo que antes hacías en varias.
Y ahí me surge la duda: ¿deberíamos mantener ese enfoque lean, cubriendo varios temas por semana con el mínimo necesario? ¿O deberíamos ampliar el alcance de cada funcionalidad, cuando el valor está claro, y así dejar las cosas más cerradas y maduras desde el principio?
Porque claro, si sabemos que algo es útil, que no hay incertidumbre sobre el valor ni sobre la dirección y es asumible un pocos días, ¿por qué no hacerlo ya y cerrar el capítulo? Pero también sé que si empezamos a aplicar eso con todo, corremos el riesgo de volver a sobreconstruir, como antes. Y entonces, ¿estamos ganando o estamos perdiendo con la IA?
No tengo una respuesta cerrada. ¿Qué estás viviendo vosotros? Sí tengo claro que la forma en que diseñamos, priorizamos y ejecutamos producto está cambiando rápido.
También puede interesarte

40 clics para pagar dos horas de aparcamiento
Un parquímetro me ha recordado por qué contar los clics y los segundos que le cuesta a tu usuario completar una tarea es clave al diseñar un producto.

5 comportamientos que definen a un Product Engineer
La IA hace que programar sea rápido. El reto que queda es entender el problema, plantear una buena arquitectura y fasear con criterio.
