First Principles para founders: cómo replantearte tu startup desde cero
Pensamiento de primeros principios para founders: cómo cuestionar las suposiciones de tu startup y encontrar soluciones que nadie más ve.
Analizar con IA — elige tu favorita
Obtén un resumen del artículo al instante
Tu startup tiene un problema. No sabes exactamente cuál es, pero algo no encaja. Las decisiones se acumulan, el equipo tira en direcciones distintas, y cada semana aparece una nueva herramienta, un nuevo proceso, un nuevo candidato para resolver lo que sea que está fallando.
La mayoría de founders en ese punto añaden cosas. Un CRM. Un COO. Un consultor. Una metodología. Más reuniones.
El pensamiento first principles propone lo contrario: antes de añadir nada, desmontar todo hasta quedarte con lo que es verdad. Luego construir desde ahí.
Lo que vas a aprender en este artículo:
Qué significa exactamente pensar desde primeros principios y por qué es distinto de razonar por analogía
Cómo aplicar este enfoque a decisiones operativas concretas de tu startup (herramientas, roles, procesos)
El ejercicio de los 5 porqués adaptado para diagnósticos rápidos
Cuándo first principles es la herramienta correcta y cuándo es una pérdida de tiempo
Qué es el pensamiento first principles (y qué no es)
Pensar desde primeros principios significa descomponer un problema hasta sus verdades más básicas, las que no puedes seguir cuestionando, y construir tu solución desde ahí en lugar de copiar lo que hacen otros o asumir que las cosas tienen que funcionar como siempre han funcionado.
Es lo opuesto de razonar por analogía. Razonar por analogía es decir: "las startups en mi sector usan HubSpot, así que nosotros también usamos HubSpot". O "los competidores tienen un COO, así que nosotros necesitamos un COO". Funciona cuando el contexto es idéntico al tuyo. Casi nunca lo es.
La diferencia importa porque las startups early-stage no pueden permitirse el lujo de copiar por defecto. Cada herramienta que añades tiene un coste real: tiempo de implementación, curva de aprendizaje, fricción operativa. Cada contratación que haces antes de entender el problema real es dinero que no vuelve.
"El problema no es que copies soluciones. Es que copies soluciones a problemas que no son exactamente los tuyos."
El proceso, resumido, tiene tres pasos:
Identificar el problema tal como lo has formulado
Cuestionar cada suposición implícita en esa formulación
Reformular el problema desde las verdades que quedan cuando eliminas las suposiciones
Sencillo de explicar. Difícil de ejecutar, porque las suposiciones son invisibles cuando llevas meses (o años) viviendo dentro de ellas.
Ejemplo 1: "Necesitamos un CRM"
Esta es una de las frases que más escuchamos al entrar en una startup. Y casi siempre es la formulación equivocada del problema.
Hagamos el ejercicio. La startup dice: necesitamos un CRM.
Primera pregunta: ¿por qué?
Respuesta habitual: porque perdemos leads, no sabemos en qué estado está cada conversación, el equipo comercial no tiene visibilidad de lo que hace el otro.
Segunda pregunta: ¿qué necesitas realmente?
Aquí es donde empieza el trabajo. Si descompones esa respuesta hasta sus elementos fundamentales, lo que necesitas es: saber quién es cada lead, qué ha pasado con él y cuál es el siguiente paso. Eso es todo. Eso es el primer principio.
Ahora construyes desde ahí: ¿qué herramienta resuelve exactamente eso para vuestro tamaño y volumen actual?
Para una startup en pre-seed con 5-20 leads activos y dos personas en comercial, la respuesta puede ser Notion con una base de datos básica. O una hoja de Google Sheets bien estructurada. HubSpot Free también cabe aquí si el equipo ya lo conoce, pero no porque "las startups usan HubSpot": porque resuelve el problema concreto sin coste ni complejidad añadida en esa fase.
La lógica de HubSpot starter (unos 20€/mes por usuario) tiene más sentido cuando el volumen de leads supera lo que puedes gestionar manualmente, necesitas automatizaciones de seguimiento o tienes más de tres personas tocando el pipeline. Antes de ese punto, es infraestructura que no usas.
Este es el pensamiento first principles aplicado a operaciones: no partes de "qué herramienta necesito", sino de "qué problema necesito resolver" y luego evalúas si la herramienta más sencilla posible lo resuelve.
Ejemplo 2: "Necesitamos contratar un COO"
Otro clásico. El founder está desbordado, las cosas se caen, nadie sabe quién hace qué, y la conclusión es: necesito un COO.
Vamos por partes.
¿Por qué crees que necesitas un COO?
Porque yo no puedo gestionar el producto, las ventas y las operaciones a la vez. Hay decisiones que no se toman, procesos que no existen, el equipo me necesita para todo.
¿Qué necesitas realmente?
Que los procesos funcionen sin que tú estés en el centro de cada decisión. Que haya alguien, o algo, que organice cómo fluye el trabajo.
Ese es el primer principio: necesitas que las operaciones funcionen sin dependencia constante del founder.
Ahora, ¿cuántas formas hay de resolver ese problema? Más de una.
Un COO a jornada completa es una. Es también la más cara y la que más tarda en dar resultados (un COO tarda meses en conocer la empresa lo suficiente para operar con autonomía real). Tiene sentido cuando la startup supera los 20-25 empleados, tiene un modelo de negocio validado y el caos operativo está limitando el crecimiento de forma clara.
Antes de ese punto, la solución puede ser: documentar los procesos críticos, asignar responsables claros para cada área y sistematizar las decisiones recurrentes. Eso se puede hacer en semanas, no meses. Y puede hacerlo alguien externo que entre, monte la estructura y salga, sin el coste fijo de una contratación senior.
"No necesitas un COO a jornada completa. Necesitas que alguien monte la cocina antes de que se queme el restaurante."
Esta es exactamente la distinción entre crecer y escalar. Contratar un COO cuando el problema real es que no hay procesos no resuelve el problema: lo esconde debajo de un sueldo de 80.000€ anuales.
El ejercicio de los 5 porqués adaptado a startups
Los 5 porqués es una técnica clásica de diagnóstico que Toyota popularizó en los años 70 para resolver problemas de producción. La idea es simple: ante cualquier problema, pregunta "¿por qué?" cinco veces consecutivas. Cada respuesta lleva a la causa más profunda.
El problema es que en startups muchos founders lo aplican mal: se quedan en el tercer porqué y saltan a la solución. Aquí está la versión adaptada que usamos nosotros.
Paso 1. Formula el problema como lo ves ahora.
Escríbelo en una frase. "Nuestras demos no convierten." "El equipo no cumple deadlines." "Los clientes se van al mes de activarse." Sé específico.
Paso 2. Pregunta "¿por qué?" cinco veces, esperando una respuesta real antes de seguir.
No pases al siguiente porqué con una respuesta vaga. Si dices "porque el equipo no está motivado", eso no es una causa: es otra descripción del problema. Sigue preguntando.
Paso 3. En cada respuesta, identifica si hay una suposición implícita.
Las suposiciones suelen aparecer disfrazadas de hechos. "El cliente no entiende el producto" asume que el problema es de comprensión del cliente y no de claridad del producto. "No tenemos suficiente pipeline" asume que el problema es de volumen y no de calidad o de proceso de cierre. Cuestiona cada suposición antes de continuar.
Paso 4. Cuando llegues al quinto porqué, reformula el problema original.
¿Sigue siendo el mismo problema que formulaste en el paso 1? Si la reformulación es significativamente distinta, tienes tu primer principio. Construye desde ahí.
Paso 5. Diseña la solución más simple que resuelva el problema reformulado.
No el más sofisticado. No el más escalable a largo plazo. El más simple que funcione ahora. Puedes complejizar después; primero valida que estás resolviendo el problema correcto.
Este ejercicio es la base de cualquier diagnóstico operativo serio. Cuando entramos en una startup, antes de tocar una sola herramienta o rediseñar un proceso, pasamos por algo muy parecido a esto con el founder y el equipo. El problema declarado casi nunca es el problema real.
Cuándo first principles es la herramienta correcta (y cuándo no)
First principles es poderoso en decisiones de alta incertidumbre, donde las suposiciones heredadas tienen mucho peso y la solución convencional puede no aplicar a tu contexto.
Úsalo cuando:
Estás a punto de tomar una decisión cara o difícil de revertir (contratar a alguien, cambiar de herramienta central, pivotear el modelo de negocio)
El problema lleva semanas sin resolverse a pesar de haber probado soluciones obvias
Sientes que estás copiando a tu competencia sin saber si lo que ellos hacen les funciona de verdad
El equipo está alineado en la solución pero no en el problema
No lo uses cuando:
La respuesta ya existe y es conocida. Si necesitas implementar RGPD en vuestro proceso de onboarding, no tienes que cuestionar si el RGPD es necesario. Hay un marco legal, hay una forma de cumplirlo, hay que implementarla. Analizar desde primeros principios la regulación europea de protección de datos no te va a ahorrar trabajo.
Tienes prisa y el coste de equivocarte es bajo. Si estás eligiendo en qué herramienta hacer una presentación para mañana, first principles es un sobrecoste cognitivo que no aporta nada.
El equipo ya tomó la decisión y está ejecutando. Reabrir debates cerrados con este enfoque cuando el equipo está en modo ejecución es una forma eficaz de romper el momentum sin añadir valor.
Este punto es importante porque el pensamiento first principles puede convertirse en una trampa intelectual: la excusa perfecta para seguir analizando en lugar de decidir. Las startups mueren más por parálisis que por decisiones imperfectas.
El mismo principio aplica al pensamiento de segundo orden, que trata de anticipar las consecuencias de tus decisiones antes de tomarlas. Hemos escrito sobre cómo aplicar el pensamiento de segundo orden en la toma de decisiones para founders: es un complemento natural a este enfoque, especialmente útil cuando ya sabes lo que vas a hacer y quieres evaluar qué puede salir mal.
Por qué los founders lo encuentran difícil
No es un problema de inteligencia. Es un problema de proximidad.
Cuando llevas 18 meses construyendo algo, tienes capas y capas de decisiones previas que funcionan como suposiciones no declaradas. "Vendemos así porque siempre hemos vendido así." "El equipo está organizado así porque así lo montamos al principio." "Usamos esta herramienta porque era lo que conocíamos."
Cada una de esas decisiones fue razonable en su momento. El problema es que el contexto ha cambiado y las decisiones no se han revisado. La startup tiene el doble de personas, el triple de clientes y la misma arquitectura operativa que tenía con seis empleados.
Eso es deuda operativa: cada proceso que no revisas cuando creces es una suposición que se convierte en obstáculo. Se paga con tiempo, con errores, con personas agotadas de trabajar contra sus propios sistemas.
First principles, en este contexto, no es solo una herramienta de diagnóstico. Es el hábito de revisar las suposiciones antes de que se fosilizan.
"El problema no es que tu startup tenga procesos viejos. Es que nadie los ha cuestionado desde que eran nuevos."
Cómo empezar hoy
No hace falta un retiro de dos días ni un facilitador externo. Empieza con una decisión que tengas pendiente, la que más te cuesta tomar, y aplica el ejercicio de los 5 porqués tal como lo hemos descrito.
Escribe el problema. Pregunta por qué cinco veces. Identifica las suposiciones. Reformula. Diseña la solución más simple.
Cuarenta y cinco minutos. Solo o con alguien del equipo que no haya estado involucrado en la decisión desde el principio. La distancia ayuda.
Si el resultado te dice que la solución que tenías en mente sigue siendo la correcta, al menos sabrás por qué. Si te dice que estabas a punto de resolver el problema equivocado, acabas de ahorrar semanas de trabajo y posiblemente varios miles de euros.
La pregunta no es si el pensamiento first principles funciona. Es cuántas decisiones llevas tomando desde hace meses sin haber cuestionado una sola suposición.
Si al aplicar este ejercicio descubres que el problema real son las operaciones de tu startup, y no sabes por dónde empezar a desmontarlas, eso es exactamente para lo que existe el Plan Diagnóstico Express de Ebägurin. En 1-2 semanas mapeamos qué funciona, qué falla y qué hay que montar. Sin suposiciones heredadas.
Preguntas frecuentes
¿Qué es el pensamiento first principles aplicado a una startup?
El pensamiento first principles es un método de razonamiento que consiste en descomponer un problema hasta sus verdades más básicas, las que no puedes seguir cuestionando, y construir la solución desde ahí. En el contexto de una startup, significa cuestionar las suposiciones implícitas detrás de cada decisión operativa o estratégica antes de ejecutar, en lugar de copiar lo que hace la competencia o lo que se considera el estándar del sector.
¿Cómo se aplican los 5 porqués en el diagnóstico de problemas operativos?
Los 5 porqués es una técnica de diagnóstico que consiste en preguntar "¿por qué?" cinco veces consecutivas ante cualquier problema, esperando una respuesta real antes de continuar. El objetivo es llegar a la causa raíz en lugar de tratar síntomas. En startups, la clave es identificar las suposiciones implícitas en cada respuesta y cuestionarlas antes de pasar al siguiente nivel.
¿Cuándo tiene sentido contratar un COO para una startup española?
Un COO a jornada completa tiene sentido cuando la startup supera los 20-25 empleados, tiene un modelo de negocio validado y el caos operativo está limitando claramente el crecimiento. Antes de ese punto, el problema suele ser la ausencia de procesos documentados y responsables asignados, no la falta de un perfil senior. Montar esa estructura puede hacerse en semanas con ayuda externa, sin el coste fijo de una contratación senior.
¿Cómo sé si estoy resolviendo el problema equivocado en mi startup?
Una señal clara es que llevas semanas aplicando soluciones sin que el problema desaparezca. Otra es que el equipo está alineado en la solución pero no puede articular con precisión qué problema resuelve. Si al hacer el ejercicio de los 5 porqués la reformulación del problema es significativamente distinta de la formulación original, estabas resolviendo el problema equivocado.
¿Qué diferencia hay entre pensar desde primeros principios y pensar por analogía?
Pensar por analogía significa resolver un problema basándote en cómo otros lo han resuelto en situaciones similares. Es útil cuando el contexto es idéntico al tuyo, pero en startups el contexto rara vez lo es. Pensar desde primeros principios implica ignorar las soluciones existentes y construir la tuya desde las verdades fundamentales del problema. Es más lento, pero produce decisiones más ajustadas a tu situación real.
¿Cuándo es una pérdida de tiempo aplicar first principles?
Cuando la respuesta ya existe y es conocida, cuando el coste de equivocarse es bajo y tienes prisa, o cuando el equipo ya tomó una decisión y está en modo ejecución. En esos casos, aplicar este enfoque genera fricción sin valor añadido. First principles es una herramienta para decisiones de alta incertidumbre y alto coste de reversión, no para cada micro-decisión del día a día.