Escalera de inferencia: cómo tomar decisiones basadas en datos y no en suposiciones
La escalera de inferencia explica por qué tomas decisiones basadas en lo que crees y no en lo que es real. Y cómo bajarte de ella.
Analizar con IA — elige tu favorita
Obtén un resumen del artículo al instante
Un cliente escribe para cancelar su suscripción. En el correo dice que el precio "es bastante elevado para lo que ofrece".
El founder lee el mensaje. Treinta segundos después, ya está convencido: somos caros. Hay que bajar el precio.
Esa convicción no llegó de un análisis. Llegó de un salto. Y ese salto —invisible, rapidísimo, aparentemente lógico— es lo que destruye márgenes, tuerce roadmaps y quema equipos enteros. Se llama escalera de inferencia, y en una startup ocurre docenas de veces al día.
Lo que vas a aprender en este artículo:
Qué es la escalera de inferencia y por qué es especialmente peligrosa en decisiones de startup
Cómo un solo mensaje de cliente puede llevar a una decisión que destroza tu modelo de negocio
El proceso para bajar la escalera y separar datos reales de suposiciones
Cómo aplicar este enfoque a decisiones de producto, pricing y equipo
Un ejercicio concreto para usar antes de tu próxima decisión importante
Qué es la escalera de inferencia
La escalera de inferencia es un modelo que describe cómo la mente humana salta desde un dato bruto hasta una acción sin darse cuenta de todos los pasos intermedios que ha dado. La formuló originalmente el psicólogo organizacional Chris Argyris y la popularizó Peter Senge en La Quinta Disciplina.
No es un concepto de psicología académica. Es una descripción muy precisa de algo que pasa en cualquier reunión de equipo, en cualquier revisión de métricas y en cualquier conversación entre founder y CTO.
Los peldaños de la escalera son estos, de abajo hacia arriba:
Datos observables. Todo lo que ocurrió realmente. El correo, la llamada, el número en el dashboard, lo que alguien dijo palabra por palabra.
Selección de datos. De todo lo que ocurrió, tu cerebro selecciona una parte. No todo. Una parte.
Interpretación. Le das significado a esa parte. "Esto quiere decir que..."
Suposición. Asumes que tu interpretación refleja la realidad general.
Conclusión. Llegas a una conclusión sobre el mundo o sobre el problema.
Acción. Decides algo y actúas en consecuencia.
El problema no es que este proceso exista. El problema es que ocurre en segundos y sin avisar. Cuando ya estás tomando la decisión, llevas cinco peldaños subidos y ni lo sabes.
El ejemplo que rompe startups: "somos caros"
Volvamos al founder del principio.
El dato observable es este: un cliente ha enviado un correo diciendo que el precio "es bastante elevado para lo que ofrece".
Lo que ocurre a continuación es la escalera entera, subida en treinta segundos:
Selección: el founder se queda con "precio elevado" e ignora "para lo que ofrece".
Interpretación: el cliente está insatisfecho con la relación precio-valor.
Suposición: si este cliente lo piensa, otros también. Es un problema sistémico de pricing.
Conclusión: somos caros. Tenemos que bajar precios para retener clientes.
Acción: se abre el spreadsheet de pricing y se modifica hacia abajo.
Lo que el founder no hizo: llamar al cliente.
Lo que el cliente quería decir, en realidad, era esto: llevo tres semanas intentando entender cómo usar la funcionalidad X y no tengo a nadie que me ayude. Si el producto no me resuelve el problema, no vale lo que cuesta.
El problema no era el precio. Era el onboarding y el soporte. La solución no era bajar el precio: era montar un proceso de activación que hiciera que el cliente llegara al valor del producto antes de que se frustrara.
Pero el founder ya había bajado los precios. Y con esa decisión, comprimió el margen, envió una señal al mercado de que el producto valía menos, y no resolvió el problema que tenía el cliente.
"Los datos no mienten. Pero la selección que haces de ellos, sí."
Este ejemplo no es hipotético. En varias startups con las que hemos trabajado, la primera reacción ante churn (pérdida de clientes) era revisar el pricing. Casi nunca era el pricing. Era onboarding, era soporte, era un bug que nadie había documentado, era que la propuesta de valor no estaba clara en el proceso de activación. El pricing era la punta visible de un problema más profundo que la escalera de inferencia impedía ver.
Cómo bajar la escalera: el proceso
Bajar la escalera no es un ejercicio filosófico. Es un hábito operativo. Requiere pausar, hacer tres preguntas concretas y resistir la presión de actuar rápido.
Paso 1: Identifica el dato real
La primera pregunta es la más difícil, porque obliga a ser honesto: ¿qué ocurrió exactamente?
No qué crees que ocurrió. No qué significa. Qué ocurrió.
En el ejemplo anterior: "Un cliente mandó un correo que decía exactamente esto: [texto literal]." Eso es el dato. Solo eso.
Este primer paso elimina ya la mitad del problema, porque la mayoría de las decisiones en una startup no parten de datos observables. Parten de resúmenes, interpretaciones y recuerdos de conversaciones que ya han sido filtrados por quien los narra.
Paso 2: Separa lo que sabes de lo que supones
La segunda pregunta: ¿qué sé con certeza y qué estoy asumiendo?
Haz la lista en dos columnas. Sin excusas. Sin mezclar columnas.
Lo que sé (datos) | Lo que supongo (inferencias) |
|---|---|
Un cliente dijo que el precio era elevado para lo que ofrece | Que otros clientes piensan lo mismo |
Es el segundo cliente que cancela este mes | Que el motivo de cancelación del otro también era el precio |
Nuestro MRR ha caído un 4% este mes | Que la caída se debe al pricing |
Cuando ves las dos columnas juntas, la columna de suposiciones suele ser mucho más larga que la de datos. Eso es información en sí misma.
Paso 3: Busca los datos que faltan antes de actuar
La tercera pregunta: ¿qué información necesito para confirmar o refutar mis suposiciones?
En el caso del founder: una llamada de 20 minutos con el cliente que canceló. Una encuesta de salida a los dos últimos churns. Revisar el dato de tiempo hasta primer valor (time-to-value) en los últimos 30 días. Ver si la tasa de activación ha bajado.
Esto no es análisis infinito. Es invertir una hora antes de tomar una decisión que va a afectar a toda tu estructura de precios.
"Tomar una decisión rápida con datos pobres no es agilidad. Es ruleta con consecuencias lentas."
Aplicar la escalera a tres tipos de decisiones críticas
Decisiones de producto
Escena habitual: el equipo de ventas dice que "los clientes piden X funcionalidad constantemente". El founder lo lleva al roadmap y retrasa otras tres iniciativas.
Bajando la escalera: ¿cuántos clientes lo pidieron? ¿Lo pidieron exactamente así o estaban describiendo un problema que podría tener varias soluciones? ¿Son los clientes del segmento al que queremos crecer o los que ya están en proceso de churnar? ¿Cuántos MRR representan?
"Los clientes piden X" es ya una inferencia, no un dato. El dato es: "En los últimos 30 días, 4 clientes que representan 3.200€ de MRR mencionaron dificultades para exportar informes en PDF durante las llamadas de renovación."
Eso es accionable. Lo otro es ruido que parece señal.
Decisiones de pricing
Ya hemos visto el ejemplo. Pero hay otro patrón igual de frecuente: el founder no sube precios porque "el mercado no está listo" o porque "la competencia cobra menos".
Dato real: ¿has intentado subir precios con algún cliente y te han dicho que no? ¿O estás asumiendo la respuesta antes de preguntar? ¿Sabes qué cobra exactamente la competencia o estás trabajando con información de hace seis meses que viste en su web?
En muchas startups en fase seed, el problema de pricing no es que sean caras. Es que cobran demasiado poco porque el founder subió la escalera en la dirección equivocada: "si somos baratos, habrá menos fricción para vender" es una suposición, no un dato. Y tiene costes directos: runway más corto, margen insuficiente para crecer, señal de posicionamiento equivocada.
Decisiones de equipo
Este es el más delicado, porque cuando la escalera de inferencia se aplica a personas, el daño es difícil de deshacer.
"Marcos no está rindiendo" puede ser una observación o puede ser el peldaño cinco de una escalera que empezó con "en la reunión del martes, Marcos no habló mucho".
Dato observable: ¿qué entregó Marcos en las últimas cuatro semanas? ¿Tiene objetivos claros y medibles? ¿Le has preguntado directamente si hay algo que le esté bloqueando?
Sin esas respuestas, cualquier decisión sobre Marcos —desde una conversación difícil hasta un cambio de rol— está construida sobre suposiciones. Y las suposiciones sobre personas crean profecías autocumplidas: tú actúas como si Marcos tuviera un problema, Marcos lo percibe, Marcos efectivamente empieza a tener un problema.
El ejercicio: datos reales vs. suposiciones en tu próxima decisión
Antes de tomar la próxima decisión que te parezca importante —da igual si es de producto, hiring, pricing o estructura— haz esto:
1. Escribe la decisión que vas a tomar en una frase. Ejemplo: "Vamos a contratar a una persona de soporte porque el equipo está desbordado."
2. Escribe los datos observables en los que se basa. No inferencias. No resúmenes. Hechos concretos. Ejemplo: "El tiempo medio de respuesta a tickets ha subido de 4 a 11 horas en los últimos 21 días. Hemos recibido 3 quejas directas por email sobre tiempo de respuesta. El equipo actual gestiona 47 tickets semanales."
3. Escribe las suposiciones que estás haciendo. Ejemplo: "Que el volumen de tickets va a seguir creciendo. Que el problema no tiene solución sin más personas. Que contratar es más rápido que automatizar parte del proceso."
4. Pregunta: ¿qué información adicional cambiaría mi decisión? Ejemplo: "Si descubro que el 60% de los tickets son siempre las mismas tres preguntas, podría resolverlo con una mejora de documentación o una automatización antes de contratar."
5. Consigue esa información primero.
Este ejercicio no alarga el proceso de decisión semanas. Alarga un día o dos. Y evita decisiones que se tardan meses en revertir.
Por qué esto importa más en una startup que en cualquier otro contexto
En una empresa de 500 personas, una decisión mal fundamentada tiene amortiguadores: otros niveles de gestión, más datos históricos, procesos de revisión. La escalera de inferencia hace daño, pero hay más puntos donde pararla.
En una startup de 10 personas, no hay amortiguadores. El founder sube la escalera, toma la decisión y el impacto llega directo a producto, a equipo o a cuenta corriente. Sin filtros. Sin red.
Según datos del ecosistema español, más del 70% de las startups que no superan los tres años citan "errores en la toma de decisiones" como uno de los factores determinantes, según el informe Spain Startup Ecosystem de Startupxplore. No son errores de falta de información. Son errores de confundir suposiciones con certezas.
La buena noticia: la escalera de inferencia no es un defecto de personalidad ni una señal de que no sabes gestionar. Es un mecanismo cognitivo universal. La diferencia entre founders que toman mejores decisiones con el tiempo y los que no, no es inteligencia. Es el hábito de bajar la escalera antes de actuar.
"No se trata de tener más datos. Se trata de saber cuáles datos tienes realmente y cuáles te estás inventando."
Si en tu startup las decisiones importantes se toman rápido pero luego hay que deshacerlas con más frecuencia de la que quisieras, el problema probablemente no es la velocidad. Es que se están tomando en el peldaño cinco de la escalera, no en el primero.
Si quieres revisar cómo se están tomando las decisiones en tu startup —qué datos hay realmente, qué procesos los capturan y dónde se pierden— empezamos con un diagnóstico de 1-2 semanas. Mira cómo funciona el Plan Estrategia a Medida →
Preguntas frecuentes
¿Qué es la escalera de inferencia y para qué sirve en una startup?
La escalera de inferencia es un modelo que describe cómo la mente salta desde un dato observable hasta una acción pasando por selección, interpretación, suposición y conclusión, todo en segundos y sin que seamos conscientes. En una startup sirve para identificar cuándo una decisión está basada en datos reales y cuándo está basada en suposiciones que parecen datos.
¿Cómo puedo saber si estoy tomando una decisión basada en datos o en suposiciones?
Escribe en dos columnas lo que sabes con certeza (datos observables: correos, números, conversaciones literales) y lo que estás asumiendo. Si la columna de suposiciones es más larga que la de datos, estás tomando la decisión desde un peldaño alto de la escalera. Antes de actuar, busca la información que necesitas para confirmar o refutar las suposiciones principales.
¿Por qué los founders confunden el problema del pricing con otros problemas operativos?
Porque el precio es el primer dato visible cuando un cliente cancela o se queja. Pero el churn rara vez tiene una sola causa, y el precio es frecuentemente la racionalización del cliente para un problema más profundo: falta de activación, soporte insuficiente, expectativas mal gestionadas en la venta. Sin bajar la escalera y hablar directamente con los clientes que se van, es casi imposible distinguir entre un problema de precio y un problema de valor percibido.
¿Cuánto tiempo lleva aplicar este proceso antes de una decisión?
Para decisiones operativas del día a día, entre 15 y 30 minutos: escribir el dato real, separar suposiciones, identificar qué información falta. Para decisiones de mayor impacto —hiring, pricing, cambios de roadmap— puede requerir uno o dos días de recogida de información adicional. Es una inversión pequeña comparada con el coste de revertir una decisión mal fundamentada.
¿Este enfoque ralentiza la toma de decisiones en una startup donde la velocidad importa?
La escalera de inferencia no ralentiza decisiones; elimina el coste de rehacerlas. Una startup que decide rápido pero revierte el 40% de sus decisiones no es ágil: es ruidosa. La agilidad real está en decidir con los datos correctos a la primera, no en decidir rápido con datos pobres y corregir después. Para decisiones pequeñas y reversibles, la velocidad tiene más valor. Para decisiones con impacto estructural, bajar la escalera siempre compensa.
¿Cómo afecta la escalera de inferencia a las decisiones sobre el equipo?
Es donde más daño hace, porque las consecuencias son más difíciles de revertir. Cuando una opinión sobre el rendimiento de una persona está construida sobre interpretaciones de comportamientos observados en reuniones y no sobre datos de entregables, objetivos y conversaciones directas, se toman decisiones de gestión que dañan la confianza y el rendimiento real. Antes de cualquier conversación difícil sobre rendimiento, hay que verificar que los datos en los que se basa son datos y no suposiciones acumuladas.
¿La escalera de inferencia se aplica igual en decisiones individuales y en decisiones de equipo?
La dinámica es la misma, pero en equipo el riesgo se multiplica: cada persona sube su propia escalera, y cuando se reúnen, la conversación parte de peldaños distintos. Alguien habla desde sus suposiciones, otro desde las suyas, y el debate se vuelve improductivo porque nadie ha bajado a los datos observables primero. Empezar las reuniones de decisión con "¿cuáles son exactamente los datos que tenemos?" antes de pasar a interpretaciones es uno de los cambios más simples y más efectivos que una startup puede hacer en su forma de operar.