Enamórate del problema, no de la solución

Un prototipo puede estar listo antes de que consigas agendar la primera conversación con un cliente. Eso ayuda. También facilita pasar una semana construyendo algo que nadie pidió.

Lo peligroso es que la pantalla funciona. El formulario envía datos, el panel muestra cifras y la demostración convence. Cada detalle terminado aumenta las ganas de defender el producto. Todavía falta saber si merece existir.

Enamórate del problema, no de la solución, de Uri Levine, da nombre a esa disciplina. Mi lectura es práctica. Antes de elegir qué construir, averigua qué trabajo intenta terminar una persona y qué se lo impide.

Pide ver la última vez

"¿Usarías un sistema que organiza tus pedidos?" es una pregunta cómoda. La persona puede decir que sí sin cambiar nada de su vida.

Prefiero pedirle que muestre el último pedido que le dio problemas. ¿Qué mensaje llegó primero? ¿Dónde anotó el precio? ¿Cómo descubrió que faltaba información? ¿Cuánto esperó hasta poder continuar?

Imagina una distribuidora que recibe pedidos por WhatsApp y los copia a una hoja de cálculo. La primera idea sería crear un portal. Al observar el proceso, podrías descubrir que copiar los datos lleva poco tiempo. La espera está en la aprobación de descuentos, que depende de una sola persona.

En este ejemplo hipotético, un portal puede ordenar la entrada y dejar intacta la demora. La cola cambió de dirección.

Describe el problema sin nombrar una tecnología

Una descripción útil sería "la persona que gestiona el pedido espera una aprobación antes de confirmar la entrega". Permite investigar quién aprueba, cuándo lo hace y qué pedidos podrían avanzar solos.

"Necesitamos un agente de IA" ya eligió una respuesta. No explica por qué un pedido está detenido.

Antes de dibujar la interfaz, registra:

• Quién hace el trabajo y en qué situación.
• Qué usa hoy, incluidos mensajes y papel.
• Dónde pierde tiempo o repite una tarea.
• Qué cambio observable justificaría sustituir el proceso.

Busca ejemplos recientes. Una conversación sobre lo que pasó ayer suele aportar más que una predicción sobre lo que alguien haría el próximo año.

Prueba el cambio en el trabajo

Para la distribuidora, la primera prueba podría ser una regla de descuento para pedidos habituales. Durante un período acordado, alguien aplica la regla a mano y registra las excepciones. No hace falta desarrollar un sistema para averiguar si la aprobación causaba la espera principal.

Define antes qué vas a observar. Por ejemplo, reducir el tiempo entre recibir un pedido completo y confirmarlo, sin aumentar las correcciones posteriores. Es una medida propuesta para la prueba, no un resultado prometido.

Anota también qué invalidaría la idea. Si los pedidos siguen detenidos porque falta inventario, el diagnóstico estaba incompleto. Descubrirlo antes del desarrollo es un resultado útil.

Un prototipo tiene sentido cuando responde una duda concreta. ¿El equipo puede completar el pedido sin ayuda? ¿Quien aprueba entiende el contexto? Si la prueba termina con "quedó bonito", faltó una pregunta.

Separa interés de compromiso

Elogiar una demostración cuesta poco. Reservar tiempo para un piloto, aportar datos adecuados y cambiar una rutina cuesta más. Esos compromisos indican mejor la prioridad del problema.

Aceptar un piloto tampoco demuestra que exista mercado. Observa el uso después de la primera semana. Comprueba si la persona vuelve cuando dejas de recordárselo. Pregunta qué abandonaría para seguir usando el producto.

El problema también puede ser real y demasiado pequeño para sostener un negocio. Ahorrar unos minutos puede ayudar sin justificar una suscripción, una implementación y otra herramienta que administrar.

Decide qué te haría parar

Antes del siguiente ciclo de desarrollo, escribe una condición para continuar y otra para parar. Comparte ambas con quienes construyen el producto.

Ese acuerdo importa más cuando ya hay código funcionando. El tiempo invertido pesa en la conversación, pero no obliga a dedicar otra semana.

Antes de pedir una funcionalidad más, vuelve al último caso real. Averigua qué quedó detenido, quién tuvo que intervenir y si el cambio propuesto habría ayudado en ese momento. Usa esa información para decidir qué entra en el producto.