Treinta días alcanzan para poner un producto real frente a usuarios reales. No alcanzan para construir todo lo que tienes en mente, y justamente de eso se trata. Una primera versión existe para descubrir si la gente quiere lo que haces, así que cada semana dedicada a funciones que nadie pidió es una semana sin esa respuesta.
Este es el plan que seguimos con productos nuevos, incluida Lyapp, la app para registrar el sueño de los bebés que publicamos en la App Store.
Por qué la mayoría de los MVP se atrasan
Los proyectos casi nunca se atrasan por un gran error. Se atrasan con un pedido razonable a la vez: una pantalla de ajustes, un segundo método de inicio de sesión, un panel de administración para después. Cada agregado parece pequeño. Juntos mueven el lanzamiento varias semanas, y el equipo todavía no aprendió nada de los usuarios.
Los MVP que se atrasan suelen tener una decisión pendiente en común: nadie escribió qué hace el producto primero, así que no hay forma de decir que no.
Escribe el trabajo principal
Antes de diseñar escribimos una frase: para quién es el producto y cuál es el trabajo que hace por esa persona. En Lyapp fue registrar el sueño y las tomas de un bebé con una mano a las 3 de la mañana. Esa frase decidió mucho. El temporizador tenía que arrancar con un toque, la pantalla principal tenía que mostrar el día de un vistazo y todo lo que necesitara dos manos podía esperar.
Deja la frase donde todo el equipo la vea. Cuando aparezca una idea nueva, compárala con la frase antes de discutir cómo construirla.
Divide la lista: lanzamiento y después
Ahora anota todo lo que el producto podría hacer y sepáralo en dos columnas. En lanzamiento queda solo lo que necesita el trabajo principal. En después queda el resto, a la vista, para que nada se sienta perdido. Las cuentas de usuario, la sincronización en la nube y las herramientas de administración suelen caer en después, y el primer día nadie las extraña.
Un plan de 30 días, semana a semana
Con el alcance definido, el mes se divide en cuatro bloques. En la práctica se solapan un poco, pero el orden importa: primero las decisiones, después las pantallas, después el código y al final los dispositivos reales.
- Semana 1: descubrimiento y una especificación escrita con la lista de lanzamiento, el flujo principal y la métrica de éxito.
- Semana 2: diseños navegables del flujo principal, revisados con dos o tres personas parecidas al usuario.
- Semana 3: construir el flujo principal de punta a punta, con datos reales, aunque los bordes estén sin pulir.
- Semana 4: probar en dispositivos reales, corregir lo que bloquea el flujo principal, publicar y configurar la analítica básica.
Qué medir después del lanzamiento
Elige un número ligado al trabajo principal. En una app de registro puede ser cuántas personas anotan algo en su segundo día. En una tienda, las compras repetidas. Las descargas y las visitas hablan del marketing; el número ligado al trabajo dice si el producto funciona.
Lanza y luego mejora
La primera versión de Lyapp llegó a la App Store el 29 de agosto. La versión 1.1 salió el 21 de septiembre con soporte para varios bebés, registro de temperatura y un temporizador que se puede pausar. Mantener pequeña la primera versión dejó espacio para planear la segunda según cómo la gente usa la app de verdad.
