Antes de construir, haz una pregunta mejor.

Una petición de funcionalidad suele llegar con una solución incorporada: necesitamos un panel, una integración o un botón nuevo. Aceptarla sin más es tentador. Da sensación de avance y permite pasar directamente a la ejecución. Pero deja sin responder lo esencial: ¿qué intenta conseguir la persona que lo ha pedido?

Antes de abrir el backlog, merece la pena reconstruir la situación. Qué estaba haciendo esa persona, dónde se detuvo y cómo lo resuelve hoy. Una conversación sobre un caso concreto suele dar más información que una lista de preferencias. El objetivo no es discutir la petición, sino entender la necesidad que hay detrás.

Después conviene escribir el resultado esperado sin mencionar la solución. Por ejemplo, reducir el tiempo que tarda un equipo en detectar una incidencia. Esta formulación permite comparar opciones: quizá haga falta un panel, pero también podría bastar con una alerta o con una mejora en el proceso.

El siguiente paso es elegir la forma más pequeña de poner a prueba esa hipótesis. Una maqueta, una prueba manual o una conversación con datos reales pueden evitar semanas de desarrollo. Define por adelantado qué observarás y qué resultado te haría cambiar de opinión.

Construir sigue siendo importante. La diferencia está en hacerlo después de entender qué merece ser construido. Un buen producto no acumula respuestas: aprende a formular mejores preguntas.