Marco Cynefin para startups: cómo saber si tu problema es simple, complicado o complejo
El marco Cynefin te dice qué tipo de problema tienes antes de que busques una solución: simple, complicado, complejo o caótico.
Analizar con IA — elige tu favorita
Obtén un resumen del artículo al instante
Hay founders que llevan tres semanas debatiendo en Slack qué base de datos usar para su MVP. Y hay founders que llevan tres semanas sin mirar el saldo de su cuenta porque tienen miedo de lo que van a ver.
Ambos tienen un problema. Pero no son el mismo tipo de problema. Y ese matiz lo cambia todo.
El marco Cynefin (pronunciado "ku-nev-in", del galés, significa "hábitat" o "lugar de pertenencia") es un framework de toma de decisiones desarrollado por Dave Snowden en IBM en 1999. No es nuevo. Pero en el contexto de una startup, es una de las herramientas más útiles que puedes tener para parar un segundo y preguntarte: ¿qué tipo de problema tengo delante?
Porque la respuesta correcta a un problema depende casi siempre de qué tipo de problema es. Y la mayoría de founders aplican la misma lógica a todo.
Lo que vas a aprender en este artículo:
Qué son los 4 dominios del marco Cynefin y cómo identificar en cuál está tu problema
Por qué la solución que funciona en un dominio destruye valor en otro
Cuál es la respuesta operativa correcta para cada tipo de problema en una startup
El error más común que cometen los founders (y cómo evitarlo)
Cómo usar este framework en el día a día sin convertirlo en un ejercicio teórico
Los 4 dominios del marco Cynefin: cuál es el tuyo
Cynefin distingue cinco dominios (cuatro más uno de "desorden" que por ahora dejamos aparte). Cada uno describe una relación diferente entre causa y efecto.
Simple: tienes la respuesta, solo falta ejecutar
En el dominio simple (también llamado "obvio" en versiones más recientes del framework), la relación entre causa y efecto es directa y predecible. Hay mejores prácticas establecidas. No hace falta analizar nada: solo aplicar lo que ya funciona.
Ejemplo en una startup: el proceso de onboarding de nuevos empleados. Si tu empresa tiene cinco personas y acaba de contratar a la sexta, no necesitas diseñar un proceso desde cero ni convocar una reunión de equipo para debatirlo. Necesitas documentar lo que ya hacéis (qué herramientas, qué accesos, quién hace la primera reunión, qué se espera en los primeros 30 días) y ejecutarlo cada vez.
La respuesta correcta aquí es: detectar, categorizar, responder. Aplica la mejor práctica. Si no la tienes documentada, ese es tu primer problema.
Lo que mata la eficiencia en el dominio simple es complicarlo. Cuando un founder convoca tres reuniones para decidir cómo hacer el onboarding de un nuevo developer, no está siendo riguroso. Está confundiendo dominios.
Complicado: necesitas expertise, no improvisación
En el dominio complicado, la relación entre causa y efecto existe pero no es obvia. Hay múltiples soluciones correctas. Para llegar a una buena decisión, necesitas análisis, experiencia técnica o el input de alguien que haya resuelto este problema antes.
Ejemplo en una startup: elegir el stack tecnológico para el backend de tu producto. No hay una respuesta universal. Depende del equipo que tengas, del tipo de producto, de la velocidad que necesitas, de si vas a escalar en seis meses o en tres años. Alguien sin contexto técnico no puede dar una buena respuesta. Alguien con mucha experiencia y el contexto correcto, sí.
La respuesta correcta aquí es: analizar, consultar expertise, responder. No te lances a ejecutar sin información. Pero tampoco paralices la decisión esperando la certeza absoluta.
El error frecuente es tratar un problema complicado como si fuera simple: asumir que hay una respuesta obvia y ejecutarla sin análisis. O al revés: tratarlo como si fuera complejo e iterar indefinidamente cuando lo que necesitas es traer a alguien que lo haya resuelto antes.
Complejo: no hay respuesta, hay experimentos
Aquí la relación entre causa y efecto solo se ve en retrospectiva. No existe una mejor práctica ni un experto que te dé la respuesta correcta porque el sistema es adaptativo: cambia a medida que interactúas con él.
Ejemplo en una startup: encontrar el product-market fit (el punto donde tu producto encaja de verdad con las necesidades del mercado). No hay análisis que te diga con certeza qué segmento, qué precio, qué mensaje va a funcionar. Lo que hay son hipótesis que validas o invalidas con experimentos reales. Lanzas, observas, aprendes, ajustas.
La respuesta correcta aquí es: probar, observar, responder. Diseñas experimentos pequeños, baratos y rápidos. No buscas LA respuesta: buscas señales.
"Cuando tratas un problema complejo como si fuera complicado, buscas al experto que te dé la solución. En el dominio complejo, ese experto no existe. O si dice que existe, miente."
El dominio complejo es donde la mayoría de startups viven entre los 6 y los 24 meses de vida. Y donde más daño hace la ilusión de control: el founder que diseña un plan de negocio de 40 páginas para un mercado que nadie ha testado todavía.
Caótico: primero actúa, luego analiza
En el dominio caótico no hay relación discernible entre causa y efecto. La situación está fuera de control. Aquí no funciona el análisis, no funciona la experimentación ordenada. Funciona la acción rápida para estabilizar.
Ejemplo en una startup: una crisis de caja. Descubres el viernes que el lunes no puedes pagar las nóminas. No es el momento de hacer un análisis estratégico del burn rate ni de diseñar un experimento de pricing. Es el momento de actuar: llamar a los inversores, negociar con proveedores, tomar decisiones difíciles de forma inmediata para que el caos no se extienda.
La respuesta correcta aquí es: actuar, detectar, responder. Primero estabilizas. Luego analizas. El orden importa.
El error en el dominio caótico es no actuar por miedo a tomar la decisión equivocada. En un sistema caótico, no actuar también es una decisión. Y suele ser la peor.
Por qué la solución correcta en un dominio destruye valor en otro
Este es el núcleo del framework y el motivo por el que vale la pena aprenderlo.
Aplica lógica de dominio simple a un problema complejo y vas a ejecutar con convicción hacia el lugar equivocado. Muchas startups que cierran no cierran porque les faltaba ejecución. Cierran porque ejecutaron muy bien una hipótesis que nunca se validó.
Aplica lógica de dominio complejo a un problema simple y vas a iterar eternamente sobre algo que ya tiene respuesta. Cuántas startups hemos visto debatir semanas el diseño de su política de gastos cuando lo que necesitaban era descargar una plantilla de Notion, tunearlá en 30 minutos y seguir adelante.
Aplica lógica de dominio complicado a una crisis caótica y la crisis te va a ganar mientras tú preparas el análisis.
"El problema no es que no sepas la respuesta. El problema es que no sabes en qué dominio estás mirando."
Esto tiene consecuencias operativas muy concretas:
Reuniones de equipo que no deberían existir: tomar decisiones colectivas sobre procesos que ya tienen una mejor práctica documentada es robar tiempo a cambio de nada.
Análisis infinitos sobre problemas que requieren experimentación: buscar al experto que te diga cómo encontrar PMF es una trampa. No hay experto. Hay mercado.
Parálisis ante una crisis: cuando el tejado se cae, no se hace una retrospectiva. Se pone el cubo.
La respuesta operativa correcta por dominio
Para que esto sea accionable, aquí tienes el mapa:
Dominio simple → Ejecuta. Documenta la mejor práctica. Asigna responsabilidades. Mide que se cumple. Si no tienes el proceso documentado, ese es el trabajo. Una vez que está, la decisión deja de existir: se convierte en un procedimiento.
Aplica a: onboarding de empleados, proceso de facturación, gestión de accesos y herramientas, protocolo de atención al cliente para incidencias recurrentes.
Dominio complicado → Analiza y trae expertise. Define qué información necesitas. Identifica quién tiene experiencia real en este tipo de problema (interno o externo). Establece un plazo para la decisión y un criterio de evaluación. No decidas sin información, pero tampoco esperes a tener certeza total.
Aplica a: elección de stack tecnológico, estructura legal y fiscal, estrategia de pricing, diseño de arquitectura de datos.
Dominio complejo → Experimenta. Define la hipótesis. Diseña el experimento más pequeño y barato que te permita obtener señal real. Lanza. Observa. Ajusta. No busques la respuesta: busca el patrón que emerge de los datos reales.
Aplica a: búsqueda de PMF, definición del ICP (Ideal Customer Profile, el perfil de cliente que más valor obtiene de tu producto), estrategia de go-to-market, modelo de expansión internacional.
Dominio caótico → Actúa primero, analiza después. Identifica la acción mínima necesaria para estabilizar. Ejecuta. Comunica. Cuando la situación esté bajo control, entonces analizas qué pasó y cómo evitar que vuelva a pasar.
Aplica a: crisis de caja, fallo técnico crítico en producción, pérdida de un cliente que representa el 40% del MRR, conflicto grave en el equipo fundador.
El error del founder: tratar todo como simple o todo como complejo
Cuando entramos a diagnosticar una startup, hay dos patrones que vemos repetidos.
El primero: el founder que trata todo como si fuera simple. Busca la respuesta. Quiere saber "qué hay que hacer" para crecer, para contratar bien, para encontrar clientes. Cuando alguien le dice que no hay una respuesta única, le parece una evasiva. Este founder ejecuta rápido pero frecuentemente en la dirección equivocada.
El segundo: el founder que trata todo como si fuera complejo. Todo requiere más datos, más iteraciones, más análisis. Las decisiones que tienen respuesta esperan semanas porque se han convertido en experimentos. Este founder raramente ejecuta en la dirección equivocada, pero tampoco ejecuta.
Ninguno de los dos tiene un problema de inteligencia. Tienen un problema de categorización.
El diagnóstico operativo que hacemos cuando entramos en una startup incluye, entre otras cosas, entender qué tipo de problemas tiene el equipo encima de la mesa y si los están abordando con la lógica correcta. Es sorprendente la cantidad de tiempo que se recupera solo con esta claridad.
La startup que lleva semanas decidiendo qué herramienta de gestión de proyectos usar (complicado a lo sumo, quizás simple) mientras no tiene documentado ni el proceso de cierre de ventas tiene el mapa girado.
Cómo usar Cynefin sin que se convierta en otro framework que nadie aplica
La trampa de los frameworks es que son fáciles de entender y difíciles de aplicar. Cynefin no es la excepción.
Tres reglas para que esto sea práctico:
Primera: úsalo en la puerta de entrada de cualquier problema. Antes de convocar una reunión, antes de buscar al experto, antes de diseñar el experimento, dedica dos minutos a preguntarte: ¿en qué dominio está este problema? ¿Tengo la respuesta y solo necesito ejecutar? ¿Necesito análisis y expertise externo? ¿Necesito experimentar para encontrar la señal? ¿Estoy en una crisis que requiere acción inmediata?
Dos minutos de categorización pueden ahorrar semanas de esfuerzo mal dirigido.
Segunda: acepta que un problema puede cambiar de dominio. Un problema que era complejo (encontrar PMF) puede volverse complicado (optimizar un funnel de conversión que ya funciona) a medida que la startup aprende. Los dominios no son permanentes. Reevalúa.
Tercera: cuando no sabes en qué dominio estás, empieza por experimentos pequeños. Si tienes dudas entre complicado y complejo, el coste de equivocarte hacia el lado complejo (diseñar un experimento) es menor que el de equivocarte hacia el lado complicado (traer al experto que te da la solución que no funciona porque el sistema era más adaptativo de lo que parecía).
Preguntas frecuentes
¿Qué es el marco Cynefin y para qué sirve en una startup?
El marco Cynefin es un framework de toma de decisiones creado por Dave Snowden que clasifica los problemas en cuatro dominios según la relación entre causa y efecto: simple, complicado, complejo y caótico. En una startup sirve para evitar aplicar la misma lógica a problemas de naturaleza distinta, lo que es una de las causas más comunes de decisiones mal ejecutadas o procesos eternamente bloqueados.
¿En qué se diferencia un problema complicado de uno complejo según Cynefin?
Un problema complicado tiene una respuesta correcta, aunque para encontrarla necesites expertise técnico o análisis previo. Un problema complejo no tiene una respuesta predefinida: la relación entre causa y efecto solo se ve en retrospectiva, y la única forma de avanzar es experimentar. Elegir una base de datos es complicado. Encontrar product-market fit es complejo.
¿Cómo sé si mi startup está en el dominio caótico o en el complejo?
La diferencia clave es el nivel de control. En el dominio complejo puedes diseñar experimentos ordenados y observar resultados con cierta calma. En el dominio caótico, el sistema está fuera de control y cualquier retraso en actuar empeora la situación. Si puedes permitirte analizar antes de actuar, no estás en el dominio caótico. Si cada hora que pasa sin acción tiene costes directos y visibles, probablemente sí.
¿Puedo aplicar Cynefin a decisiones de producto o solo a operaciones?
Cynefin aplica a cualquier tipo de decisión, incluyendo producto, estrategia, personas y operaciones. En producto, por ejemplo, las decisiones de arquitectura técnica suelen ser complicadas, mientras que las decisiones de qué funcionalidad desarrollar siguiente suelen ser complejas hasta que tienes datos de uso reales. El framework es agnóstico al área funcional.
¿Cuánto tiempo lleva aprender a usar Cynefin bien en el día a día?
El concepto se entiende en una lectura. Aplicarlo con criterio requiere práctica. En nuestra experiencia, un equipo fundador que trabaja activamente con este framework durante cuatro a seis semanas empieza a clasificar los problemas de forma casi automática antes de las reuniones. El principal obstáculo no es la curva de aprendizaje, sino el hábito de parar dos minutos a categorizar antes de actuar.
¿Existe algún recurso oficial sobre el marco Cynefin en español?
El trabajo original de Dave Snowden está en inglés. Cynefin Co, la empresa de Snowden, publica artículos y vídeos en inglés sobre el framework. En español hay contenido académico disperso, pero no existe una fuente canónica equivalente. La mejor forma de aprenderlo es combinar la lectura del paper original de Snowden con la aplicación directa a problemas reales de tu startup.
¿Cynefin reemplaza otros frameworks de toma de decisiones como OKRs o RICE?
No. Cynefin no es un sistema de priorización ni de gestión de objetivos: es una herramienta de diagnóstico que te ayuda a entender qué tipo de problema tienes antes de decidir cómo abordarlo. OKRs y RICE son herramientas de ejecución y priorización. Se complementan: primero clasificas el problema con Cynefin, luego priorizas y ejecutas con los frameworks que uses habitualmente.
La próxima vez que tu equipo lleve más de una semana sin resolver un problema, la pregunta útil no es "¿por qué tardamos tanto?". Es: "¿estamos aplicando la lógica correcta al tipo de problema que tenemos?"
A veces el problema es que nadie ha documentado el proceso. A veces es que hace falta alguien que haya estado aquí antes. A veces es que no hay respuesta sin experimentar. Y a veces es que el edificio está ardiendo y lo que hace falta no es un framework sino actuar.
Si quieres que revisemos juntos qué tipo de problemas tiene tu startup encima de la mesa y si los estáis abordando con la lógica correcta, empezamos con un diagnóstico de 1-2 semanas donde mapeamos exactamente qué funciona, qué falla y qué hay que montar. Agendar una llamada →