¿Alguna vez has descubierto que estabas construyendo la solución correcta al problema equivocado?

El error más caro de producto no es técnico

En la cultura ágil hablamos mucho de eficiencia: entregar rápido, iterar, reducir el desperdicio. Pero la forma más costosa de desperdicio no es construir algo lentamente; es construir bien algo que no había que construir. Y eso ocurre cuando aceptamos un problema mal planteado.

Melissa Perri lo nombró con una expresión que se ha vuelto referencia: la build trap, la trampa de construir (Escaping the Build Trap, 2018). Las organizaciones caen en ella cuando miden su éxito por la cantidad de funcionalidades entregadas en lugar de por el valor generado. El equipo se convierte en una fábrica de outputs y pierde de vista los outcomes. La pregunta "¿estamos construyendo lo correcto?" se sustituye por "¿estamos construyendo rápido?".

El problema es que la trampa no se siente como una trampa. Desde dentro, todo parece ir bien: hay backlog, hay sprints, hay entregas. La maquinaria funciona. Solo que apunta al objetivo equivocado.

Por qué aceptamos problemas mal planteados

Si encuadrar mal un problema es tan costoso, ¿por qué lo hacemos tan a menudo? Thomas Wedell-Wedellsborg, en What's Your Problem? (2020), ofrece una explicación: tendemos a enamorarnos del primer enunciado del problema que recibimos y saltamos directamente a generar soluciones. Su ejemplo clásico es el del edificio con un ascensor lento. La definición obvia del problema —"el ascensor es lento"— lleva a soluciones costosas: motores nuevos, algoritmos de optimización. Pero reencuadrar el problema como "la espera es molesta" abre soluciones baratas y eficaces, como instalar espejos en el rellano. El problema no era la velocidad; era el aburrimiento de esperar.

Hay varias razones por las que aceptamos el primer encuadre sin cuestionarlo. La presión por avanzar penaliza la pausa reflexiva: dedicar tiempo a interrogar el problema parece "no estar produciendo". La jerarquía juega en contra: cuando el enunciado viene de arriba, cuestionarlo se siente como insubordinación. Y nuestra propia psicología nos traiciona: una vez que tenemos una solución en mente, reinterpretamos el problema para que encaje con ella, en lugar de al revés.

Don Norman, en The Design of Everyday Things (2013), recordaba que los diseñadores expertos resisten la tentación de resolver el problema que se les presenta y dedican esfuerzo deliberado a determinar cuál es el problema real. Esa resistencia —no aceptar el enunciado tal cual llega— es una de las competencias más subestimadas en producto.

Síntoma, problema y necesidad: tres cosas distintas

Buena parte de los problemas mal planteados nacen de confundir tres niveles que conviene separar.

El síntoma es lo que se observa: una métrica que cae, una queja recurrente, una funcionalidad poco usada. El problema es la interpretación de por qué ocurre el síntoma. La necesidad es lo que la persona realmente intenta lograr.

Cuando un stakeholder dice "necesitamos un botón de exportar a Excel", está mezclando los tres niveles en una sola frase que ya viene con la solución incorporada. El trabajo de producto consiste en desempaquetarla: ¿qué intenta hacer realmente quien pide esto? Quizá necesita compartir datos con alguien que no tiene acceso al sistema. Quizá necesita un informe que el producto no ofrece. El botón de exportar puede ser la peor solución a una necesidad que ni siquiera hemos entendido.

Aquí es donde el marco Jobs to Be Done resulta útil. La idea, popularizada por Clayton Christensen y desarrollada por Anthony Ulwick en Jobs to Be Done (2016), es que las personas "contratan" productos para hacer un trabajo en su vida. Si no entendemos el trabajo, optimizamos la herramienta equivocada. La famosa formulación de Christensen —la gente no quiere un taladro, quiere un agujero, y en realidad ni siquiera quiere el agujero, sino lo que el agujero le permite conseguir— captura exactamente este desplazamiento de foco.

Discovery continuo: cuestionar el problema antes de construir

La práctica que mejor protege contra resolver el problema equivocado es separar el descubrimiento de la entrega. Teresa Torres, en Continuous Discovery Habits (2021), propone que los equipos de producto sostengan un contacto regular con sus usuarios —idealmente semanal— para mantener viva la pregunta sobre qué problemas merecen ser resueltos.

Su herramienta central, el árbol de oportunidades y soluciones (opportunity solution tree), obliga a mapear las oportunidades —las necesidades y dolores reales detectados— antes de saltar a soluciones. Esto crea una disciplina: ninguna solución se justifica sola; cada una debe colgar de una oportunidad validada que, a su vez, conecta con un resultado de negocio deseado.

Marty Cagan, en Inspired (2017), distingue cuatro grandes riesgos que el discovery debe abordar antes de comprometer recursos de construcción: el riesgo de valor (¿lo querrán?), el de usabilidad (¿sabrán usarlo?), el de viabilidad (¿podemos construirlo?) y el de viabilidad de negocio (¿funciona para la organización?). Construir la solución correcta al problema equivocado suele ser un fallo del primer riesgo, el de valor, disfrazado de éxito de ejecución.

La inteligencia artificial ha abaratado construir y encarecido equivocarse de problema

Aquí aparece una tensión nueva y específica de nuestro momento. La IA generativa ha reducido drásticamente el coste de construir. Lo que antes requería semanas de desarrollo hoy puede prototiparse en horas. Y esto, que es una buena noticia para la velocidad, agrava un riesgo viejo.

Cuando construir era caro y lento, el coste mismo de la construcción imponía cierta cautela: nadie quería invertir tres meses sin estar razonablemente seguro. Ahora que construir es barato, esa fricción protectora desaparece. Es tentador saltar directamente a generar la solución porque cuesta tan poco que parece que no hay nada que perder.

Pero sí hay algo que perder. Cada solución construida —aunque sea barata— genera mantenimiento, complejidad, expectativas en los usuarios y deuda conceptual. Un producto lleno de funcionalidades que resuelven problemas equivocados no es gratis por haber sido barato de construir; es un producto confuso, difícil de mantener y desalineado. La IA reduce el coste de construir, pero no reduce —y quizá aumenta— el coste de construir lo incorrecto.

La conclusión es contraintuitiva: cuanto más barato resulta construir, más valioso se vuelve el discovery. El cuello de botella ya no es la capacidad de ejecución, sino la calidad del problema que elegimos resolver. En un mundo donde cualquiera puede generar una solución plausible en minutos, la ventaja competitiva se desplaza hacia quien sabe formular el problema correcto. Es exactamente el espacio donde herramientas como ScrumIA, que integran la IA en el flujo de trabajo ágil sin sustituir el criterio del equipo, pueden ayudar: acelerando la generación de hipótesis sin eximir de la responsabilidad de validarlas.

Señales de que podrías estar resolviendo el problema equivocado

Conviene tener algunos indicadores de alerta. No son pruebas concluyentes, pero invitan a detenerse.

Cuando nadie del equipo puede explicar con claridad qué cambiará en la vida del usuario si esto funciona, probablemente estás trabajando sobre una solución, no sobre un problema. Cuando el enunciado del problema ya contiene la solución ("necesitamos una app", "hay que migrar a microservicios"), alguien saltó un paso. Cuando la justificación de una iniciativa es "lo pidió un cliente importante" sin entender qué intentaba lograr ese cliente, hay riesgo de confundir la petición con la necesidad. Y cuando llevas semanas construyendo y todavía no has hablado con un solo usuario real, el riesgo es máximo.

Ninguna de estas señales obliga a parar. Pero todas invitan a hacer la pregunta que con tanta frecuencia omitimos: ¿estamos seguros de qué problema estamos resolviendo y por qué importa?

Reencuadrar no es analizar hasta la parálisis

Conviene un matiz honesto. Cuestionar el problema puede degenerar en su propia disfunción: el análisis interminable, el discovery que nunca termina, el equipo que reformula el problema una y otra vez sin construir nada. Esto también es desperdicio.

La cuestión no es elegir entre construir o cuestionar, sino integrar ambas cosas en un ritmo sostenible. El discovery continuo de Torres no es una fase previa infinita; es una práctica ligera y paralela a la entrega. Reencuadrar el problema no significa paralizarse ante la incertidumbre, sino reducir esa incertidumbre con el menor esfuerzo posible antes de comprometer recursos grandes. A veces la mejor forma de validar un encuadre es construir un experimento pequeño y barato, no debatir en abstracto.

El equilibrio está en hacer las preguntas correctas en el momento correcto, no en hacerlas todas, todo el tiempo.

Descubrir que construiste la solución correcta al problema equivocado es una de las experiencias más formativas en producto, precisamente porque no se siente como un error mientras ocurre. Todo parece ir bien hasta que el resultado revela que apuntábamos al sitio equivocado.

La buena noticia es que esta competencia —interrogar el problema antes de enamorarse de la solución— se puede cultivar. Requiere disciplina para resistir la presión de "ponerse a hacer", humildad para admitir que el primer encuadre puede estar mal, y contacto regular con la realidad de los usuarios. En un momento donde la IA hace trivial construir casi cualquier cosa, esta competencia deja de ser un lujo de equipos maduros para convertirse en la diferencia entre crear valor y acumular funcionalidades inútiles.