La velocidad no arregla un mal discovery
Cuanto más barato es construir, más caro sale decidir mal qué construir. Una cosa es aprender rápido y otra muy distinta producir rápido.
Se oye bastante un argumento que suena razonable: como ahora podemos construir en horas lo que antes costaba semanas, ya no hace falta pensar tanto antes de empezar. Si nos equivocamos, lo tiramos y probamos otra cosa.
Tiene parte de razón, y esa parte me gusta. Pero mezcla dos velocidades que no son la misma: la velocidad a la que producimos y la velocidad a la que aprendemos. Una puede multiplicarse sin que la otra se mueva.
Lo que ha cambiado y lo que no
Hace unos años, equivocarse de dirección solía significar semanas de desarrollo. Ese coste era incómodo, pero obligaba a pararse a pensar. Hoy hay cosas que se pueden prototipar, e incluso implementar, en horas o en un par de días. Es una mejora enorme y no pienso discutirla.
Lo que no ha cambiado es lo que hay que saber antes de decidir qué merece ese esfuerzo: quién tiene el problema, cuánto le importa, qué hace hoy para resolverlo y por qué lo que vamos a construir sería mejor. Eso sigue saliendo de hablar con personas, de mirar cómo usan lo que ya existe y de entender el negocio en el que tiene que encajar la solución. Acelerar un mal discovery solo consigue que descubras antes, y con más cosas ya construidas, que el problema no era ese.
Cuando construir es barato, se construye por defecto
El riesgo no es técnico, es de incentivos. Si un prototipo cuesta una tarde, la pregunta de si deberíamos hacerlo empieza a parecer un trámite. “Podemos hacerlo rápido” siempre está disponible como respuesta y suena a productividad, pero contesta a otra pregunta.
Lo construido, además, tiene un coste que no aparece en ninguna estimación: hay que mantenerlo, explicarlo y decidir qué hacer con ello. Y un prototipo hecho en una tarde también genera apego. Un equipo con cinco ideas medio pensadas y funcionando tiene más ruido, no más claridad.
Velocidad de aprendizaje, no de producción
No estoy defendiendo meses de investigación antes de tocar nada. El discovery se puede hacer con muy pocos recursos y, ahora que prototipar es barato, puedes aprender haciendo cosas que antes exigían esperar al desarrollo: enseñar algo tangible a un usuario o a alguien de operaciones, ver dónde se atasca y descartar la mitad de las ideas sin escribir una línea de código de producción.
La diferencia está en para qué se construye. Un prototipo que responde a una pregunta concreta, como si entienden este flujo o si les importa lo bastante como para cambiar lo que hacen hoy, acelera el aprendizaje. Uno que se construye porque ya había una idea y era fácil llevarla un poco más lejos acelera la producción. Desde fuera se parecen mucho.
Dónde ayuda la IA y dónde no
Ayuda mucho en discovery: sintetizar transcripciones, buscar patrones en tickets o reseñas, preparar hipótesis para discutirlas, generar alternativas, montar algo que enseñar. Yo la uso a diario para parte de eso, aunque con reservas que también he contado.
Lo que no hace es sentarse con la persona que tiene el problema, conocer cómo funciona tu empresa por dentro ni decidir cuánta evidencia es suficiente para actuar. Puede resumir decenas de entrevistas, pero no sabe cuál de las cosas que se dijeron pesa más para tu negocio. Ese criterio se nota más cuando todo lo demás es rápido, porque queda menos tiempo por el camino para darse cuenta de que algo no cuadra.
La velocidad multiplica tanto las buenas decisiones como las malas. Antes de celebrar lo rápido que construimos, yo preguntaría qué hemos aprendido esta semana que no supiéramos la anterior.
Las opiniones expresadas son personales y no representan la posición de ninguna organización.