Cómo escribir hipótesis que no se mueran en la primera reunión

La mayoría de hipótesis de growth mueren en la reunión de revisión. No porque el experimento haya fallado. Sino porque nadie se pone de acuerdo en qué significa que haya fallado o funcionado.

El problema no es el resultado. Es que la hipótesis estaba mal escrita desde el principio.

1. El problema con las hipótesis vagas

"Creemos que si mejoramos el onboarding, más usuarios se activarán."

Esta hipótesis parece razonable. Pero tiene tres problemas críticos:

  • ¿Qué significa "mejorar el onboarding"? No está definido el cambio específico.
  • ¿Qué significa "más usuarios"? Sin un número, cualquier resultado es válido.
  • ¿En qué plazo? Sin una ventana temporal, el experimento puede vivir para siempre.

Cuando el resultado llega, empieza el debate. "Un 2% de mejora cuenta como éxito?" "¿Lo medimos en 7 días o en 30?" La hipótesis vaga convierte cada experimento en una negociación.

2. El formato que elimina la ambigüedad

El formato que uso con equipos de producto tiene cuatro componentes:

Creemos que [cambio específico] para [segmento específico] resultará en [métrica medible] porque [razonamiento basado en datos o comportamiento observado].

Aplicado al mismo caso:

"Creemos que reducir el onboarding de 7 pasos a 3 pasos para usuarios que se registran desde mobile resultará en un incremento del 15% en la tasa de activación a 48 horas, porque el análisis de sesiones muestra que el 60% de los abandonos ocurren en el paso 4 de configuración."

Ahora hay un cambio definido, un segmento específico, una métrica con umbral numérico y una ventana temporal. Y hay un razonamiento que puede ser refutado o confirmado.

3. El componente más ignorado: el razonamiento

La mayoría de equipos escribe el "porque" como una intuición. "Porque creemos que los usuarios prefieren experiencias más simples."

Eso no es un razonamiento. Es una opinión.

Un razonamiento válido cita un dato observado:

  • Datos de comportamiento: "el 60% de los abandonos ocurren en el paso 4."
  • Investigación de usuario: "3 de 5 usuarios en entrevistas mencionaron confusión en el paso de configuración."
  • Benchmark externo: "el promedio de activación en SaaS B2B con onboarding de 3 pasos es 40% vs 22% con 7 pasos."

El razonamiento es la parte más importante de la hipótesis porque define qué aprenderás si el experimento falla. Si el cambio no mueve la métrica pero el razonamiento era sólido, tienes información valiosa sobre tu usuario.

4. Criterios de éxito: definirlos antes, no después

Antes de lanzar cualquier experimento, el equipo debe acordar en una sola reunión:

  • ¿Cuál es el umbral mínimo de mejora para declarar éxito?
  • ¿Cuál es la métrica primaria y cuáles son las métricas de guardia (las que no deben empeorar)?
  • ¿Cuánto tiempo corre el experimento antes de leer los resultados?
  • ¿Qué haremos si el resultado es neutro? ¿Y si es negativo?

Este acuerdo previo elimina el 90% de los debates post-experimento.

5. Una hipótesis por sprint, no diez

El error más común en equipos que recién adoptan una cultura de experimentación es querer lanzar muchos tests al mismo tiempo.

El problema: los recursos se dispersan, los resultados llegan todos juntos y es imposible saber qué causó qué.

La regla práctica: una hipótesis principal por sprint, dos tests de soporte como máximo. Velocidad de iteración no significa cantidad de tests simultáneos. Significa ciclos cortos con aprendizajes claros.