Una decisión es una apuesta

Descripción

La lección 2 te dio la herramienta para separar hechos de suposiciones. Esta lección le da estructura a lo que encontraste: una apuesta de producto tiene una thesis —la afirmación central que el equipo cree que va a pasar si construye la apuesta ("mostrar recomendaciones personalizadas va a subir el GMV por comprador")— y esa tesis descansa sobre una pila de suposiciones (el assumption stack), cada una de las cuales podría estar equivocada. Cuantas más suposiciones sin probar sostienen la tesis, más grande es el salto de fe que el equipo está dando al construirla.

Esto no es un tecnicismo de vocabulario: cambia cómo se juzga si una decisión fue buena. La poker player y autora Annie Duke acuñó un término para el error más común al evaluar decisiones bajo incertidumbre: "resulting" — juzgar la calidad de una decisión por la calidad de su resultado, en vez de por la calidad del razonamiento que la sostuvo en el momento de tomarla. Una apuesta bien pensada puede fallar por mala suerte; una apuesta mal pensada puede salir bien por casualidad. Confundir las dos cosas —como vas a ver en el ejemplo de hoy— hace que los equipos aprendan la lección equivocada de sus propios resultados.

Conexión con el módulo. La lección 2 te enseñó a separar fact de assumption; esta lección organiza esas suposiciones alrededor de la tesis que sostienen, y te da el criterio para juzgar si una apuesta se tomó bien —sin esperar a saber si salió bien—. Las lecciones 4 y 5 toman exactamente esta misma pila de suposiciones y encuentran cuál, de todas, es la que más pesa.

Una analogía: la mano de póker que no depende de ganar

Annie Duke jugó póker profesional antes de escribir sobre decisiones. En el póker, cada apuesta se hace sin ver las cartas del rival: apuestas con la mejor lectura posible de la situación —tus cartas, las que ya se mostraron, cómo jugó el rival hasta ahora—, y aun con la mejor lectura posible, puedes perder la mano. El rival puede tener, contra toda probabilidad, exactamente la carta que necesitaba. Eso no vuelve mala tu decisión de apostar — tu decisión fue la correcta dado lo que sabías en ese momento; el resultado, esta vez, no coincidió con la probabilidad.

Y lo inverso también pasa todo el tiempo: alguien apuesta fuerte con una mano débil, sin ninguna razón sólida, y gana igual porque la carta que necesitaba salió por pura suerte. Ganó la mano. No tomó una buena decisión — tomó una decisión mala que tuvo un resultado bueno. Si ese jugador aprende de esa mano "apostar fuerte con manos débiles funciona", va a perder mucho más dinero en las próximas cien manos de lo que ganó en esa.

Construir una apuesta de producto es exactamente igual: apuestas con la mejor lectura posible —tus hechos, tus suposiciones, tu evidencia—, sin ver "las cartas del rival" (lo que de verdad va a hacer el mercado). Si recommendations sube el GMV, eso no prueba automáticamente que la apuesta se pensó bien — pudo subir por una temporada alta que coincidió por casualidad. Si recommendations no mueve el GMV, eso tampoco prueba que la apuesta se pensó mal — la tesis pudo ser razonable y fallar por un factor que nadie podía prever. Lo único que sí puedes evaluar, antes de saber el resultado, es si identificaste tu tesis con claridad y si probaste la suposición que más podía hundirla.

Ejemplo trabajado: dos apuestas, dos tamaños de salto de fe

No todas las apuestas del backlog de Mercado son iguales de inciertas. Compara fasterCheckout con recommendations: ambas son apuestas —ninguna es una certeza absoluta—, pero el tamaño de lo que están asumiendo es muy distinto.

// describeBet(bet): cuenta cuantas suposiciones sostienen la tesis de una apuesta,
// y cuantas de esas siguen sin probarse. No pondera nada todavia (eso es la leccion 5);
// solo hace visible el TAMANO del salto de fe detras de cada apuesta.
function describeBet(bet) {
  const untested = bet.assumptions.filter((a) => !a.tested).length;
  return {
    thesis: bet.thesis,
    totalAssumptions: bet.assumptions.length,
    untestedAssumptions: untested,
  };
}

const fasterCheckoutBet = {
  thesis: 'Reducir el checkout de 3 pasos a 1 va a subir la conversion',
  assumptions: [
    { text: 'Los usuarios abandonan principalmente por friccion, no por precio', tested: true },
    { text: 'Un checkout de 1 paso no aumenta errores de pago', tested: false },
  ],
};

const recommendationsBet = {
  thesis: 'Mostrar recomendaciones personalizadas va a subir el GMV por comprador',
  assumptions: [
    { text: 'Los usuarios van a comprar mas si ven recomendaciones personalizadas', tested: false },
    { text: 'El equipo puede construir un motor basico en 3 person-months', tested: false },
    { text: 'Los vendedores no se van a quejar de productos menos visibles', tested: false },
    { text: 'Mostrar recomendaciones no baja la velocidad de carga', tested: false },
  ],
};

console.log('=== Dos apuestas del backlog de Mercado, vistas como apuestas ===\n');
[fasterCheckoutBet, recommendationsBet].forEach((bet) => {
  const d = describeBet(bet);
  console.log('  "' + d.thesis + '"');
  console.log('  suposiciones: ' + d.totalAssumptions + '  |  sin probar: ' + d.untestedAssumptions + '\n');
});

console.log('fasterCheckout descansa en 2 suposiciones, 1 ya probada: un salto de fe chico.');
console.log('recommendations descansa en 4 suposiciones, las 4 sin probar: un salto de fe grande.');
console.log('Las dos son apuestas -- ninguna es una certeza -- pero no del mismo tamano.');

Qué esperar. Al correr el archivo con Node, la salida es exactamente esta:

=== Dos apuestas del backlog de Mercado, vistas como apuestas ===

  "Reducir el checkout de 3 pasos a 1 va a subir la conversion"
  suposiciones: 2  |  sin probar: 1

  "Mostrar recomendaciones personalizadas va a subir el GMV por comprador"
  suposiciones: 4  |  sin probar: 4

fasterCheckout descansa en 2 suposiciones, 1 ya probada: un salto de fe chico.
recommendations descansa en 4 suposiciones, las 4 sin probar: un salto de fe grande.
Las dos son apuestas -- ninguna es una certeza -- pero no del mismo tamano.

Fíjate en algo que describeBet() no hace todavía: no dice cuál de las suposiciones de recommendations importa más que las otras tres — solo cuenta cuántas hay y cuántas están sin probar. Eso es intencional: antes de preguntar "¿cuál pesa más?" (lecciones 4 y 5), hace falta ver el tamaño completo del salto de fe. fasterCheckout tiene una suposición sin probar ("un checkout de 1 paso no aumenta errores de pago"); si esa suposición fuera falsa, sería un problema real, pero acotado — el equipo ya tiene evidencia sólida sobre la causa principal del abandono (tested: true). recommendations tiene cuatro suposiciones sin probar a la vez: el salto de fe no es solo más grande, es estructuralmente distinto — nada de lo que sostiene la tesis tiene todavía una base verificada.

El error de "resulting" aplicado a una apuesta de producto

Imagina dos escenarios, ambos posibles para recommendations:

Escenario A. El equipo construye el motor completo sin probar ninguna suposición primero, lo lanza, y el GMV sube un 8% ese mes — pero resulta que ese mes coincidió con una campaña de descuentos que el equipo de marketing lanzó en paralelo, sin coordinar. El GMV subió por la campaña, no por las recomendaciones (nadie lo puede saber con certeza, porque nunca se aisló el efecto). El equipo concluye: "constuir sin validar funcionó, hagámoslo así de nuevo la próxima vez". Esa conclusión es "resulting" en su forma más pura: el resultado fue bueno, pero el proceso de decisión —apostar todo sin probar la suposición riesgosa— fue el mismo mal proceso, disfrazado por una coincidencia externa.

Escenario B. El equipo prueba primero, barato, si la personalización cambia el comportamiento de compra (algo que vas a ver cómo hacer en la lección 6), consigue una señal positiva clara, construye el MVP informado por esa señal, y aun así el GMV no se mueve — porque, sin que nadie lo supiera, un competidor lanzó ese mismo mes una promoción agresiva que absorbió la demanda. El equipo concluye: "probamos, tuvimos evidencia real, y aun así falló — la decisión estuvo bien tomada, el resultado se lo llevó un factor externo que no podíamos controlar ni prever". Esa es la lectura correcta: el proceso fue bueno, aunque el resultado no lo haya sido.

La diferencia entre los dos escenarios no está en el GMV final — está en si el equipo identificó su tesis, nombró sus suposiciones y probó la más riesgosa antes de comprometer recursos. Eso es lo único que puedes controlar al tomar la decisión; el resultado, no.

Errores comunes

Caer en "resulting": juzgar la decisión por el resultado. Qué pasa: como en el Escenario A del ejemplo, una apuesta que se construyó sin validar nada sale bien por una razón ajena, y el equipo aprende "no hace falta validar" — o al revés, una apuesta bien pensada falla por un factor externo, y el equipo aprende "esto no funciona, no lo intentemos de nuevo". Por qué pasa: el resultado es lo único visible y medible después de los hechos; el proceso de decisión que lo precedió es invisible si nadie lo documentó. Cómo detectarlo: la retrospectiva de una apuesta se centra por completo en "¿subió la métrica o no?" y nunca en "¿identificamos bien la tesis y probamos la suposición correcta antes de construir?". Cómo corregirlo: evalúa el proceso de decisión por separado del resultado — documenta, antes de conocer el resultado, cuál era la tesis y cuál la suposición más riesgosa que se probó (o no), y usa eso, no solo el número final, para decidir si repetir el proceso la próxima vez.

Enamorarse de la apuesta y no querer buscar la suposición que la mata. Qué pasa: quien defendió recommendations en la reunión de planeación se resiste, sin darse cuenta, a nombrar la suposición más frágil de su propia idea — la explora menos, la cuestiona menos, y en cambio se enfoca en las suposiciones más cómodas de defender. Por qué pasa: cuestionar la propia idea se siente como sabotearla; es más agradable hablar de por qué "va a funcionar" que de por qué "podría no funcionar". Cómo detectarlo: quien más entusiasmo tiene por una apuesta es, casi siempre, quien menos preguntas hace sobre sus propias suposiciones — mientras que hace preguntas duras sobre las apuestas de los demás. Cómo corregirlo: separa el rol de "quien defiende la apuesta" del rol de "quien busca su suposición más riesgosa" — o, si es la misma persona, exige explícitamente que haga el ejercicio de las lecciones 4 y 5 sobre su propia idea antes de defenderla en la reunión. Buscar la grieta en tu propia apuesta antes de que la encuentre la realidad es más barato.

Tratar todas las apuestas como igual de inciertas. Qué pasa: el equipo aplica el mismo nivel de escrutinio y precaución a fasterCheckout (1 suposición sin probar, sobre una base sólida) que a recommendations (4 suposiciones sin probar, sobre una tesis nueva), como si "todo fuera una apuesta" significara que todas pesan lo mismo. Por qué pasa: "una apuesta es una apuesta" es una frase simple que invita a tratarlas de forma uniforme, aunque el tamaño real del salto de fe sea muy distinto. Cómo detectarlo: en la reunión de planeación, fasterCheckout y recommendations reciben la misma cantidad de preguntas y el mismo nivel de validación previa, a pesar de tener un assumption stack de tamaños completamente distintos. Cómo corregirlo: usa describeBet() —o simplemente cuenta las suposiciones sin probar— para calibrar cuánto escrutinio necesita cada apuesta antes de comprometer recursos importantes. Una apuesta con un salto de fe grande necesita más validación antes de construir que una con un salto de fe chico, aunque las dos sean, técnicamente, "apuestas".

Ejercicios

Ejercicio 1 — Nombra la tesis. Para la apuesta improvedSearch del backlog de Mercado, escribe en una sola frase cuál crees que sería su thesis —la afirmación central que el equipo apuesta a que es cierta—.

Ver solución

Una tesis razonable: "Mejorar la relevancia de los resultados de búsqueda va a reducir el abandono de sesiones sin compra y subir la conversión." Fíjate en la forma de la frase: nombra una acción (mejorar la búsqueda) y un resultado esperado (menos abandono, más conversión) — exactamente la misma estructura que fasterCheckout ("reducir el checkout... va a subir la conversión") y recommendations ("mostrar recomendaciones... va a subir el GMV"). Toda tesis de este módulo sigue ese patrón: "si hacemos X, esperamos Y".

Ejercicio 2 — Identifica el "resulting". Un compañero dice: "Lanzamos sellerTools el trimestre pasado sin validar nada antes, y el GMV subió — así que para el próximo trimestre no necesitamos gastar tiempo probando suposiciones, vamos directo a construir". ¿Qué error de esta lección está cometiendo, y qué pregunta le harías antes de aceptar su conclusión?

Ver solución

Está cometiendo "resulting": está juzgando que el proceso de decisión ("construir sin validar") fue bueno solo porque el resultado (el GMV subió) fue bueno, sin haber verificado si el resultado se debió realmente a sellerTools o a otro factor. La pregunta correcta antes de aceptar la conclusión: "¿cómo sabemos que el GMV subió por sellerTools y no por otra cosa que pasó ese mismo trimestre —una temporada alta, una campaña de marketing, un cambio de precios de la competencia—?". Si no hay forma de aislar el efecto, la conclusión "no necesitamos validar" no está respaldada por el resultado — es exactamente el mismo error del Escenario A del ejemplo trabajado.

Ejercicio 3 — Compara dos saltos de fe. Sin ejecutar Node, para estas dos apuestas hipotéticas, di cuál tiene el salto de fe más grande y por qué, usando la misma lógica de describeBet():

• Apuesta X: 3 suposiciones, todas ya probadas (tested: true).
• Apuesta Y: 2 suposiciones, ninguna probada (tested: false).

Ver solución

La Apuesta Y tiene el salto de fe más grande, aunque tenga menos suposiciones en total. describeBet() no mide el tamaño del salto de fe por la cantidad total de suposiciones, sino por cuántas están sin probar — la Apuesta X tiene 3 suposiciones pero 0 sin probar (untestedAssumptions: 0), mientras que la Apuesta Y tiene 2 suposiciones y las 2 sin probar (untestedAssumptions: 2). Este ejercicio anticipa algo importante: una apuesta con muchas suposiciones nombradas y ya validadas puede ser, en la práctica, más segura que una apuesta con pocas suposiciones pero completamente sin probar. Nombrar las suposiciones es el primer paso; probarlas es lo que realmente reduce el salto de fe.

Resumen y siguiente paso

En esta lección aprendiste a ver una apuesta de producto con la misma estructura con la que Annie Duke enseña a ver una mano de póker: una thesis —lo que crees que va a pasar— sostenida por un assumption stack —las creencias que tienen que ser ciertas para que la tesis se sostenga—. Y aprendiste el error más peligroso al evaluar esas apuestas después de los hechos: "resulting", juzgar la calidad de la decisión por la calidad del resultado, cuando el resultado puede depender de factores que nunca estuvieron bajo tu control. Con describeBet() comparaste el tamaño del salto de fe de dos apuestas reales del backlog de Mercado — fasterCheckout, con una base mayormente probada, y recommendations, con cuatro suposiciones abiertas a la vez.

Antes de avanzar deberías poder: nombrar la thesis de cualquier apuesta del backlog en una frase; explicar "resulting" con un ejemplo propio; y distinguir el tamaño del salto de fe de una apuesta contando sus suposiciones sin probar.

La lección 4 entra en la pila de suposiciones de recommendations y responde la pregunta que describeBet() todavía no responde: de las cuatro suposiciones sin probar, ¿cuál es la que, si es falsa, hunde la tesis entera?

Recursos

• Annie Duke, Thinking in Bets: Making Smarter Decisions When You Don't Have All the Facts — annieduke.com/annie-duke-thinking-in-bets. La fuente del vocabulario central de esta lección: tratar las decisiones como apuestas, y el peligro de juzgarlas por su resultado. En inglés.
• Nautilus, "The Resulting Fallacy Is Ruining Your Decisions" — nautil.us/the-resulting-fallacy-is-ruining-your-decisions-236901. Un artículo enfocado específicamente en "resulting", con ejemplos fuera del póker que ayudan a ver el patrón en otros contextos. En inglés.
• Marty Cagan / SVPG, blog de Silicon Valley Product Group — svpg.com/articles — sobre por qué los mejores equipos de producto tratan cada apuesta como una hipótesis a probar, no como una certeza a defender. En inglés.