Módulo 6: Thinking In Bets And Assumptions

Mini-proyecto: encuentra la suposición más riesgosa de `recommendations`

Siguiente →

Descripción

Es hora de juntar todo el módulo en una sola entrega, de punta a punta. Aprendiste a separar hechos de suposiciones con classify() (lección 2), a organizar esas suposiciones alrededor de la tesis de una apuesta y a no juzgar la decisión por su resultado (lección 3), a encontrar cuál suposición sostiene el peso real de la tesis (lección 4), a cuantificarla con risk x impact usando rankAssumptions() (lección 5), a decidir qué prueba barata la ataca sin construir todo primero (lección 6), y a calibrar el confidence de RICE según si esa prueba ya se corrió (lección 7). En este mini-proyecto tomas la apuesta recommendations del backlog de Mercado —la misma que acompañó al módulo desde la presentación— y corres el pipeline completo: de la lista cruda de afirmaciones hasta la recomendación final de qué probar y por qué.

Y no solo lo razonas: lo verificas. Tu entrega corre, con Node, cuatro pasos en secuencia sobre las seis afirmaciones reales de recommendations — classify() para separar hecho de suposición, rankAssumptions() para ordenar las suposiciones por riesgo, la identificación explícita de la riskiest assumption y su test más barato, y finalmente una simulación de qué pasa una vez que el equipo corre ese test y consigue evidencia real—. Es la síntesis del módulo entero, aplicada al caso que lo acompañó desde el principio, y el ensayo directo de una parte del capstone de la guía (módulo 8), donde este mismo backlog va a pasar por el dimensionamiento de oportunidad (módulo 4), la priorización con RICE (módulo 3), el recorte a MVP (módulo 5) y el costo de demora (módulo 7) antes de convertirse en el roadmap final del trimestre.

Conexión con el módulo. Este proyecto cierra el módulo reuniendo sus siete lecciones en una sola entrega: la separación hecho/suposición (lección 2) como el punto de partida, la estructura de tesis y assumption stack (lección 3) como el marco, la búsqueda de la riskiest assumption (lecciones 4 y 5) como el motor del análisis, el test barato (lección 6) como la acción concreta, y la confidence calibrada (lección 7) como el cierre honesto del ciclo. Lo que armas hoy —una apuesta diseccionada de punta a punta, con su suposición más peligrosa nombrada y su plan de prueba definido— es exactamente el insumo que el módulo 7 va a ordenar junto al resto del backlog por costo de demora, y que el módulo 8 va a convertir en el roadmap defendible del trimestre.

Una analogía: abrir el cimiento completo, no revisar una sola grieta

Vuelve a la casa de la presentación del módulo. Hasta ahora trabajaste una pieza a la vez: separaste hechos de suposiciones (lección 2), miraste una sola suposición a la vez con la pregunta del bloque de carga (lección 4), calculaste un score para cada una por separado (lección 5). Hoy haces lo que un inspector de estructuras hace de verdad antes de aprobar una construcción: abre el cimiento completo, revisa cada parte con el mismo criterio, y entrega un solo informe que dice, sin ambigüedad, cuál es la parte que hay que reforzar antes de seguir construyendo — no una lista de sospechas sueltas, sino una conclusión ordenada y accionable.

La solución de referencia, verificada

Vamos a construir la solución completa y verificarla, para que tengas un patrón claro. (Los ejercicios del final te piden extenderla y razonar sobre ella.)

Parte 1 — Las afirmaciones completas, con risk e impact declarados

Antes de correr nada, esta es la lista completa de afirmaciones detrás de recommendations, tal como el equipo las dejó por escrito — las mismas seis de la lección 2, ahora con risk e impact ya asignados a las que resultaron ser suposiciones:

Afirmacion                                                    Evidencia            risk   impact
─────────────────────────────────────────────────────────────  ──────────────────  ─────  ──────
Mercado tiene 5,000 compradores activos por dia                 dashboard analytics   -      -
Historial de compra para el 80% de compradores activos          query al warehouse     -      -
Los usuarios compran mas si ven recomendaciones personalizadas   (ninguna)            0.6     5
El equipo construye el motor basico en 3 person-months           (ninguna)            0.4     2
Los vendedores no se quejan de productos menos visibles          (ninguna)            0.3     3
Mostrar recomendaciones no baja la velocidad de carga             (ninguna)            0.2     3

Las dos primeras filas ya tienen evidencia — no necesitan risk ni impact, porque classify() las va a marcar como fact de entrada—. Las cuatro últimas son las suposiciones reales que el pipeline de hoy va a rankear.

Parte 2 — El pipeline completo, ejecutado en Node

Reutilizamos, sin cambios, classify() (lección 2) y rankAssumptions() (lección 5), y agregamos los dos pasos que le dan cierre práctico al análisis: nombrar el test más barato para la riskiest assumption, y simular el resultado de correrlo.

// Mini-proyecto: pipeline completo sobre la apuesta "recommendations" de Mercado.
// claims -> classify (hecho/suposicion) -> rankAssumptions (risk x impact) -> riskiest.
function classify(claims) {
  return claims.map((c) => ({ ...c, type: c.evidence ? 'fact' : 'assumption' }));
}

function rankAssumptions(assumptions) {
  return assumptions
    .map((a) => ({ ...a, score: a.risk * a.impact }))
    .sort((a, b) => b.score - a.score)
    .map((a, i) => ({ ...a, riskiest: i === 0 }));
}

// --- Paso 1: todas las afirmaciones detras de la apuesta, sin filtrar ---
const claims = [
  { text: 'Mercado tiene 5,000 compradores activos por dia',
    evidence: 'dashboard de analytics, actualizado hoy', risk: 0, impact: 0 },
  { text: 'Tenemos historial de compra registrado para el 80% de los compradores activos',
    evidence: 'query a la tabla purchases del data warehouse', risk: 0, impact: 0 },
  { text: 'Los usuarios van a comprar mas si ven recomendaciones personalizadas',
    evidence: null, risk: 0.6, impact: 5 },
  { text: 'El equipo puede construir un motor basico de recomendaciones en 3 person-months',
    evidence: null, risk: 0.4, impact: 2 },
  { text: 'Los vendedores no se van a quejar de que sus productos menos populares queden menos visibles',
    evidence: null, risk: 0.3, impact: 3 },
  { text: 'Mostrar recomendaciones en la home no baja la velocidad de carga de forma perceptible',
    evidence: null, risk: 0.2, impact: 3 },
];

console.log('=== Paso 1: classify() sobre "recommendations" ===\n');
const classified = classify(claims);
classified.forEach((c) => console.log('  [' + c.type.toUpperCase().padEnd(10) + '] ' + c.text));

const facts = classified.filter((c) => c.type === 'fact');
const assumptions = classified.filter((c) => c.type === 'assumption');
console.log('\n  facts: ' + facts.length + '  |  assumptions: ' + assumptions.length);

console.log('\n=== Paso 2: rankAssumptions() sobre las ' + assumptions.length + ' suposiciones ===\n');
const ranked = rankAssumptions(assumptions);
ranked.forEach((a, i) => {
  console.log('  ' + (i + 1) + '. score=' + a.score.toFixed(1) +
    (a.riskiest ? '  <-- RISKIEST ASSUMPTION' : '') + '   ' + a.text);
});

const riskiest = ranked[0];
console.log('\n=== Paso 3: la suposicion mas riesgosa ===\n');
console.log('  "' + riskiest.text + '"');
console.log('  score=' + riskiest.score.toFixed(1) + ' (risk=' + riskiest.risk + ' x impact=' + riskiest.impact + ')');
console.log('\n  Test mas barato que la ataca (el DISENO del test, a fondo, es la guia de discovery):');
console.log('  mostrar recomendaciones curadas a mano a 50 usuarios durante 1 semana y medir si');
console.log('  compran mas que un grupo sin recomendaciones -- sin construir ningun motor todavia.');

// --- Paso 4: el equipo corre ese test barato y consigue evidencia real ---
console.log('\n=== Paso 4: el equipo corre el test y ahora SI hay evidencia ===\n');
const claimsAfterTest = claims.map((c) =>
  c.text === riskiest.text
    ? { ...c, evidence: 'test de curaduria manual, 1 semana, 50 usuarios: +18% de compra' }
    : c
);
const classifiedAfter = classify(claimsAfterTest);
const assumptionsAfter = classifiedAfter.filter((c) => c.type === 'assumption');
console.log('  facts: ' + classifiedAfter.filter((c) => c.type === 'fact').length +
  '  |  assumptions: ' + assumptionsAfter.length + '  (bajo de ' + assumptions.length + ')');
console.log('\n  "' + riskiest.text + '"');
console.log('  paso de ASSUMPTION a FACT: ya tiene evidencia real, no solo una creencia del equipo.');

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

=== Paso 1: classify() sobre "recommendations" ===

  [FACT      ] Mercado tiene 5,000 compradores activos por dia
  [FACT      ] Tenemos historial de compra registrado para el 80% de los compradores activos
  [ASSUMPTION] Los usuarios van a comprar mas si ven recomendaciones personalizadas
  [ASSUMPTION] El equipo puede construir un motor basico de recomendaciones en 3 person-months
  [ASSUMPTION] Los vendedores no se van a quejar de que sus productos menos populares queden menos visibles
  [ASSUMPTION] Mostrar recomendaciones en la home no baja la velocidad de carga de forma perceptible

  facts: 2  |  assumptions: 4

=== Paso 2: rankAssumptions() sobre las 4 suposiciones ===

  1. score=3.0  <-- RISKIEST ASSUMPTION   Los usuarios van a comprar mas si ven recomendaciones personalizadas
  2. score=0.9   Los vendedores no se van a quejar de que sus productos menos populares queden menos visibles
  3. score=0.8   El equipo puede construir un motor basico de recomendaciones en 3 person-months
  4. score=0.6   Mostrar recomendaciones en la home no baja la velocidad de carga de forma perceptible

=== Paso 3: la suposicion mas riesgosa ===

  "Los usuarios van a comprar mas si ven recomendaciones personalizadas"
  score=3.0 (risk=0.6 x impact=5)

  Test mas barato que la ataca (el DISENO del test, a fondo, es la guia de discovery):
  mostrar recomendaciones curadas a mano a 50 usuarios durante 1 semana y medir si
  compran mas que un grupo sin recomendaciones -- sin construir ningun motor todavia.

=== Paso 4: el equipo corre el test y ahora SI hay evidencia ===

  facts: 3  |  assumptions: 3  (bajo de 4)

  "Los usuarios van a comprar mas si ven recomendaciones personalizadas"
  paso de ASSUMPTION a FACT: ya tiene evidencia real, no solo una creencia del equipo.

Recorre el resultado por partes y reconoce lo que cada una certifica:

  • Paso 1 (classify). De seis afirmaciones, dos ya eran hechos verificables y cuatro eran suposiciones — la misma proporción que viste en la lección 2, ahora como punto de entrada del pipeline completo, no como ejercicio aislado.
  • Paso 2 (rankAssumptions). Las cuatro suposiciones quedan ordenadas sin ambigüedad: "los usuarios compran más" domina con score=3.0, más de tres veces la segunda (0.9). No hace falta ningún juicio adicional para saber cuál es la riskiest — el número lo dice.
  • Paso 3 (la riskiest y su test). El pipeline nombra explícitamente la suposición ganadora y el test más barato que la ataca — una prueba de curaduría manual, sin construir el motor de recomendaciones automático, que sigue la regla de la lección 6: mucho más barata que construir todo, y todavía capaz de dar una señal real (compara contra un grupo sin recomendaciones, no es una encuesta de opinión).
  • Paso 4 (después del test). Con evidencia real en mano, la misma afirmación que empezó el pipeline como assumption termina como fact — el conteo baja de 4 a 3 suposiciones, y el confidenceCeiling de la lección 7, recalculado con este nuevo estado, subiría de 0.3 a 0.8, exactamente como viste en esa lección.

El pipeline completo —de seis afirmaciones crudas a una decisión concreta de qué probar y por qué— es la respuesta final del módulo a la pregunta que abrió la presentación: "¿en qué descansa esta apuesta, y cuál de esas cosas la puede hundir?".

Errores comunes

Confundir "identificamos la riskiest assumption" con "ya la resolvimos". Qué pasa: el equipo corre el pipeline hasta el Paso 3, celebra haber encontrado la suposición más riesgosa, y sigue adelante con la construcción normal sin correr el Paso 4 —el test que de verdad reduce la incertidumbre—. Por qué pasa: identificar y nombrar algo se siente como progreso real, y a veces es más satisfactorio que la parte incómoda de diseñar y correr una prueba. Cómo detectarlo: la reunión de planeación termina con "ya sabemos cuál es la suposición riesgosa" como conclusión final, sin un plan concreto de cuándo y cómo se va a probar. Cómo corregirlo: nombrar la riskiest assumption es el Paso 3 de cuatro, no el final del proceso — el proyecto de hoy no está completo hasta que el Paso 4 (o su equivalente real, con usuarios de verdad) efectivamente se corre.

Elegir el test más barato disponible en general, en vez del que ataca específicamente la riskiest assumption. Qué pasa: en vez de diseñar un test para "los usuarios compran más al ver recomendaciones" (la riskiest), el equipo corre el test más sencillo que tiene a mano —una encuesta rápida sobre si a los vendedores les molestaría la funcionalidad— y lo presenta como "avance de validación del módulo". Por qué pasa: es exactamente el error de la lección 6, repetido en el contexto del proyecto completo: correr algún test se siente productivo, sin verificar que ataque la suposición correcta. Cómo detectarlo: después de "validar", el score de la riskiest assumption en el ranking del Paso 2 no cambió, aunque el equipo sí corrió algún tipo de prueba. Cómo corregirlo: antes de diseñar cualquier test, verifica que su resultado, sea cual sea, cambiaría directamente el estado de tested de la suposición que quedó en el Paso 3 — si el test no puede hacer eso, no es el test de este proyecto.

Detenerse en el ranking sin conectar con el resto de las decisiones de la apuesta. Qué pasa: el equipo produce un ranking impecable de suposiciones, identifica la riskiest, incluso corre el test — y ahí se detiene, sin preguntarse cómo este resultado cambia el confidence en RICE (módulo 3), el tamaño de MVP a construir (módulo 5), o el lugar de la apuesta en el roadmap del trimestre (módulo 7). Por qué pasa: el análisis de suposiciones se siente como un ejercicio completo en sí mismo, y conectar sus resultados con las otras herramientas del ecosistema —RICE, MVP, WSJF— requiere un paso adicional que se puede pasar por alto. Cómo detectarlo: el equipo puede recitar la riskiest assumption de una apuesta, pero no puede decir qué confidence debería tener esa apuesta en el backlog priorizado, ni si el resultado del test cambia el orden. Cómo corregirlo: cierra siempre el análisis conectándolo de vuelta con la lección 7 —¿cuál es el confidenceCeiling antes y después del test?— y anticipa que el módulo 8 va a exigir esa misma conexión para el backlog completo del trimestre.

Ejercicios

Ejercicio 1 — Recalcula el confidenceCeiling después del proyecto. Usando el resultado del Paso 4 (la riskiest assumption ya probada, con risk: 0.6, impact: 5, tested: true, y las otras tres suposiciones sin cambios respecto al estado original de la lección 7), calcula el confidenceCeiling resultante sin ejecutar Node, y compáralo con el confidence: 0.5 original del módulo 3.

Ver solución

Con la riskiest assumption ahora tested: true, la condición !riskiest.tested de confidenceCeiling() es falsa, así que la función salta directo al último return 0.8. El resultado es idéntico al que viste en la lección 7 con este mismo escenario: el techo sube de 0.3 (antes del test) a 0.8 (después). Comparado con el confidence: 0.5 original del módulo 3, el valor calibrado hoy —0.8— es más alto que el original, y esta vez con una justificación concreta y verificable: no "nos sentimos más seguros", sino "la suposición que sostiene el peso de la tesis ya tiene evidencia real detrás, de un test propio de Mercado".

Ejercicio 2 — Corre el pipeline sobre una apuesta distinta. Elige sellerTools (herramientas para vendedores) y escribe, sin ejecutar Node, una lista de al menos 4 afirmaciones (mezcla de fact y assumption, con risk e impact para las suposiciones) que sostendrían esa apuesta. Identifica cuál sería, según tu propia estimación, la riskiest assumption, y justifica por qué.

Ver solución

Una lista razonable:

  • fact: "El 60% de los tickets de soporte del trimestre pasado piden mejor gestión de inventario" (con un reporte de soporte como evidencia).
  • assumption: "Si damos mejores herramientas, los vendedores suben más productos al catálogo" (risk: 0.4, impact: 4 — es, en esencia, el mecanismo central de la tesis: si esto es falso, la apuesta pierde su razón de ser).
  • assumption: "El equipo puede construir el panel de gestión en 2 person-months" (risk: 0.3, impact: 2 — un riesgo de feasibility, acotado en su daño si está mal estimado).
  • assumption: "Los vendedores actuales van a adoptar la herramienta sin necesitar capacitación extensa" (risk: 0.5, impact: 3 — un riesgo de usabilidad real, pero probablemente resoluble con mejor onboarding si resulta falso).

Con estos números, la riskiest assumption sería "si damos mejores herramientas, los vendedores suben más productos" (score = 0.4 x 4 = 1.6, la más alta de las tres), porque es la única cuya falsedad haría que toda la apuesta perdiera sentido —las otras dos, aunque reales, son manejables incluso si resultan equivocadas—.

Ejercicio 3 — Diseña el test más barato para tu propia riskiest assumption. Para la riskiest assumption que identificaste en el ejercicio 2 (sellerTools), describe en 2-3 frases el test más barato que se te ocurra que le daría al equipo una señal real, sin construir el panel de gestión completo. No hace falta diseñarlo a fondo —eso es terreno de discovery—; basta con nombrar el enfoque general y por qué sería más barato que construir todo.

Ver solución

Una respuesta razonable: pedirle a un grupo pequeño de vendedores activos que suban productos usando una hoja de cálculo compartida con mejor estructura (en vez del panel actual), asistidos manualmente por alguien del equipo durante una semana, y medir si efectivamente suben más productos que un grupo de control sin ese apoyo. Es mucho más barato que construir el panel completo —no requiere ningún desarrollo de software, solo tiempo de una persona coordinando manualmente—, y sigue dando una señal real sobre el mecanismo central de la tesis: si mejor soporte para gestionar inventario efectivamente cambia cuántos productos suben los vendedores. El diseño fino de ese experimento —cómo reclutar al grupo, cómo evitar sesgos, cuánto tiempo correrlo— es, como ya viste en la lección 6, trabajo de product-discovery-and-prototyping-guide.

Resumen y siguiente paso

En este mini-proyecto corriste el pipeline completo del módulo sobre la apuesta recommendations: classify() separó 2 hechos de 4 suposiciones, rankAssumptions() identificó sin ambigüedad la riskiest assumption (score=3.0, "los usuarios compran más al ver recomendaciones"), nombraste el test más barato que la ataca sin construir el motor completo, y simulaste el resultado de correrlo: la misma afirmación que empezó como creencia terminó, con evidencia real, convertida en hecho verificable — lista para que el confidenceCeiling de la lección 7 suba de 0.3 a 0.8 con total honestidad.

Con esto cierras el módulo 6. Ahora puedes tomar cualquier apuesta del backlog, separar lo que se sabe de lo que se cree, encontrar la suposición que puede hundirla, decidir cómo probarla barato y primero, y calibrar tu confianza en la apuesta según lo que realmente se comprobó — no según cuánto entusiasmo genera en la sala.

Hacia dónde sigues. El módulo 7 toma este mismo análisis y le agrega la dimensión del tiempo: el costo de demora y WSJF — cuánto cuesta esperar para probar la riskiest assumption de una apuesta, comparado con otras del backlog—. El módulo 8, el capstone de la guía, junta todo lo que aprendiste en los ocho módulos —outcomes sobre outputs, la cadena de valor, RICE, dimensionamiento de oportunidad, MVP, apuestas y suposiciones, costo de demora— en el roadmap final y defendible del trimestre de Mercado. Lo que armaste hoy —una apuesta diseccionada de punta a punta— es exactamente la pieza que ese capstone va a pedirte para cada una de las cinco apuestas del backlog.

Recursos

  • Annie Duke, Thinking in Bets — annieduke.com/annie-duke-thinking-in-bets. La tesis que sostiene el módulo entero: decidir bien no es lo mismo que acertar el resultado; revísala como cierre, con la apuesta recommendations de hoy como ejemplo propio. En inglés.
  • David J. Bland y Alexander Osterwalder, Testing Business Ideas — resumen en strategyzer.com/library/testing-business-ideas-book-summary. El libro de referencia completo para seguir practicando "assumptions mapping" en apuestas reales, más allá del caso de Mercado. En inglés.
  • Marty Cagan / SVPG, "The Four Big Risks" — svpg.com/four-big-risks. Útil como checklist final: antes de cerrar el análisis de cualquier apuesta, revisa si cubriste los cuatro tipos de riesgo (valor, usabilidad, factibilidad, viabilidad de negocio), no solo el que resultó ser el más riesgoso esta vez. En inglés.
  • Teresa Torres, "Opportunity Solution Trees" — producttalk.org/opportunity-solution-trees. El siguiente paso natural después de este módulo: cómo un equipo de descubrimiento continuo repite este mismo ciclo —nombrar, probar, aprender— semana tras semana, no solo una vez por trimestre. La entrada natural a product-discovery-and-prototyping-guide. En inglés.
← AnteriorConfianza calibradaSiguiente →Presentación del módulo: ya sabes puntuar, dimensionar y recortar. Falta la pregunta que de verdad duele