Por qué esta fase existe
Hay una escena que se repite en casi todas las organizaciones que hemos conocido. Alguien llega a una reunión con una idea. La idea suena bien. Alguien con autoridad dice que parece interesante. En cuestión de días, hay un equipo asignado, un backlog creado y un sprint planificado. Nadie se detuvo a preguntar si el problema que esa idea pretendía resolver existía realmente, o si existía de la forma en que se asumió.
Con la llegada de la IA generativa, esta dinámica se ha acelerado. Ahora puedes tener un prototipo funcional en horas. Un MVP en días. La tentación de saltar directamente a la construcción es más fuerte que nunca, porque el coste percibido de construir ha caído en picado. Pero el coste de construir lo incorrecto sigue siendo exactamente el mismo. O peor: ahora produces la solución equivocada más rápido, con mayor nivel de acabado, y por tanto con mayor dificultad para que alguien se atreva a cuestionar si realmente resuelve algo.
Problem Phase existe para interrumpir ese patrón. Es la fase en la que el equipo se obliga a entender el problema real antes de pensar en soluciones. No es una reunión de kickoff. No es un briefing. No es un formulario que alguien rellena para cumplir un trámite. Es una investigación activa, rigurosa y a menudo incómoda con las personas que viven el problema todos los días.
Su único objetivo es producir una definición del problema que sea precisa, compartida y validada. Nada más. Y nada menos.
El problema es sagrado. Nunca asumas que entiendes el problema. El problema real raramente es el problema que te presentan en la primera conversación. Tienes que ganártelo a través de escucha activa, observación y preguntas incómodas. Un problema mal entendido contamina todo lo que viene después, sin excepción.
Esta fase es la más contraintuitiva de toda la metodología. En un mundo que premia la velocidad, pedir al equipo que se detenga a pensar antes de actuar parece un lujo. No lo es. Es la inversión con mayor retorno de todo el proceso. Cada hora invertida en entender bien el problema ahorra semanas de construcción equivocada, ciclos de retrabajo, reuniones de realineación y, sobre todo, la erosión de confianza que se produce cuando un equipo entrega algo que nadie necesitaba.