Cuando un equipo de producto se reúne alrededor del Opportunity Solution Tree (Continuous Discovery Habits 2021) suele haber un momento incómodo. Alguien ha mapeado oportunidades, alguien ha propuesto soluciones, y el árbol empieza a tomar forma. Todo parece razonable. Todo parece conectado.

Pero debajo de cada rama hay una capa invisible: los supuestos. Las cosas que el equipo da por sentadas sin haberlas verificado: los usuarios experimentan de la forma en que el equipo cree, la solución propuesta resuelve algo que la gente realmente quiere resolver, están dispuestos a cambiar su comportamiento para usarla...

Torres llama a esto el trabajo de los assumption tests: antes de construir una solución completa, identificar los supuestos que la sostienen y buscar la forma más rápida y barata de saber si son válidos. Parece razonable. Y, sin embargo, la mayoría de los equipos no lo hacen o lo hacen mal.

¿Por qué? Porque identificar supuestos requiere cierta dosis de honestidad intelectual que va en contra de dos fuerzas muy humanas: el entusiasmo por una idea y la presión organizacional por entregar. Cuando estás convencido de que algo va a funcionar, detenerte a preguntarte "¿qué tendría que ser verdad para que esto funcione?" no resulta natural. Resulta incómodo.

Qué es exactamente un supuesto oculto

Un supuesto es cualquier afirmación implícita que subyace a una decisión. En product management, los supuestos suelen agruparse en torno a cuatro dimensiones bajo el acrónimo DUDE (David Bland y Alex Osterwalder, 2020):

• Desirability (¿alguien lo quiere?).
• Usability (¿puede usarlo?).
• Feasibility (¿podemos construirlo?).
• Viability (¿tiene sentido para el negocio?).

Pero no todos los supuestos son igual de visibles. Algunos son explícitos ("creemos que los usuarios prefieren pagar mensualmente a anualmente.") y fácil de identificar, fácil de formular como hipótesis. Pero otros son tan estructurales que el equipo ni siquiera los ve como supuestos: "los usuarios leerán las instrucciones antes de usar la funcionalidad." O peor: "el problema que estamos resolviendo es el problema real."

Este último nivel —los supuestos sobre el problema en sí— es el más peligroso y el más frecuentemente ignorado. Es la diferencia entre equipos que hacen output y equipos que persiguen outcomes: los primeros asumen que el problema está bien definido y se concentran en la solución; los segundos cuestionan periódicamente si están atacando el problema correcto (Marty Cagan, 2018).

Teresa Torres va un paso más allá con su concepto de continuous discovery: el problema nunca está completamente definido. La comprensión del problema evoluciona a medida que aprendemos de los usuarios. Por eso, los supuestos sobre el problema no son algo que se valida una vez al principio, sino algo que se revisa con regularidad a lo largo del ciclo de vida del producto.

Opportunity Solution Tree como mapa de suposiciones

Si trabajamos con el OST (árbol de oportunidad) de Torres, tenemos una estructura que puede ayudarnos a organizar los supuestos de forma sistemática. Cada nodo del árbol lleva implícitos supuestos propios.

• En el nodo de oportunidad (la necesidad, el dolor, el deseo del usuario) hay supuestos sobre si esa oportunidad existe, sobre cuán frecuente o intensa es, sobre si el segmento que la experimenta es suficientemente relevante para el negocio. Una oportunidad mal definida (o asumida sin suficiente evidencia) contamina todo lo que viene después.
• En el nodo de solución los supuestos se multiplican. ¿Creemos que esta solución aborda la oportunidad? ¿Qué comportamiento esperamos que provoque? ¿Qué contexto damos por sentado? ¿Qué sabemos sobre cómo los usuarios actuales resuelven ese problema sin nuestra solución?
• Y en los experimentos, que son la respuesta del OST a esas preguntas, hay también supuestos metodológicos: el experimento mide lo que queremos medir, el segmento reclutado es representativo, la señal que obtenemos es lo suficientemente fuerte para tomar una decisión...

Usar el OST no elimina los supuestos. Les da una ubicación: algo que se puede localizar se puede cuestionar.

Cómo afloran los supuestos ocultos

No hay un único método para sacar a la superficie lo que el equipo da por sentado. Pero hay algunas prácticas que, usadas con regularidad, ayudan.

La pregunta "¿qué tendría que ser verdad?"

Es quizás la más poderosa y la más subestimada. Ante cualquier solución propuesta, el equipo se pregunta: ¿qué tendría que ser verdad sobre el usuario, el mercado, la tecnología y el negocio para que esto funcione? Cada respuesta es un supuesto. La técnica viene del campo de la estrategia y Torres la adapta directamente al contexto del discovery de producto.

El pre-mortem

Es otra herramienta clásica con renovado protagonismo en entornos ágiles. Gary Klein describió este ejercicio en Sources of Power (1998): imaginar que el proyecto ha fracasado y trabajar hacia atrás para identificar qué pudo haber salido mal. En el contexto de product discovery, obliga a nombrar los miedos y las dudas que suelen quedar en el subconsciente colectivo del equipo. "Si esto fracasa, probablemente sea porque asumimos que los usuarios cambiarían su hábito actual, y en realidad no tienen motivación suficiente para hacerlo."

El mapeo explícito de supuestos como actividad de equipo

Habitualmente se usa en un taller corto antes de priorizar experimentos. Consiste en escribir todos los supuestos que el equipo identifica sobre una solución, sin juzgarlos. La regla es simple: si alguien del equipo lo da por sentado, se escribe. Luego viene la priorización.

Journey map

Puede ser útil como herramienta para revelar supuestos sobre el comportamiento. Cuando el equipo mapea el viaje del usuario paso a paso, emergen las asunciones implícitas sobre qué hace la persona antes de llegar a nuestra solución, durante el uso y después. Esas transiciones invisibles son terreno fértil para supuestos peligrosos.

Priorizar: no todos los supuestos merecen el mismo tratamiento

Una vez que los supuestos están sobre la mesa, el siguiente paso es priorizarlos. No porque los demás no importen, sino porque los recursos —tiempo, energía, dinero— son siempre limitados.

La matriz más utilizada en este contexto cruza dos dimensiones: importancia (¿cuánto depende el éxito de la idea de que este supuesto sea correcto?) e incertidumbre (¿cuánto sabemos ya sobre si es válido o no?).

• Los supuestos que son críticos para el éxito de la idea y sobre los que tenemos poca evidencia son los que hay que testear primero.
• Los que son críticos pero sobre los que ya tenemos evidencia sólida pueden tratarse como premisas (aunque revisables).
• Los de baja importancia, independientemente de su incertidumbre, pueden dejarse para más adelante o simplemente aceptarse.

Bland y Osterwalder llaman a esto la "zona de alto riesgo": los supuestos críticos e inciertos son los que pueden hundir la idea. Testarlos primero reduce el riesgo de invertir en construir algo que el mercado no validará.

Sin embargo, hay una trampa aquí que conviene nombrar: los equipos tienden a priorizar los supuestos que pueden testear fácilmente, no los que deberían testear primero. El sesgo de disponibilidad nos lleva a sobrevalorar lo que está al alcance y a evitar lo que resulta difícil o incómodo (Kahneman 2011). Testear si la solución es usable es más sencillo que testear si el problema que creemos haber identificado es realmente el problema. Pero el segundo supuesto suele ser más crítico.

Testear supuestos: del experimento a la evidencia

Testear un supuesto no es sinónimo de hacer una encuesta o lanzar un prototipo. Es encontrar la forma más rápida y barata de obtener evidencia suficiente para tomar una decisión sobre si continuar, pivotar o abandonar una línea de trabajo.

Torres distingue entre dos tipos de experimentos en función de la naturaleza del supuesto:

1. Los experimentos de actitud miden lo que la gente dice (entrevistas, encuestas, prototipos evaluados verbalmente).
2. Los de comportamiento miden lo que la gente hace (pruebas A/B, smoke tests, experimentos de demanda falsa, análisis de datos de uso). Este suele ser más costoso de ejecutar pero proporciona señales más fiables, porque la distancia entre lo que alguien dice que haría y lo que realmente hace puede ser enorme.

Esta distinción no es trivial. Cuando un equipo muestra un prototipo de alta fidelidad y los usuarios dicen "me parece muy interesante", el equipo tiende a interpretar eso como validación. Pero la pregunta relevante no es si el usuario encuentra interesante la idea, sino si estaría dispuesto a cambiar su comportamiento actual para adoptarla. Son preguntas muy diferentes.

Jeff Gothelf y Josh Seiden (2021) proponen una estructura de hipótesis que ayuda a mantener el foco:

"Creemos que [output] para [usuario] resultará en [outcome]. Sabremos que hemos tenido éxito cuando observemos [señal medible]."

Esta formulación obliga a conectar el experimento con la evidencia que se buscará, evitando el error frecuente de testear sin saber exactamente qué señal sería suficiente para tomar una decisión.

Un ejemplo concreto: supongamos que el equipo cree que los usuarios de una app de gestión de tareas necesitan una funcionalidad de recordatorios automáticos. El supuesto oculto es que los usuarios no crean recordatorios manualmente porque es demasiado tedioso, no porque no les interesen los recordatorios.

• Un experimento de actitud ("¿usarías recordatorios automáticos?") probablemente obtendrá un "sí" masivo.
• Un experimento de comportamiento (ofrecer la funcionalidad a un subconjunto de usuarios y medir cuántos la activan y con qué frecuencia la usan) dará información mucho más valiosa sobre la demanda real.

El riesgo organizacional: cuando el contexto dificulta el trabajo de supuestos

El trabajo de identificar y testear supuestos no ocurre en el vacío. Ocurre en organizaciones con plazos, con presupuestos, con jerarquías, y con culturas que no siempre premian la duda y el cuestionamiento.

En muchos contextos, reconocer que una idea tiene supuestos sin validar puede interpretarse como falta de confianza o como un obstáculo al avance. "Ya tenemos suficiente con lo que sabemos, necesitamos avanzar." Esta presión no es irracional desde el punto de vista de quien la ejerce: hay incertidumbre irreducible en cualquier decisión de producto, y en algún momento hay que actuar. El problema es cuando esa presión lleva a saltarse supuestos críticos porque resultan incómodos o porque testearlos requeriría ralentizar la producción.

Amy Edmondson (2018) documenta extensamente cómo la seguridad psicológica afecta directamente a la capacidad de los equipos para aprender. Un equipo que no se siente seguro para decir "creo que estamos asumiendo cosas que no hemos verificado" difícilmente realizará un trabajo serio de mapeo de supuestos. El método importa, pero el ambiente en el que se aplica importa igual o más.

Esto conecta con el hecho de que no todas las organizaciones están en condiciones de hacer discovery de calidad, no porque les falte el método, sino porque no han creado las condiciones para que el cuestionamiento sea bienvenido. El diagnóstico de madurez —que herramientas como AgiLevel pueden ayudar a hacer de forma más estructurada— puede ser el primer paso para entender qué está faltando antes del método.

La cadencia: supuestos como práctica continua, no como fase

Uno de los errores más comunes cuando los equipos descubren el trabajo de supuestos es tratarlo como una fase. Esta lógica es comprensible, pero contradice el principio central del discovery continuo que Torres propone.

Los supuestos cambian. El mercado cambia. Lo que los usuarios necesitan el primer mes puede no ser lo mismo que necesitan seis meses después. Y las soluciones, a medida que se desarrollan, generan nuevos supuestos que no existían al principio.

La propuesta de Torres de mantener entrevistas semanales con usuarios no es arbitraria: es la mecánica que permite al equipo actualizar continuamente su comprensión del espacio del problema y, por tanto, sus supuestos. Sin esa cadencia, el conocimiento se vuelve obsoleto y los supuestos se fosilizan.

Integrar el trabajo de supuestos en la rutina del equipo (en las sesiones de refinamiento, en los reviews, en las retrospectivas orientadas a aprendizaje) es más efectivo que tratarlo como un taller especial que se hace cada vez que empieza algo nuevo.

Identificar, priorizar y testear supuestos no es un proceso limpio. Requiere honestidad sobre lo que no sabemos, disposición para hacer preguntas incómodas, y un entorno organizacional que haga posible ese trabajo sin que el equipo tenga que pagar un coste político por hacerlo.

La buena noticia es que, con práctica, se vuelve más natural. Los equipos que habitúan el cuestionamiento de supuestos toman mejores decisiones y, sobre todo, aprenden más rápido de sus errores. No porque cometan menos, sino porque los cometen antes y con menos coste.

La pregunta que nos gustaría dejar abierta es esta: en tu equipo o en los equipos con los que trabajas, ¿cuánto del trabajo de discovery se destina a validar ideas que ya se daban por buenas, y cuánto a cuestionar genuinamente si las oportunidades que se persiguen son las correctas?

Si tienes experiencia con el Opportunity Solution Tree u otras formas de hacer visibles los supuestos en tu equipo, nos encantaría que lo compartieras.

Si quieres profundizar en el enfoque de Torres desde los fundamentos, puedes empezar por los apuntes sobre Continuous Discovery Habits disponibles en Open Knowledge.

Bibliografía

Bland, D. J. y Osterwalder, A. (2020). Testing Business Ideas: A Field Guide for Rapid Experimentation. Wiley.

Cagan, M. (2018). Inspired: How to Create Tech Products Customers Love (2ª ed.). Wiley.

Edmondson, A. C. (2018). The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth. Wiley.

Gothelf, J. y Seiden, J. (2021). Lean UX: Creating Great Products with Agile Teams (3ª ed.). O'Reilly Media.

Kahneman, D. (2011). Thinking, Fast and Slow. Farrar, Straus and Giroux.

Klein, G. (1998). Sources of Power: How People Make Decisions. MIT Press.

Martin, R. y Lafley, A. G. (2013). Playing to Win: How Strategy Really Works. Harvard Business Review Press.

Perri, M. (2019). Escaping the Build Trap: How Effective Product Management Creates Real Value. O'Reilly Media. ISBN: 978-1491973790

Seiden, J. (2019). Outcomes Over Output: Why Customer Behavior Is the Key Metric for Business Success. Sense and Respond Press.

Torres, T. (2021). Continuous Discovery Habits: Discover Products That Create Customer Value and Business Value. Product Talk LLC.