Existe un mito peligroso en la industria: que hay un momento ideal para lanzar un producto. Que después de suficientes rondas de diseño, suficientes tests, suficientes reuniones — el producto está listo.
No lo está. Nunca lo está. Y esperar a que lo esté es la forma más cara de equivocarse.
Lo que te enseña producción
La primera semana de un producto en manos de usuarios reales genera más señales de las que genera cualquier fase de planeación. Descubres:
- Qué pantallas nadie usa — y por qué las diseñaste con tanto cariño.
- Qué flujos la gente completa en mitad de otra cosa — y cómo hacerlos respetuosos con ese contexto.
- Qué promesa del marketing se convierte en una espera real — y cuál es lenta hasta para ti.
- Qué caso borde es, en realidad, el caso principal de un 12% de los usuarios.
Ninguna de esas cosas aparece en una junta. Aparecen cuando algo está vivo.
”Ship, don’t sing”
Hay equipos que cantan y equipos que envían. Los que cantan presentan, iteran internamente, hacen tres rondas de feedback con stakeholders. Los que envían ponen una versión fea pero honesta frente a un usuario de verdad — y después iteran.
La diferencia en la calidad final no es la que uno esperaría. El equipo que envía seis veces termina con un producto mejor que el equipo que canta seis veces, porque aprende seis veces, no una.
Enviar no es improvisar
Esto es importante: enviar temprano no significa enviar cualquier cosa. Significa enviar lo mínimo que te enseñe algo. Y hay una disciplina detrás de ese mínimo:
- Define qué aprendizaje buscas. “Quiero saber si la gente entiende el primer paso del onboarding” es un objetivo. “Quiero que funcione” no lo es.
- Recorta todo lo que no sirva a ese aprendizaje. Si el experimento es sobre onboarding, el dashboard puede ser horrible.
- Mide antes de opinar. Revisa números, no intuiciones — al menos los primeros siete días.
Con esa disciplina, “rápido” deja de ser sinónimo de “descuidado”.
Qué puedes dejar imperfecto (y qué no)
Hay cosas que sí tienen que estar bien desde la primera versión, aunque eso retrase el lanzamiento dos semanas:
- Seguridad y datos de usuario. No hay versión temprana de “perdimos tus contraseñas”.
- Pagos. Un cobro incorrecto es más caro que un retraso.
- Promesas explícitas. Si dijiste “entrega en 24 horas”, que sea verdad.
El resto — copys, animaciones, edge cases, paneles admin, documentación — puede empezar rústico y mejorar con el uso.
Una señal útil
Si al ver tu próximo sprint te das cuenta de que ninguna de las tareas se verá en producción este mes, algo está mal. Puede ser investigación necesaria. O puede ser miedo a enviar disfrazado de rigor.
La forma más honesta de saberlo es preguntarse: si hoy forzáramos un deploy con lo que hay, ¿qué pasaría?
Si la respuesta es “se rompe todo”, hay trabajo por hacer. Pero si es “funcionaría, pero no se ve bien” — ya tienes un producto. Solo falta dejar que alguien más lo use.
TL;DR — enviar temprano es una decisión estratégica, no una falta de estándares. Un producto imperfecto frente a usuarios reales te da datos que diez juntas no pueden darte. Y esos datos son los que hacen que la versión 2.0 sea buena en serio.