Opportunity Solution Tree

El árbol se lee de arriba abajo en cuatro capas. En la raíz hay un único outcome deseado — un objetivo medible que el equipo persigue, como elevar la activación o reducir el tiempo hasta el valor. Debajo se ramifican las oportunidades: necesidades, dolores y deseos del cliente expresados en sus propios términos, sacados a la luz mediante la discovery continua. Bajo cada oportunidad hay soluciones candidatas, y bajo cada solución están las pruebas de hipótesis o experimentos que comprueban si la solución realmente moverá la oportunidad.

La estructura es deliberadamente un árbol, no una lista. Un único outcome se ramifica en muchas oportunidades, cada oportunidad en varias soluciones, cada solución en múltiples pruebas. Esta ramificación obliga a un equipo a mantener más de una opción en cada nivel, lo cual es el antídoto contra comprometerse con la primera idea que suena plausible.

La función del árbol es hacer visibles y cuestionables las decisiones de discovery. Como toda solución se remonta a una oportunidad y toda oportunidad al outcome, cualquiera puede preguntar «¿a qué necesidad del cliente sirve esto, y qué objetivo mueve esa necesidad?». Una funcionalidad que no puede responder a esas preguntas queda expuesta como trabajo huérfano antes de consumir un sprint.

También replantea la priorización. En lugar de clasificar un backlog plano de funcionalidades, el equipo primero compara oportunidades frente al outcome — evaluando qué necesidad, de resolverse, movería más el objetivo — y solo entonces explora soluciones dentro de la rama elegida. Torres llama a esto «comparar oportunidades, no soluciones», y eso mantiene honestos a marcos de puntuación como RICE, al asegurar que los elementos evaluados sean necesidades genuinas del cliente y no funcionalidades precocinadas.

El fallo más común es escribir soluciones disfrazadas de oportunidades. «Añadir una integración con Slack» es una solución; la oportunidad real es «pierdo el rastro de las menciones porque viven en otra herramienta». Cuando la capa de oportunidades está llena de funcionalidades, el árbol colapsa en un backlog y su poder comparativo desaparece. Las oportunidades deben formularse como necesidades del cliente, en el lenguaje del cliente, distintas de cualquier solución concreta.

Un segundo fallo es tratar el árbol como un artefacto de una sola vez. Debe evolucionar cada semana a medida que llega nueva evidencia de entrevistas — se añaden ramas, se podan y se repesan. Un árbol que no ha cambiado en un mes suele ser señal de que la discovery se ha detenido en silencio. Una tercera trampa es saltarse por completo la capa de experimentos y lanzar la primera solución bajo una oportunidad, lo que descarta la generación de opciones que la estructura existe para imponer.

Un opportunity solution tree es tan confiable como la evidencia que hay bajo cada rama. En la práctica, esa evidencia — la nota de la entrevista, el ticket de soporte, la señal de uso, los ingresos detrás de la cuenta que la planteó — suele vivir en herramientas separadas, así que las oportunidades tienden a alejarse de necesidades reales y volver a ser suposiciones, y los outcomes pierden su vínculo con el comportamiento real de las cuentas.

Un sistema operativo de producto como AIOProductOS mantiene esa evidencia conectable en una columna vertebral compartida: su feed de Insights muestra el feedback junto al registro Customer-360 y a los ingresos detrás de él, de modo que una oportunidad puede mostrar qué cuentas de pago la plantearon antes de merecer una rama, y el outcome en la raíz puede seguirse frente a analítica de producto real en lugar de un número copiado en una diapositiva. El árbol sigue siendo una herramienta de discovery; la columna vertebral mantiene actualizada la evidencia que lo sostiene.