Busca la desconfirmación, activamente

Descripción

El módulo 4 de esta guía ya te enseñó una versión de esta pregunta —al diseñar un test, ¿puede de verdad refutar la hipótesis?—. Esta lección aplica la misma disciplina a un momento distinto: al leer un resultado, no al diseñarlo. La pregunta central es la misma en espíritu, pero se hace en otro instante: no "¿este test podría fallar?" sino "¿qué evidencia específica, si la viera ahora mismo, me haría cambiar de opinión?" — y la diferencia entre hacerse esa pregunta antes de ver el resultado o después de verlo es, como vas a comprobar en el ejemplo de hoy, la diferencia entre protegerte del sesgo de confirmación y quedar completamente expuesto a él.

Buscar desconfirmación activamente no es una actitud pesimista ni una forma de sabotear tu propia idea — es, según Kahneman, lo opuesto a lo que el cerebro hace por defecto: el pensamiento intuitivo tiende a una "estrategia de prueba positiva", buscando datos compatibles con lo que ya cree, en vez de buscar activamente los que lo contradicen. Contrarrestar esa tendencia por defecto requiere un esfuerzo deliberado — no pasa solo, aunque tengas buenas intenciones.

Conexión con el módulo. Esta lección no introduce un modelo formal nuevo del módulo (esos son sampleBias() en la lección 4 y rankByStrength() en la lección 6), pero construye preRegisteredCheck(), un modelo pedagógico pequeño que ilustra el punto central: compara el mismo resultado numérico leído por dos equipos, uno que escribió su condición de fracaso antes de ver el número, y otro que no. Conecta directamente con isFalsifiable() del módulo 4 —la misma disciplina de escribir el wrongIf con antelación— pero aplicada ahora al momento de la lectura, no del diseño.

Una analogía cotidiana: el buen mecánico busca la falla, no confirma que "suena bien"

Llevas tu auto al taller porque hace un ruido raro al frenar. Hay dos formas muy distintas en que un mecánico puede revisar el problema. La primera: enciende el auto, lo escucha unos segundos, dice "suena bien" y te lo entrega. La segunda: desarma el freno, revisa el desgaste de las pastillas contra un umbral específico, prueba el pedal buscando activamente cualquier indicio de la falla que tú describiste — no se conforma con "no escuché nada raro en el primer segundo", sino que busca, con intención, la evidencia que confirmaría que sí hay un problema.

La diferencia no está en la herramienta ni en el tiempo dedicado — puede tomar minutos similares. Está en la actitud: el primer mecánico está buscando una razón para decir "está bien" y entregarte el auto rápido; el segundo está buscando, activamente, la razón por la que no debería decirte que está bien. Leer el resultado de un fake door o de una entrevista sin buscar activamente la evidencia que lo refutaría es exactamente el primer mecánico — puedes "escuchar" el resultado, notar que "no suena tan mal", y entregar una conclusión que no resistiría un examen más cuidadoso.

Ejemplo trabajado: el mismo 5.2% de clics, leído por dos equipos

El fake door de recommendations (elegido en el módulo 4, construido en el módulo 5) termina con una tasa de clics del 5.2%. Es un número real, sin ambigüedad en sí mismo — la ambigüedad aparece en cómo se lee. Comparamos dos equipos: uno que escribió su condición de fracaso antes de correr el test, y otro que decide qué pensar después de ver el número.

// L5: preRegisteredCheck() -- compara el resultado real de un test contra la condicion
// de fracaso (wrongIf) escrita ANTES de correrlo. La pregunta central de la leccion
// --que evidencia me probaria equivocado-- solo protege si la respuesta se escribe
// antes de ver el resultado, no despues.
function preRegisteredCheck(test) {
  if (!test.wrongIfWrittenBefore) {
    return { ...test, verdict: 'sin proteccion -- no hay condicion de fracaso escrita antes de ver el resultado' };
  }
  const failed = test.actualClickRate < test.wrongIfBelowClickRate;
  return {
    ...test,
    verdict: failed
      ? 'la hipotesis fallo su propia condicion de fracaso -- toca tomarlo en serio'
      : 'la hipotesis paso su propia condicion de fracaso',
  };
}

const withPreRegistration = {
  label: 'Equipo A -- escribio wrongIf antes de correr el fake door',
  wrongIfWrittenBefore: true,
  wrongIfBelowClickRate: 8,
  actualClickRate: 5.2,
};

const withoutPreRegistration = {
  label: 'Equipo B -- decidio que "5.2% no esta tan mal" despues de ver el numero',
  wrongIfWrittenBefore: false,
  actualClickRate: 5.2,
};

console.log('=== preRegisteredCheck() sobre el mismo resultado (5.2% de clics), dos equipos ===\n');
[withPreRegistration, withoutPreRegistration].forEach((t) => {
  const result = preRegisteredCheck(t);
  console.log(t.label + ':');
  console.log('  ' + result.verdict);
  console.log('');
});

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

=== preRegisteredCheck() sobre el mismo resultado (5.2% de clics), dos equipos ===

Equipo A -- escribio wrongIf antes de correr el fake door:
  la hipotesis fallo su propia condicion de fracaso -- toca tomarlo en serio

Equipo B -- decidio que "5.2% no esta tan mal" despues de ver el numero:
  sin proteccion -- no hay condicion de fracaso escrita antes de ver el resultado

El número —5.2% de clics— es idéntico para los dos equipos. Lo único que cambia es si existía, por escrito, una condición de fracaso antes de que ese número existiera. El Equipo A había declarado, con antelación, que menos de 8% contaría como evidencia en contra de la hipótesis — así que cuando el resultado llega en 5.2%, no hay espacio para negociar consigo mismos: la hipótesis falló su propia condición, escrita cuando nadie sabía todavía qué iba a pasar. El Equipo B, sin ese ancla previa, queda completamente expuesto: puede decidir, en el momento, que "5.2% no está tan mal" — una lectura perfectamente posible del mismo número, y exactamente el tipo de decisión post-hoc que el sesgo de confirmación favorece sin que nadie lo note.

La pregunta, aplicada a un resultado que ya tienes enfrente

Si ya tienes un resultado sobre la mesa y nunca escribiste una condición de fracaso con antelación —el caso más común, honestamente, en equipos reales—, la pregunta de esta lección todavía sirve, aunque de forma más débil: pregúntate, ahora mismo, "si este número hubiera salido más bajo de lo que salió, ¿en qué punto habría dejado de sentirme cómodo con la idea?" Escribir esa respuesta antes de decidir qué hacer con el número que ya tienes —aunque sea tarde para la pre-registración perfecta— sigue siendo mejor que decidir directamente "esto confirma lo que pensaba", sin pasar por ninguna pregunta intermedia.

Errores comunes

No escribir de antemano qué resultado te haría cambiar de opinión. Qué pasa: el equipo corre un test —entrevistas, fake door, prototipo— sin haber declarado antes, en ningún lugar, qué número o qué patrón de respuestas contaría como "esto refuta la idea". Cuando el resultado llega, la conversación se convierte en negociar, en tiempo real, si el número "cuenta" como suficiente evidencia. Por qué pasa: escribir una condición de fracaso antes de tener ningún dato se siente como un paso extra, burocrático, cuando lo urgente parece ser correr el test cuanto antes. Cómo detectarlo: pregunta, antes de correr cualquier test, "¿qué resultado específico nos haría abandonar esta idea?" — si nadie puede responder con un número o un criterio concreto, no hay condición de fracaso escrita, y la lectura posterior queda sin protección, como el Equipo B del ejemplo de hoy. Cómo corregirlo: adopta el mismo hábito que isFalsifiable() exige del módulo 4 —el wrongIf— pero muévelo al calendario correcto: se escribe antes de correr el test, nunca después de ver el resultado.

Descartar la evidencia que refuta como "esos usuarios no entendieron". Qué pasa: cuando el resultado de un test contradice claramente la hipótesis, alguien ofrece una explicación que lo neutraliza sin someterla al mismo escrutinio que se le exigiría a una evidencia favorable — "esos usuarios no entendieron bien el prototipo", "el fake door tenía un bug", "ese día había poco tráfico". Por qué pasa: buscar activamente por qué un resultado incómodo podría estar equivocado es mucho más fácil, cognitivamente, que aceptar que la hipótesis podría estarlo — y casi siempre existe alguna explicación alternativa plausible, lo cual la hace tentadora de usar sin verificarla. Cómo detectarlo: pregúntate si aplicarías el mismo nivel de sospecha a un resultado que confirmara la hipótesis — ¿revisarías con el mismo cuidado si "el prototipo tenía un bug" cuando el resultado sale bien? Si la respuesta es no, el escrutinio no es parejo. Cómo corregirlo: cualquier explicación que descarte un resultado desfavorable debe verificarse con la misma evidencia que exigirías para aceptar un resultado favorable — no basta con que sea plausible, tiene que confirmarse por separado, no inventarse para salvar la hipótesis.

Ejercicios

Ejercicio 1 — Corre preRegisteredCheck() sobre un tercer caso. Un equipo escribió wrongIfWrittenBefore: true, wrongIfBelowClickRate: 3 antes de correr su fake door, y obtuvo actualClickRate: 4.5. ¿Qué verdict devuelve preRegisteredCheck(), y qué significa en términos de la hipótesis?

Ver solución

failed = 4.5 < 3 es false, así que el verdict es 'la hipotesis paso su propia condicion de fracaso'. A diferencia del ejemplo trabajado, aquí el resultado real (4.5%) está por encima del umbral que el equipo mismo definió como fracaso (3%) — la hipótesis sobrevive su propia prueba, con un criterio que se escribió antes de conocer el resultado. Esto no significa que la hipótesis esté "probada" de forma definitiva (eso depende también de la fuerza de la evidencia, tema de la lección 6, y de la síntesis completa del módulo 7) — significa, específicamente, que este resultado no calificó como la señal de fracaso que el equipo había definido con antelación.

Ejercicio 2 — Diagnostica cuál equipo está protegido. Dos equipos observan el mismo resultado ambiguo de una entrevista. El equipo X dice: "esperábamos que al menos 6 de 10 usuarios mencionaran el problema sin que se lo sugiriéramos; solo lo mencionaron 3, así que no se validó la oportunidad." El equipo Y dice: "3 de 10 mencionaron el problema — no está mal, considerando que es un tema nuevo para ellos." ¿Cuál equipo aplicó la disciplina de esta lección, y cómo lo sabes?

Ver solución

El equipo X. Su frase revela que existía un umbral específico ("al menos 6 de 10") declarado antes de conocer el resultado real — el mismo patrón que preRegisteredCheck() marca como protegido. El equipo Y, en cambio, evalúa el número (3 de 10) con un criterio inventado en el momento ("no está mal, considerando...") sin ninguna referencia a un umbral previo — exactamente el patrón sin protección del Equipo B en el ejemplo trabajado de esta lección. El número real (3 de 10) es el mismo tipo de resultado ambiguo en ambos casos; lo que distingue a los dos equipos es si tenían, de antemano, una regla para leerlo.

Ejercicio 3 — Aplica la analogía del mecánico a tu propio trabajo. Describe, en dos o tres frases, una situación (real o inventada) donde revisaste algo —código, un diseño, un plan— buscando confirmar que "estaba bien" en vez de buscar activamente la falla que lo tumbaría. ¿Qué habría cambiado si hubieras escrito, antes de revisar, qué tipo de problema específico estabas buscando?

Ver solución

No hay una respuesta única — depende del ejemplo que elijas —, pero un buen ejemplo debería reconocer la misma estructura del mecánico: una revisión que, sin mala intención, se detuvo en "no encontré nada raro a primera vista" en vez de buscar activamente una falla específica y conocida (un caso límite, un tipo de error común en ese contexto). Lo que cambiaría, en cualquier caso, es lo mismo que en el ejemplo de Mercado: escribir de antemano "voy a buscar específicamente X" convierte una revisión pasiva —que tiende a confirmar que todo está bien— en una búsqueda activa, con una meta clara de lo que contaría como encontrar un problema real.

Resumen y siguiente paso

Esta lección tomó una pregunta que ya conocías del módulo 4 —¿qué resultado me probaría equivocado?— y la movió del momento de diseñar un test al momento de leer su resultado. Viste ejecutado preRegisteredCheck() sobre el mismo número exacto, 5.2%, leído por dos equipos: uno protegido por una condición de fracaso escrita con antelación, que reconoce sin ambigüedad que la hipótesis falló; y otro sin esa protección, completamente expuesto a decidir en el momento que "no está tan mal". El número nunca cambió — lo que cambió fue si existía, por escrito, una regla previa para leerlo.

Antes de avanzar deberías poder: explicar la diferencia entre preguntarte "¿qué me probaría equivocado?" antes de ver un resultado y preguntártelo después; y aplicar esa pregunta a un resultado ambiguo real, no solo a uno de Mercado.

La lección 6 le da a esta disciplina un aliado que no depende de la fuerza de voluntad de nadie: un número. Vas a construir rankByStrength(), que pesa cualquier pieza de evidencia por su tipo —comportamiento observado, comportamiento reportado, opinión declarada, hipotético— sin importar cuán convincente se sintió en el momento de escucharla.

Recursos

• Daniel Kahneman, Thinking, Fast and Slow — us.macmillan.com/books/9780374533557/thinkingfastandslow. La fuente de la "estrategia de prueba positiva": Kahneman describe cómo el pensamiento intuitivo busca por defecto datos compatibles con una creencia, en vez de buscar activamente los que la contradicen. En inglés.
• Paul Saffo, entrevista "Betting on Strong Opinions, Weakly Held" — saffo.com/interviews. El origen del principio "opiniones fuertes, sostenidas débilmente": forma una conclusión con la evidencia disponible, y después dedícate, activamente, a intentar tumbarla — la misma disciplina de esta lección, aplicada a cualquier tipo de pronóstico o decisión. En inglés.
• Karl Popper, entrada "Karl Popper" en la Stanford Encyclopedia of Philosophy — plato.stanford.edu/entries/popper. La misma fuente filosófica del módulo 4, relevante aquí desde otro ángulo: Popper insistía en que la ciencia se distingue por buscar activamente la refutación, no solo por poder ser refutada en teoría. En inglés.