.png)
Principio 2 del Pragmatismo: Lo suficiente sobre lo ideal
- 28 dic 2025
- 8 Min. de lectura
El enemigo silencioso del progreso
Parte de la serie: Los 9 Principios del Pragmatismo
Son las 23:47 de un martes. Llevas 4 horas "puliendo" una presentación que mañana vas a compartir con tu equipo. Has cambiado el tipo de letra tres veces, has reordenado las diapositivas dos veces, y ahora estás debatiendo internamente si ese degradado en el fondo aporta o distrae.
A las 19:00, la presentación ya estaba lista. Tenía toda la información necesaria, las conclusiones eran claras, y cualquiera podría haber tomado decisiones con ella.
Pero tu voz interior susurró: "Podría estar mejor".
Y aquí estás, 5 horas después, agotado, frustrado y con una presentación que es un 2% mejor que la versión de las 19:00.
Este es el precio de la perfección: horas robadas a tu vida, proyectos que nunca arrancan, oportunidades que se evaporan mientras esperas el momento ideal.
La pregunta que deberías hacerte no es "¿Está perfecto?" sino "¿Es suficiente para avanzar?"
La tiranía de lo ideal
Vivimos en una cultura que glorifica la excelencia. "Si vas a hacer algo, hazlo bien", nos repiten desde niños. Y no está mal como principio general, pero el problema es que hemos confundido "hacerlo bien" con "hacerlo perfecto".
Y peor aún, hemos olvidado que:
Perfecto es enemigo de hecho.
La paradoja del perfeccionista
Los perfeccionistas no son más exitosos que los pragmáticos. De hecho, suelen serlo menos.
¿Por qué?
Porque mientras el perfeccionista está en su cueva puliendo, el pragmático ya está recibiendo feedback del mundo real, ajustando sobre la marcha y avanzando.
El perfeccionista lanza 1 proyecto perfecto cada año. El pragmático lanza 10 proyectos suficientes, aprende de 8 fracasos, perfecciona los 2 que funcionan, y acaba el año muy por delante.
La realidad premia la iteración, no la preparación.
Los 3 antipatrones de la parálisis perfeccionista
En los Antipatrones del Pragmatismo identificamos "La parálisis perfeccionista" como uno de los más destructivos. Veamos sus manifestaciones más comunes:
1. El síndrome del "Cuando tenga X, entonces..."
La escena: Quieres lanzar tu newsletter, pero primero necesitas el dominio perfecto, luego el diseño profesional, después un backlog de 10 artículos listos, luego una estrategia de crecimiento completa... Seis meses después, sigues sin enviar el primer email.
La realidad: Mientras tú esperas que todo esté "listo", alguien con un Substack básico y 3 artículos mediocres ya tiene 200 suscriptores y está aprendiendo qué funciona.
El diagnóstico: Confundes preparación con procrastinación. El mundo no premia al mejor preparado, premia al primero en ejecutar suficientemente bien.
2. La búsqueda infinita del stack perfecto
La escena: Necesitas una herramienta de gestión de proyectos. Pasas 3 semanas comparando Notion, Asana, ClickUp, Monday, Linear... Haces tablas comparativas, lees reviews, pruebas trials. Mientras tanto, tus proyectos están en un caos de emails y post-its.
La realidad: Cualquiera de esas herramientas hubiera resuelto el 80% de tu problema en el primer día. El otro 20% lo descubrirás solo usando la herramienta, no leyendo comparativas.
El diagnóstico: Estás optimizando decisiones irreversibles como si fueran reversibles. Si la decisión se puede cambiar en 5 minutos (y cambiar de herramienta lo es), no merece 3 semanas de análisis.
3. El rediseño eterno
La escena: Tu producto funciona. Los usuarios lo usan. Pero "no es elegante". Decides reescribirlo desde cero con el framework más nuevo. Seis meses después, el código nuevo todavía no hace lo que el viejo hacía en el día 1. Mientras tanto, tus competidores ya lanzaron 3 features nuevas.
La realidad: Has sacrificado valor real (nuevas funcionalidades) en el altar de la elegancia técnica que solo tú y otros 4 desarrolladores aprecian.
El diagnóstico: Confundes mejora con reconstrucción. El código legacy feo que funciona vale más que el código nuevo bonito que no existe.
La definición pragmática de "suficiente"
"Suficiente" no significa mediocre. "Suficiente" no significa chapucero. "Suficiente" no significa conformista."Suficiente" significa:
Resuelve el problema que tiene que resolver, ahora.
El test de lo suficiente: Las 4 preguntas
Antes de seguir puliendo, hazte estas 4 preguntas:
1. ¿Resuelve el problema core?
Si tu solución elimina el dolor principal del usuario, es suficiente. No importa si el botón es azul o verde. No importa si la tipografía es Helvetica o Inter. No importa si el código está refactorizado o no.
Si resuelve el problema, es suficiente. Todo lo demás es cosmética.
2. ¿Alguien lo puede usar ya?
Si la respuesta es "sí, pero habría que explicarles que...", probablemente es suficiente.
Si la respuesta es "no, todavía falta...", pregúntate: ¿Falta algo que impide el uso o falta algo que mejora la experiencia?
Lo primero es esencial. Lo segundo es opcional.
3. ¿Puedes aprender algo útil lanzándolo ahora?
Esta es la pregunta que los perfeccionistas odian:
"¿Y si lo lanzo así y descubro que nadie lo quiere?"
La respuesta pragmática: Mejor descubrirlo ahora con 10 horas invertidas que dentro de 6 meses con 500 horas invertidas.
Cada día que retienes tu solución es un día sin feedback real. Y sin feedback real, estás volando a ciegas.
4. ¿El coste de mejorarlo justifica el retraso?
Si mejorar esto un 10% te va a costar 2 semanas más, pregúntate: ¿Qué más podrías hacer con esas 2 semanas?
¿Lanzar otra feature?
¿Hacer pruebas con usuarios?
¿Empezar el siguiente proyecto?
La perfección tiene un coste de oportunidad que raramente se contabiliza.
El framework de los 3 niveles
No todo merece el mismo nivel de pulido. El pragmático sabe distribuir su energía.
Nivel 1: MVP brutal (Lo mínimo viable)
Cuándo usarlo: Cuando estás validando una hipótesis o probando algo nuevo.
Características:
Funciona lo justo para probar la idea
Puede tener bugs no críticos
La UX es básica pero usable
El código es feo pero funcional
Ejemplo real: El primer Twitter permitía enviar SMS de 140 caracteres. No tenía fotos, ni videos, ni hilos, ni retweets, solo texto y fue suficiente para validar que la gente quería microbblogging.
Regla: Si inviertes más de 1 semana en un MVP, ya no es minimal.
Nivel 2: Solución funcional (Lo suficiente)
Cuándo usarlo: Cuando sabes que funciona y quieres que otros lo usen sin fricciones mayores.
Características:
Resuelve el problema completamente
Cubre los casos de uso principales
La experiencia es fluida (no perfecta)
Está documentado lo esencial
Ejemplo real: Slack en 2014. Funcionaba perfectamente para chat en equipo, pero le faltaban videollamadas, hilos, y mil features que vinieron después. Era suficiente para que los equipos lo adoptaran.
Regla: Si no hay quejas recurrentes de usuarios, ya es suficiente. No anticipes necesidades imaginarias.
Nivel 3: Producto pulido (El ideal selectivo)
Cuándo usarlo: Cuando algo es crítico para tu marca, competitivo, o genera el 80% de tu valor.
Características:
Experiencia premium
Detalles cuidados
Casos edge cubiertos
Documentación exhaustiva
Ejemplo real: La primera experiencia de iPhone unboxing. Apple sabía que esos primeros 5 minutos definían la percepción de toda la marca. Ahí sí vale invertir en perfección.
Regla: Solo el 20% de tu trabajo debería llegar a este nivel. Elige con cirugía láser qué merece el pulido máximo.
El concepto de "Done" en modo pragmático
El perfeccionista define "done" como "no puedo mejorar esto más".
El pragmático define
Done como "esto resuelve el problema y puedo pasar a lo siguiente".
Checklist pragmático de "Done"
Algo está terminado cuando:
Cumple el objetivo principal (no todos los objetivos posibles, solo el principal)
Alguien lo puede usar sin tu ayuda (aunque tenga rough edges)
Tienes forma de medir si funciona (no necesitas métricas perfectas, solo suficientes)
No tiene bugs críticos (puede tener bugs menores, esos se arreglan después)
Estás dispuesto a mostrarlo (aunque no sea tu obra maestra)
Si cumples estos 5 puntos, está hecho, suéltalo.
Todo lo demás son adornos que puedes añadir después, si el feedback lo justifica.
El arte de iterar vs. pulir
Aquí está la trampa mental más sutil:
Los perfeccionistas piensan: "Si lanzo esto imperfecto, quedaré mal".
Los pragmáticos piensan: "Si no lanzo esto ahora, nadie aprenderá nada, incluido yo".
La diferencia está en entender que nadie ve tu versión 1 como tú la ves.
Tú ves todos los defectos porque conoces lo que podría ser. Ellos ven una solución a su problema que antes no existía.
El método de las versiones rápidas
En lugar de: → 6 meses → Versión 1.0 perfecta → Lanzamiento
Haz: → 2 semanas → v0.1 (brutal pero funcional) → Feedback → 2 semanas → v0.3 (resuelve los puntos de dolor principales) → Feedback → 2 semanas → v0.5 (ya es usable de verdad)
Al final de las 6 semanas tendrás:
3 ciclos de feedback real
3 versiones progresivamente mejores
Usuarios usando tu producto (y pagando, si aplica)
Conocimiento real de qué merece pulirse
El perfeccionista tiene un PowerPoint precioso de lo que hará.
"Pero en mi industria no se puede lanzar sin calidad"
Este es el argumento favorito de los perfeccionistas y a veces es legítimo.
Si eres cirujano, obviamente no puedes hacer una operación "suficiente". Si construyes aviones, no puedes lanzar un MVP con alas opcionales.
Pero la mayoría no trabajamos en cirugía ni aeronáutica. Trabajamos en productos, servicios, contenidos, proyectos donde el coste del error es bajo y el feedback es reversible. Y aún así, nos comportamos como si cualquier imperfección fuera catastrófica.
La pregunta definitiva
Antes de retrasar algo por "falta de calidad", pregúntate:
¿Qué es lo peor que puede pasar si lo lanzo ahora?
Si la respuesta es:
"Alguien podría quejarse" → Lánzalo y aprende de la queja
"Podría no ser perfecto" → Lánzalo, perfecto es enemigo de hecho
"Podrían pensar que soy mediocre" → Lánzalo, tu reputación se construye con entregas consistentes, no perfectas
Si la respuesta es:
"Alguien podría morir" → Ok, debes pulirlo hasta que sea seguro
"Perderíamos el negocio completo" → Ok, asegúrate bien antes
El 95% de las veces, el coste del retraso supera el coste de la imperfección.
El plan de acción: De ideal a suficiente en 7 días
Identifica dónde estás atascado por perfeccionismo:
Día 1-2: Haz una lista de proyectos que llevas más de 1 mes sin lanzar. Pregúntate: ¿Están retenidos por problemas reales o por búsqueda de lo ideal?
Día 3-4: Para cada proyecto, define: "¿Cuál es la versión mínima que resuelve el problema core?" Escríbelo en una frase.
Día 5: Elige el proyecto más importante y comprométete: "Lanzo en 7 días la versión suficiente, aunque no sea perfecta".
Día 6-7: Ejecuta esa versión suficiente. No permitas que tu cerebro te meta nuevas features "que solo tomarán 2 horitas más".
El truco mental del "Launch and Learn"
Cuando sientas la tentación de pulir, recuerda esta fórmula:
Imperfecto en el mundo > Perfecto en tu cabeza
Un producto mediocre en manos de usuarios genera aprendizaje. Un producto perfecto en tu disco duro genera ansiedad.
Conclusión: La velocidad es una feature
Los mercados, los proyectos, las oportunidades no esperan a que estés listo.
La startup con el producto "suficiente" que lanza en 2 meses tiene ventaja sobre la startup con el producto "perfecto" que lanza en 2 años.
El escritor que publica 1 artículo cada semana aprende más que el que lleva 6 meses escribiendo "el artículo definitivo".
El profesional que entrega soluciones funcionales consistentemente es más valioso que el genio que promete obras maestras que nunca llegan.
Recuerda: El pragmatismo no es conformismo, es optimización de impacto.
No se trata de hacer las cosas mal. Se trata de entender que "suficiente hoy" suele ser mejor que "perfecto nunca".
Vuelve a ese martes a las 19:00. Tu presentación está lista, es clara, es útil, es suficiente.
Cierra el portátil. Vete a casa. Duerme. Mañana tu equipo tomará decisiones igual de buenas con esa versión que con la de las 23:47. Y tú habrás recuperado 5 horas de tu vida.
Eso, amigo mío, es pragmatismo.
Siguiente paso
Este es el Principio 2 de 9. Si quieres entender por qué tus soluciones "suficientes" a veces no generan impacto, lee el Principio 1: Entregar valor sobre hacer.
Y si sientes que tu organización te castiga por lanzar "imperfecto", lee los Antipatrones del Pragmatismo para identificar las trampas culturales que te rodean.
Comentarios