Cómo definir un MVP sin desperdiciar presupuesto

Un MVP se define eligiendo un único problema, un único tipo de usuario y el recorrido más corto que lo resuelve de principio a fin, y dejando por escrito todo lo que se queda fuera. El presupuesto se desperdicia cuando «mínimo» se entiende como «barato» en vez de como «lo justo para aprender».

Esa es la respuesta corta. La larga ocupa el resto de la página, porque lo difícil de una primera versión no es construirla: es decidir qué no construir todavía. Es la conversación con la que empezamos cada proyecto de software a medida, y este es el método que seguimos.

Qué es un MVP y qué no es

El MVP, o producto mínimo viable, es la versión de un producto nuevo que permite a un equipo recoger la mayor cantidad de aprendizaje validado sobre sus clientes con el menor esfuerzo. Así lo fijó Eric Ries en 2009, y la palabra que importa es «aprendizaje»: un MVP existe para comprobar una hipótesis con usuarios reales, no para salir del paso.

Por eso no es una demo (enseña, pero no se usa), ni un prototipo clicable (no procesa datos reales), ni una beta (ya es el producto, con fallos). Tampoco es «la app completa más barata»: con el mismo alcance y menos precio, lo recortado es la calidad, y se paga después.

Dónde se desperdicia el presupuesto

El presupuesto de un MVP se escapa casi siempre por los mismos cuatro sitios, y los cuatro nacen de escribir la lista de funciones antes que la pregunta:

• Todas las funciones a la vez. La lista de lo que la aplicación «tiene que tener» crece con cada reunión y nadie ha decidido qué pregunta responde la primera versión.
• El «ya que estamos». Un panel de informes o un segundo perfil de usuario añadidos porque el equipo ya está con ello; cada uno es tiempo de desarrollo, de pruebas y de mantenimiento.
• Sin métrica. Se construye y se publica sin acordar qué dato dirá si la hipótesis se cumple. Sin ese dato, el MVP no enseña nada.
• Confundir mínimo con inacabado. Una versión que falla al registrar un pedido o que pierde datos no valida nada: los usuarios la abandonan antes de darte información.

Cómo definir el MVP en cinco pasos

El MVP se acota en cinco decisiones, en este orden, y todas se toman antes de programar.

1. Un problema y un usuario

Escribe en una frase qué problema resuelve el producto y para quién. Si la frase necesita dos «y», hay dos productos. Un programa de gestión para una clínica puede empezar por la agenda de citas, no por la agenda, la facturación y la historia clínica a la vez.

2. La hipótesis y el dato que la confirma

Una hipótesis es una afirmación que puede fallar: «los pacientes reservarán por la app en vez de llamar». El dato que la confirma se mide dentro del propio producto (el porcentaje de citas reservadas sin llamada en el primer mes) y se acuerda antes de programar, porque condiciona qué hay que registrar desde el primer día.

3. El recorrido crítico, de punta a punta

Dibuja el camino que sigue ese usuario desde que entra hasta que obtiene el resultado, y constrúyelo entero. Un recorrido completo que funciona vale más que cinco pantallas a medias. Si pasa por una pasarela de pago, la pasarela va en el MVP; si pasa por un aviso por correo, el aviso va. Lo que no está en ese camino, no va.

4. La lista de lo que se queda fuera

Es tan importante como la de lo que entra, y se guarda con fecha. Es la que evita desperdiciar presupuesto en funciones que se cuelan «ya que estamos», y le dice al cliente que no se han olvidado, solo se han ordenado.

5. El criterio de decisión, antes de construir

Qué pasa si el dato del paso 2 sale bien, regular o mal: seguir, cambiar de enfoque o parar. Si el criterio se fija antes, la decisión no depende de lo que cada uno quería que pasara.

Qué entra y qué se aplaza

El MVP lleva el recorrido crítico, un tipo de usuario y el registro del dato; casi todo lo demás se aplaza. La tabla resume el reparto en un proyecto típico.

El mínimo que las tiendas aceptan

Un MVP que es una app móvil tiene un suelo: el que marcan las tiendas. Las directrices de revisión de la App Store de Apple, en su apartado 4.2 («Minimum Functionality»), piden que la app vaya más allá de «una web reempaquetada»: una app que no sea «particularmente útil, única o app-like» no tiene sitio en la tienda, y la que no aporte una utilidad adecuada puede no ser aceptada. Un MVP móvil que sea solo la web metida en una app puede quedarse fuera antes de llegar a un usuario.

Lo que un MVP no recorta nunca

Un MVP mínimo no es un MVP descuidado. Cuatro cosas van en la primera versión aunque el presupuesto obligue a dejar fuera funciones visibles:

1. Protección de datos personales. Si el producto guarda datos de personas, el deber de información, la base jurídica y las medidas de seguridad se aplican desde el primer usuario, no desde la versión 2.0.
2. Copias de seguridad y recuperación. Un MVP que pierde los datos de sus primeros usuarios pierde la confianza que necesitaba para aprender de ellos.
3. Acceso seguro. Contraseñas guardadas con hash, sesiones con caducidad y permisos aunque solo haya un perfil.
4. Accesibilidad básica. Contraste suficiente, botones que se pulsan con el dedo y formularios con etiquetas; cuesta poco al principio y mucho al reescribir.

Después del MVP: medir y decidir

El MVP se publica con el registro del dato ya montado y con un plazo acordado para leerlo. Es el ciclo que propone Ries: construir, medir y aprender; convertir ideas en producto, medir cómo responden los clientes y decidir si se cambia de rumbo o se persevera. Lo que sube a la segunda fase es lo que el dato pide, no lo que estaba más arriba en la lista del paso 4.

Preguntas frecuentes

¿Un MVP tiene que ser feo o estar sin terminar?

No. Tiene que ser pequeño, no descuidado. El recorrido que incluye funciona de principio a fin, con un diseño que no estorbe y sin errores que hagan abandonar. Lo que se recorta son las funciones que no sirven para comprobar la hipótesis, no la calidad de las que sí entran.

¿Un MVP sirve para pedir presupuesto?

Sí, y es la forma más fiable de pedirlo. Con el recorrido crítico dibujado y la lista de lo aplazado, el presupuesto describe pantallas y conexiones concretas en vez de una lista de deseos, y dos propuestas distintas se comparan sobre el mismo alcance.

¿Qué pasa si el MVP demuestra que la idea no funciona?

Es el mejor resultado posible por el precio que ha costado. Un MVP que da un «no» claro evita construir el producto entero sobre una hipótesis falsa. Con el dato y la lista de lo aplazado, se decide si cambia el usuario, el problema o el enfoque, o si el proyecto se para.

El siguiente paso

Si tienes una idea de producto y una lista de funciones que no para de crecer, la primera reunión que proponemos es justo esta: elegir el problema, el usuario y el recorrido crítico, y dejar por escrito lo que se aplaza. Así abordamos el software a medida en Zubicode. Cuéntanos tu caso en la página de contacto.

Fuentes

• Eric Ries, «Minimum Viable Product: a guide», Startup Lessons Learned, 3 de agosto de 2009: startuplessonslearned.com.
• The Lean Startup, «Principles» (el ciclo construir, medir y aprender): theleanstartup.com/principles.
• Apple, App Store Review Guidelines, apartado 4.2 «Minimum Functionality»: developer.apple.com.