Hay un momento muy típico en los fundadores de startups en fase temprana (aunque también te lo puedes llegar a encontrar en empresas en fase de crecimiento) en el que crees que estás siendo data-driven en la toma de decisiones a la hora de validar hipótesis. Sin embargo, en vez de apoyarte en datos, acabas quedándote con los que más te interesan y, en vez de data-driven, acabas siendo sesgo-driven al caer prisionero de los sesgos.
¿Te suenan algunas de estas situaciones?
- He hablado con 15 personas y todas lo ven clarísimo
- Tenemos un piloto con un cliente grande, esto está validado ya
- El inversor X dijo que esto tiene pinta de unicornio
- La demo encantó, así que ya está
- No necesito validar nada porque el modelo de negocio es similar al de Airbnb y ya es algo que funciona
Sigues esas tesis y luego pasan dos cosas:
- El producto no despega como esperabas
- Tú te quedas con cara de «pero si lo habíamos validado»
La clave es ésta: validar no es acumular señales a favor. Validar es diseñar un proceso para encontrar la verdad, aunque ésta duela y nos acabe quitando la razón.
Y para encontrar la verdad, lo primero es detectar cuándo tu cabeza te está haciendo trampas (y aquí es donde los sesgos entran en juego).
1. El sesgo del superviviente: el sesgo que te hace copiar la estrategia equivocada (y uno de los sesgos más conocidos)
Del sesgo del superviviente ya hemos hablado en alguna ocasión en el blog a raíz de la historia de Abraham Wald y la Segunda Guerra Mundial (y también en el contexto de validación y desarrollo de clientes).

Esas zonas azules eran las zonas críticas a reforzar porque un impacto ahí era fatal dado que ningún avión había regresado con impactos ahí.
¿Cómo te engaña? Miras a los ganadores, copias su playbook y te olvidas de todos los que hicieron lo mismo y fracasaron. Un ejemplo típico sería algo como: «Notion creció así → hagamos lo mismo».
¿El problema? Notion es un outlier, es decir, un caso atípico. Lo difícil no es copiar el «cómo lo contaron», sino replicar el contexto: timing, producto, distribución, equipo, suerte y 1000 variables más.
Antídoto práctico: plantéate preguntas que te devuelvan a la realidad:
- ¿Cuántos hicieron esto y no lo lograron?
- ¿Qué pasa normalmente en tu categoría? (no en el 1% ganador)
Y si quieres ver cómo estos sesgos se disparan con hype, FOMO (fear of missing out o miedo a quedarse fuera), presión social y autoridad, solo hay que recordar la historia de Theranos y Elisabeth Holmes.

2. Sesgo de confirmación (otro de los sesgos más peligrosos en una startup)
Cómo te engaña: vas a buscar razones para decir «sí» y no razones para descubrir «no». Dicho de otra forma, te quedas con los insights, opiniones, feedback y datos que confirman tu hipótesis (descartando todo aquello que no encaja con el patrón buscado, aunque haya más “no” que “sí”).
Ejemplo típico: haces 20 entrevistas y sales contento porque 15 personas dicen «suena genial».
Pero si preguntas: «¿cuándo fue la última vez que pagaste por resolver esto?»… se hace el silencio o aparecen respuestas vagas.
Antídoto práctico: cambia hipotéticos por pasado y céntrate en comportamientos:
- Mala pregunta: «¿Pagarías por esto?»
- Buena pregunta: «¿Qué haces hoy para resolverlo? ¿Cuánto te cuesta (tiempo/dinero)?»
3. Sesgo de selección (muestra sesgada)
Cómo te engaña: hablas con gente accesible (tu red, amigos, early adopters extremos) y crees que eso representa el mercado. Tu entorno cercano no siempre es la mejor vía para validar, sobre todo si no coincide con tu buyer persona.

Ejemplo típico: tu idea se «valida» porque 10 founders como tú te dicen que lo usarían. Luego sales a vender al buyer real (CFO/ops/HR) y te das cuenta de que el problema no les importa o no lo priorizan.
Antídoto práctico:
- Define ICP antes (aunque sea imperfecto)
- Ponte cuotas por segmento
- Separa conclusiones por segmento: lo que vale para un early adopter no vale para el pragmático

Fuente: Javier Padilla
4. Efecto halo (logo, marca y cliente estratégico)
Cómo te engaña: una señal brillante (logo, advisor, sector muy atractivo…) contamina tu juicio.
Ejemplo típico: consigues un “logo bonito” y lo cuentas como tracción. Pero por debajo:
- haces una integración a medida
- vendes con condiciones especiales
- acabas dando soporte VIP
- y se convierte en algo de cero repetibilidad y escalabilidad
Así que en vez de vender un producto, haces un proyecto a medida.
Antídoto:
- Separa prestigio de comportamiento: uso real, repetición, pago/renovación
- Pregunta: ¿qué es lo que se repite? ¿O es un one-off?
Y de nuevo Theranos y Elisabeth Holmes son el recordatorio perfecto de que el halo (marca, relato, autoridad) puede sustituir a la evidencia durante demasiado tiempo.

5. Coste hundido (sunk cost)
Cómo te engaña: como ya invertiste tiempo/dinero/ego, ahora te sientes obligado a «hacer que funcione» (cueste lo que cueste).
Ejemplo típico: «ya lo hemos construido, ahora hay que venderlo». Y empiezas a añadir features para «hacerlo vendible», cuando el problema era que no era un painkiller. Hiciste una vitamina en vez de una aspirina.
Antídoto práctico: define un criterio de parada (si en 30 días no pasa X, paramos Y) y plantéate:«si hoy empezásemos de cero, ¿haríamos lo mismo?».
6. Falacia narrativa
Cómo te engaña: te enamoras del relato («si hacemos X, pasará Y») y empiezas a tratarlo como una ley física.
Ejemplo típico: “si lanzamos esto así, se viraliza”. Luego lanzas y no pasa nada. No porque “la gente no lo entienda”, sino porque la viralidad no era una propiedad del producto: era una esperanza.
Antídoto práctico:
- Cambia intención por comportamiento: “dicen que lo usarían” vs “lo usan sin que les persigas”
- Diseña experimentos que te puedan contradecir
7. Optimismo y planning fallacy
Cómo te engaña: subestimas tiempo, coste y complejidad.
Ejemplo típico: “esto en 4 semanas lo tenemos”. Sin embargo ocurre lo siguiente en la realidad:
- Semana 6: “queda poco”
- Semana 10: “salió un imprevisto”
Antídoto práctico:
- Estima por rangos y escenarios (best/base/worst)
- Pre-mortem: “¿qué tendría que pasar para tardar el doble?”
- Margen explícito (y defendido)
8. Recency bias (lo último manda)
Cómo te engaña: decides por el último input que has recibido: la última queja, el último deal, el último movimiento de un competidor…
Ejemplo típico: un cliente grande se queja alto y el roadmap cambia. La semana siguiente otro cliente se queja de otra cosa y el roadmap vuelve a cambiar. Y en 2 meses has perdido criterio, foco y velocidad.
Antídoto práctico:
- Ventanas de decisión (semanal/quincenal) con criterios estables
- Cohortes/series temporales: ¿es tendencia o caso aislado?
- Pregunta: “¿esto es frecuencia o volumen de ruido?”
9. Authority bias (sesgo de autoridad)
Cómo te engaña: si lo dice alguien «top», lo tomas como dato cuando es una opinión.
Ejemplo típico: un advisor te dice “deberíais ir a clientes enterprise”. Y tú cambias estrategia. Meses después descubres que el problema no era ventas, eran capacidades (seguridad, SLAs, soporte, procurement…).
Antídoto:
- Convierte la opinión en experimento: “¿qué tendría que ver en 2 semanas para validar esto?”
- No cambies estrategia solo por autoridad sin evidencia conductual
Cuando hay FOMO, el halo y la autoridad pesan más que la evidencia.

10. Availability bias
Cómo te engaña: sobrevaloras lo más visible/reciente, no lo más frecuente.
Ejemplo típico: diseñas el producto para el ticket más raro (edge case) porque te dolió mucho. Pero el 80% de usuarios se atasca en algo básico que no estás mirando porque esos clientes no gritan.
Antídoto:
- Base rates: ¿cuántas veces pasa de verdad?
- Segmenta por frecuencia e impacto
- Evita construir para outliers si rompen la repetibilidad
11. ¿Cómo luchar contra el autoengaño y los sesgos antes de decir “esto está validado”?
Plantéate estas preguntas para no caer en los sesgos:
- ¿Qué hipótesis estoy intentando falsear?
- ¿Qué dato me haría cambiar de opinión?
- ¿Mi muestra está sesgada hacia gente accesible o afín a mí?
- ¿Estoy midiendo intención… o comportamiento?
- ¿Estoy copiando supervivientes sin ver la distribución completa?
- ¿Qué criterio de parada tiene esto?
- ¿Estoy actuando por FOMO (miedo a quedarme fuera) más que por evidencia?
- ¿Esto es tendencia (datos) o anécdota (recency/availability)?
- ¿Estoy tomando opinión de autoridad como dato?
- Si hoy empezáramos de cero, ¿haríamos esto igual?
La validación no falla por falta de trabajo: falla por mal diseño del experimento y por sesgos.
¿Qué parte de tu “validación” es evidencia y cuál es confirmación con buena narrativa? Esto es lo que te tienes que plantear de vez en cuando para comprobar que vas por la senda adecuada.
Nos seguimos leyendo. Hasta la próxima.

Imágenes: Thirdman en Pexels, Forbes, Wikipedia, Javier Padilla y Giphy y FOMO Bar