FedEx Estaba Roto Hasta Que Cambiaron Una Sola Cosa: La Lección de Munger Que Todo Builder Necesita Entender

· 6 min de lectura

FedEx Estaba Roto Hasta Que Cambiaron Una Sola Cosa: La Lección de Munger Que Todo Builder Necesita Entender

Hace años, FedEx tenía un problema serio con su operación nocturna de clasificación de paquetes.

Los paquetes no llegaban a tiempo. El servicio se estaba yendo al garete. Contrataron más gente. Mejoraron los procesos. Dieron formación extra. Nada funcionó.

¿El problema real? Estaban pagando a los trabajadores por hora.

Si terminabas antes, seguías cobrando hasta que acabara el turno. Si tardabas más, también. El incentivo estaba completamente desalineado con lo que la empresa necesitaba.

Cuando cambiaron el modelo — pagando por turno completado y dejando ir a la gente a casa en cuanto terminaran todos los paquetes — el problema desapareció casi de la noche a la mañana.

No contrataron nuevos empleados. No compraron nueva tecnología. Solo cambiaron los incentivos.

Charlie Munger lo llama así de simple:

> *"Muéstrame los incentivos y te mostraré el resultado."*

---

Por Qué Esta Frase Es La Más Poderosa Que He Leído

Mira, yo vengo del mundo del código. Soy desarrollador. Mi instinto natural cuando algo no funciona es buscar el bug técnico, el proceso roto, la herramienta equivocada.

Pero Munger me enseñó que la mayoría de los problemas que parecen técnicos, operativos o de personas son en realidad problemas de incentivos mal diseñados.

Y lo peor es que son invisibles. Nadie en FedEx se despertaba pensando *"hoy voy a hacer mi trabajo mal"*. Solo respondían racionalmente a los incentivos que tenían delante.

Eso es lo flipante de este concepto: el comportamiento irracional casi siempre es completamente racional si entiendes los incentivos de la persona.

---

Cómo Los Incentivos Destruyen Productos Sin Que Nadie Se Dé Cuenta

En 2026, estoy viendo esto constantemente en el mundo de los SaaS y las herramientas digitales.

Un ejemplo clásico: el modelo freemium mal diseñado.

Muchos productos ofrecen una versión gratuita para adquirir usuarios. Suena bien en teoría. Pero si el incentivo del equipo de producto se mide por *número de usuarios registrados* y no por *usuarios que pagan*, el equipo optimiza para captar gente, no para convertirla.

Resultado: onboardings complicados que no explican el valor real. Features que no necesitas antes de ver las que sí te harían pagar. Un producto que parece diseñado para mantener a los usuarios en la versión gratuita para siempre.

Nadie tomó esa decisión conscientemente. Solo siguieron los incentivos que tenían.

La Pregunta Que Deberías Hacerte Sobre Tu Producto

¿Cuál es el comportamiento que tus métricas están incentivando realmente?

No el que crees que están incentivando. El real.

Si mides *tiempo en la app*, estás incentivando adicción, no valor. Si mides *features usadas*, estás incentivando complejidad, no claridad. Si mides *tickets de soporte cerrados*, estás incentivando velocidad de cierre, no resolución real del problema.

Esto no es teoría. Es algo que revisar esta semana.

---

El Problema Con Tus Propios Incentivos Como Builder

A ver, seré directo porque esto me pasó a mí.

Durante meses estuve construyendo features que nadie me había pedido. Me sentía productivo. Estaba en modo builder puro, shippeando cosas, viendo el repositorio crecer.

¿El problema? Mi incentivo real era *sentirme ocupado y útil*, no *resolver el problema del usuario*.

La sensación de construir es inmediata y satisfactoria. El feedback de si eso que construiste importa llega tarde y es incómodo de buscar.

Munger diría: "Claro que hacías eso. Tus incentivos personales apuntaban en esa dirección."

Cómo Lo Cambié

Dos cosas concretas que hice:

1. Cambié la métrica de mi semana. Dejé de medir *qué construí* y empecé a medir *cuántas conversaciones tuve con usuarios reales*. Si en una semana no había hablado con nadie que usara mi producto, la semana había sido mala independientemente de cuánto código hubiera escrito.

2. Me puse una regla de validación antes de construcción. Antes de empezar cualquier feature nueva, necesito identificar al menos dos usuarios que me hayan pedido algo similar. No una variante de lo que yo quiero construir. Algo que ellos hayan descrito con sus propias palabras.

Parece obvio. No lo era para mí.

---

Munger Y Los Incentivos Institucionales: La Parte Más Oscura

Hay un nivel más profundo en este concepto que Munger exploró mucho: los incentivos institucionales.

Las instituciones grandes — bancos, consultoras, grandes empresas tecnológicas — tienen sus propios sistemas de incentivos que a menudo van en contra del interés del cliente.

Un consultor que cobra por horas tiene un incentivo estructural para que los proyectos duren más. Un médico que cobra por visita tiene un incentivo para que vuelvas. Una agencia de publicidad que cobra por presupuesto gestionado tiene un incentivo para aumentar ese presupuesto.

Esto no significa que todas estas personas sean corruptas o malas. Munger era muy claro en eso: no asumas maldad donde el incentivo lo explica todo.

Pero sí significa que cuando trabajas con alguien, la primera pregunta debería ser: *¿cómo gana dinero esta persona y cómo afecta eso a lo que me recomienda?*

En el contexto español, esto es especialmente relevante al trabajar con agencias digitales, gestorías, o incluso plataformas de hosting que tienen acuerdos de afiliación con herramientas específicas.

---

Cómo Usar Este Mental Model Esta Semana

Te dejo tres ejercicios concretos:

Ejercicio 1: Audita tus métricas actuales. Coge las 3 métricas principales con las que mides el éxito de tu proyecto. Para cada una, pregúntate: *¿qué comportamiento incentiva esta métrica si la optimizo al máximo?* Si la respuesta te incomoda, la métrica está mal.

Ejercicio 2: Analiza una decisión reciente que no entendiste. Piensa en alguien (un cliente, un socio, un competidor) cuyo comportamiento te pareció irracional o contraproducente. Ahora pregúntate: *¿cuál es su incentivo real en esa situación?* Casi siempre el comportamiento tiene más sentido del que parecía.

Ejercicio 3: Diseña un incentivo, no una regla. Si quieres cambiar un comportamiento en tu vida o en tu negocio, antes de crear una nueva regla o proceso, pregúntate si puedes cambiar el incentivo subyacente. Las reglas se rompen. Los incentivos funcionan solos.

---

La Idea Que Me Quedo

Lo que más me impresiona de Munger es que este framework funciona en todos los niveles: tu comportamiento personal, tu producto, tus métricas de negocio, las instituciones con las que trabajas.

No necesitas psicología avanzada ni modelos complejos. Solo aprender a hacerte esta pregunta antes de juzgar o diseñar cualquier sistema:

*¿Cuál es el incentivo real aquí?*

FedEx no arregló a su gente. Arregló el sistema.

A veces tú tampoco necesitas cambiar tu disciplina, tu fuerza de voluntad o tus procesos.

Solo necesitas cambiar los incentivos.

---

*¿Tienes algún ejemplo propio donde los incentivos estaban desalineados y no lo veías hasta que fue obvio? Me interesa leerlo.*

Brian Mena

Brian Mena

Ingeniero informatico construyendo productos digitales rentables: SaaS, directorios y agentes de IA. Todo desde cero, todo en produccion.

LinkedIn