Construir ya no es el cuello de botella

Hace no mucho, lo más difícil de un producto digital era conseguir que existiera. Hacían falta meses, un equipo grande y mucho dinero antes de poder enseñar una idea a alguien.

Eso ha cambiado. Hoy puedo describir lo que imagino, probar varias pantallas y tener algo funcionando en unos días. Es una ventaja enorme, y yo la uso a diario.

Pero que algo funcione no significa que alguien lo necesite. Solo demuestra que sabíamos construirlo.

Cuando hacer software cuesta poco, lo que cuesta de verdad es decidir qué merece hacerse.

Una demo bonita responde a una sola pregunta

Imagina una herramienta que escucha las reuniones con clientes, apunta los acuerdos y reparte las tareas. En una demostración impresiona: reconoce las voces, resume bien y manda cada tarea a quien toca.

Ya sabemos una cosa: se puede hacer.

Lo que no sabemos es si los acuerdos se pierden de verdad, si perderlos duele, si alguien leerá el resumen o si alguien pagaría por evitar ese trabajo. Podríamos haber resuelto con mucho acierto algo que nadie quería delegar.

Hay una trampa muy humana en todo esto: una pantalla nueva da sensación de avance inmediata. Una conversación que contradice nuestra idea se siente peor, aunque nos ahorre meses.

Hacer más no es avanzar más

La IA no hace desaparecer el trabajo difícil. Hay que revisar lo que genera, encajarlo con el resto y responder de que funcione. El estudio DORA de 2025, con casi cinco mil profesionales, la describe como un amplificador: potencia lo que un equipo ya hace bien y también sus problemas.¹ Y en la encuesta de Stack Overflow del mismo año, dos de cada tres personas señalaban como frustración las respuestas de IA que estaban casi bien, pero no del todo.²

Además aparece un riesgo nuevo. Como probar algo cuesta tan poco, es fácil acumular versiones sin haber entendido cuál merece seguir. Diez versiones que responden a la misma suposición no son diez respuestas: son diez formas de seguir sin saber.

Mi primera pregunta: ¿qué quiero saber?

Antes de construir nada me hago una pregunta sencilla: ¿qué es lo que más me preocupa que sea falso?

Casi siempre es una de estas dudas, y conviene saber cuál:

• si el problema ocurre de verdad y a alguien le importa;
• si la persona a la que ayudo existe y puedo llegar hasta ella;
• si lo que propongo se entiende y se prefiere a lo que hace hoy;
• si lo va a usar de verdad, una semana tras otra;
• si puedo sostenerlo, técnica y económicamente.

Cada versión pequeña solo puede aclarar una o dos. Una lista de espera con mucha gente demuestra interés, pero no que alguien vaya a cambiar su forma de trabajar. Un piloto que le encanta a quien coordina el proyecto no demuestra que quien tiene el presupuesto vaya a pagar.

El error no es empezar con una señal pequeña. Es pedirle que responda algo para lo que no sirve.

Decidir antes de mirar el resultado

Hay un paso que casi siempre me ahorra tiempo: antes de hacer una prueba, escribo qué haré según cómo salga.

Si sale como espero, ¿qué me atreveré a hacer? Si no, ¿qué cambiaré o dejaré de hacer?

Si todos los resultados me llevan a construir lo mismo, no estoy haciendo una prueba; estoy buscando una excusa. Y si decido el criterio después de ver los datos, casi siempre me convenzo de que salió bien.

Es la idea de la prueba de carga: no hace falta construir el puente entero para saber si aguantará. Basta con probar una tabla con un límite que has fijado antes de poner las pesas. Con 100 kg pasa; con 120, no. Nadie discute después el resultado.

Lo que alguien hace pesa más que lo que dice

No todas las señales valen lo mismo. Que alguien opine que tu idea es buena ayuda a entender cómo piensa. Que cuente cómo resolvió el problema la última vez, con fechas y consecuencias, ayuda más. Que dedique una tarde a probarla, o que presente la prueba a su equipo, ayuda todavía más. Y que pague o firme un piloto es la señal más fuerte de todas.

Por eso prefiero preguntar por hechos que por intenciones. «Cuéntame la última vez que se perdió un acuerdo» enseña mucho más que «¿usarías una herramienta que organice tus reuniones?». Y observar a alguien trabajando suele aclarar más que cualquier encuesta.³

Tampoco hay que obsesionarse con la escala. Diez clics de las personas equivocadas valen menos que una conversación que descubre quién toma de verdad la decisión.

La prueba más pequeña que sirva

No todas las dudas necesitan software. Si dudo del problema, empiezo hablando con personas y mirando cómo trabajan hoy. Si dudo de la propuesta, enseño un prototipo o entrego el resultado hecho a mano. Si dudo de que se vaya a usar, hago un piloto pequeño en una rutina real. Y si dudo del negocio, hago una oferta concreta, con precio y condiciones.

Volvamos a la herramienta de reuniones. En vez de construir grabación, voces, resúmenes e integraciones, puedo avanzar así:

Primero, pedir a varios equipos que reconstruyan reuniones recientes: qué se acordó, qué se perdió y qué costó. Si no aparece ninguna pérdida frecuente, la transcripción deja de importar. Quizá el problema real sea decidir durante la reunión, no recordar después.

Después, preparar yo mismo el resumen y entregarlo como lo haría el producto. Veo qué corrigen, qué comparten y qué ignoran. Si nadie usa las tareas automáticas, me he ahorrado construirlas.

Más tarde, dejar que un equipo lo use durante unas semanas en reuniones reales. Ahí aparece lo que una demo no enseña: permisos, confianza, reuniones que no deberían grabarse y trabajo extra que yo mismo estaba creando.

Y por último, hacer una oferta de verdad. «Me interesa» y «lo compro» no son la misma señal.

No hace falta que todo salga bien. Si el resumen se comparte pero nadie quiere grabar, cambio la forma de entrada. Si se usa pero nadie pone presupuesto, quizá sea una función de otra herramienta y no un producto. El objetivo no es aprobar cuatro exámenes, sino saber qué decidir después.

Medir menos, decidir mejor

Una primera versión puede registrar visitas, clics y decenas de eventos. Que podamos medirlos no significa que sirvan.

Para cada dato me pregunto: ¿qué decisión cambiaría? Si quiero saber si el resumen entra en el trabajo del equipo, me importa más cuántas veces lo comparten que cuánto tiempo estuvo abierta la página. Y para saber si hay hábito, una segunda semana de uso dice más que un pico el día del lanzamiento.

Los números cuentan qué pasó; hablar con la persona cuenta por qué. Y medir menos tiene otra ventaja: hay menos información que proteger.

Aprender rápido no es entregar algo descuidado

En el artículo anterior defendía que mínimo no significa incompleto. Aquí encaja con una idea muy práctica.

Una entrevista no tiene por qué parecer un producto, y un prototipo puede simular partes. Pero cuando la prueba depende del uso real, los fallos básicos estropean lo que aprendemos. Si alguien no vuelve porque perdió su trabajo, no hemos aprendido que la idea no vale. Si no puede entrar por un problema de accesibilidad, no hemos probado su necesidad.

Cada prueba necesita el cuidado suficiente para que su resultado se pueda creer y su riesgo sea responsable. No más. Tampoco menos.

Construir sigue siendo una gran ventaja

No propongo usar menos la IA. Me permite explorar, comparar y convertir una decisión en software a una velocidad que hace poco no existía, y sería absurdo renunciar a eso.

Lo que propongo es no gastar esa velocidad en responder preguntas que nadie ha hecho. Y Combinator resume el consejo en lanzar pronto y aprender de quienes usan el producto.⁴ La parte fácil de repetir es «lanzar pronto». La importante es que lo que lanzamos nos acerque al problema y cambie lo que hacemos después.

Así que, antes de añadir la próxima función, me hago una pregunta:

¿Qué incertidumbre estoy pagando por reducir con esta versión?

Si no sé responder, construir más rápido solo me llevará antes al mismo sitio. Si sé, la velocidad deja de ser una promesa y se convierte en una ventaja.