In partnership with

Patrocinador de hoy:

Gracias a este patrocinio, podemos seguir enviándote contenido gratuito cada día.

Solo con hacer clic aquí ya estás apoyando muchísimo a The Startup Eye.
No tienes que pagar nada. Solo haces CLIC y listo.

Introducing the first AI-native CRM

Connect your email, and you’ll instantly get a CRM with enriched customer insights and a platform that grows with your business.

With AI at the core, Attio lets you:

• Prospect and route leads with research agents

• Get real-time insights during customer calls

• Build powerful automations for your complex workflows

Join industry leaders like Granola, Taskrabbit, Flatfile and more.

👉Try Attio Pro for free

La confusión habitual: complejidad ≠ sofisticación

Kaufman hace una distinción clave que merece ser entendida bien:

• Complejidad: muchas partes, muchas dependencias, muchos puntos de fallo.

• Sofisticación: hacer algo difícil de forma elegante, eficiente y robusta.

El problema es que muchas startups construyen complejidad creyendo que están construyendo sofisticación.

Dashboards con 40 métricas.
Flujos de onboarding con 12 pasos.
Arquitecturas técnicas pensadas para “cuando escalemos”.
Automatizaciones que nadie entiende, ni siquiera quien las creó.

Nada de eso es sofisticado.
Es simplemente frágil.

La Ley de Gall no dice que la complejidad sea mala. Dice algo más incómodo:

Por qué diseñar sistemas complejos desde cero falla

Kaufman es claro en esto:
los sistemas complejos diseñados “en papel” rara vez sobreviven al contacto con la realidad.

¿Por qué?

1. No puedes predecir todas las interacciones
   Cada nueva pieza interactúa con las demás. El número de combinaciones crece de forma no lineal.

2. Aumentan los puntos de fallo
   Cuando algo se rompe, es más difícil saber qué, por qué y cómo arreglarlo.

3. El coste cognitivo se dispara
   Equipos pequeños gastan más energía entendiendo el sistema que creando valor.

4. La iteración se vuelve lenta
   Cambiar una cosa implica tocar cinco más. La velocidad desaparece.

Esto no es teoría.
Es exactamente lo que ocurre cuando una startup intenta “hacerlo bien desde el principio”.

Sistemas simples que funcionan > sistemas complejos perfectos

Aquí está la parte clave del capítulo.

Kaufman insiste en que un sistema simple que funciona siempre es superior a un sistema complejo que aún no ha demostrado nada.

¿Por qué?

Porque un sistema simple:

• es más fácil de entender

• es más fácil de depurar

• es más fácil de mejorar

• y, sobre todo, es más fácil de adaptar cuando la realidad cambia

La realidad siempre cambia.

Y aquí entra el matiz importante:
simple no significa cutre.
Significa reducir el sistema a lo estrictamente necesario para que cumpla su función.

“Haz fácil lo difícil” como principio operativo

Si tuviera que resumir el capítulo 10 en una sola frase práctica sería esta:

Eso cambia por completo el enfoque.

No preguntas:

• “¿Cómo construyo el sistema perfecto?”

Preguntas:

• “¿Cuál es la versión más simple que cumple el objetivo hoy?”

No piensas en:

• escalabilidad futura

Piensas en:

• funcionalidad presente

Y una vez eso funciona, entonces evolucionas.

El patrón que Kaufman describe (y que se repite)

Aunque Kaufman no se centra en casos mediáticos, el patrón es muy reconocible cuando miras empresas reales.

Empresas que funcionan bien suelen seguir este ciclo:

1. Empiezan con un sistema dolorosamente simple

2. Validan que ese sistema resuelve un problema real

3. Detectan cuellos de botella reales (no imaginados)

4. Añaden complejidad solo donde es estrictamente necesaria

5. Vuelven a simplificar

No es lineal.
Es iterativo.

Y aquí es donde encaja bien mencionar a Elon Musk, no como icono, sino como ingeniero de sistemas.

“Hacer barato lo caro” es aplicar la Ley de Gall

Cuando Musk habla de “hacer barato lo que tradicionalmente es caro”, no está hablando de magia.

Está aplicando exactamente lo que describe Kaufman:

• identificar qué parte del sistema genera complejidad innecesaria

• eliminarla

• y reconstruir desde principios básicos

SpaceX no empezó con el cohete perfecto.
Empezó con versiones simples que explotaban, pero que permitían aprender rápido.

Tesla no empezó con una gama completa.
Empezó con un solo modelo, caro, imperfecto y funcional.

El patrón no es ambición desmedida.
Es simplificación radical al inicio.

El error más común en startups modernas

Kaufman no habla de IA, SaaS o automatización, pero su análisis encaja perfectamente.

Hoy el error típico es este:

Eso genera:

• productos sobreingenierizados

• procesos rígidos

• equipos lentos

• y decisiones basadas en supuestos no validados

La Ley de Gall te obliga a aceptar algo incómodo:
no sabes aún qué complejidad necesitarás.

Y eso está bien.

Una pregunta incómoda (pero útil)

Si estás construyendo algo ahora mismo, pregúntate con honestidad:

• ¿Qué parte de mi producto existe solo “por si acaso”?

• ¿Qué proceso he creado para un problema que aún no tengo?

• ¿Qué complejidad estoy justificando como “profesionalidad”?

Kaufman insiste en esto:
la mayoría de sistemas no fallan por falta de inteligencia, sino por exceso de diseño prematuro.

La lección práctica del capítulo 10

Si tuviera que dejar una idea clara para llevarte hoy sería esta:

Empieza simple.
Haz que funcione.
Observa la realidad.
Añade complejidad solo cuando sea inevitable.

Eso no es ir lento.
Es ir en la dirección correcta.

La Ley de Gall no es una regla bonita para citar en presentaciones.
Es una advertencia.

Los sistemas que sobreviven no son los más inteligentes, ni los más completos.
Son los que evolucionan sin romperse.

Y eso empieza siempre igual:
haciendo fácil lo difícil.

Gracias por leer

Alek.