“MVP” se ha convertido en una palabra comodín que cada uno usa como le conviene. Para unos es “la versión barata”. Para otros, “la versión sin acabar”. Para el proveedor que quiere cerrar el proyecto, es “todo lo que me has pedido, pero peor”.

Ninguna de las tres es lo que significa, y confundirlas cuesta dinero.

Qué es de verdad un MVP

Un producto mínimo viable es la versión más pequeña que ya resuelve el problema entero de un usuario concreto. Las dos palabras importantes son “mínimo” y “viable”, y la mayoría de la gente solo oye la primera.

La analogía que mejor lo explica: si el problema es desplazarse, un MVP no es la rueda de un coche. Es un patinete. Feo, limitado, incómodo, pero te lleva de A a B. La rueda sola no vale para nada por muy bien hecha que esté.

Aplicado a software: si estás construyendo una app de reservas, el MVP no es “la pantalla de reservas sin el pago”. Es el ciclo completo —buscar, elegir, reservar, recibir confirmación— aunque sea para un solo tipo de negocio, sin filtros avanzados y con un panel de administración feo.

Un usuario tiene que poder resolver su problema de principio a fin. Si no, no has hecho un MVP: has hecho un trozo.

Por qué importa acertar con esto

Un alcance mal definido es la causa número uno de que un proyecto se desvíe en tiempo y presupuesto. Y se desvía en las dos direcciones:

Por exceso: construyes ocho funcionalidades, lanzas a los seis meses y descubres que los usuarios solo usan dos. Has pagado seis de más y has tardado el triple en enterarte de lo que funcionaba.

Por defecto: recortas tanto que el producto no resuelve nada, nadie lo usa, y concluyes que la idea no valía. Cuando lo que no valía era la versión.

Un método sencillo para decidir qué entra

Paso 1: escribe el recorrido completo de un usuario

Una sola frase por paso, sin tecnicismos. Por ejemplo: “María busca peluquerías cerca → elige una → ve los huecos libres → reserva → recibe confirmación → recibe recordatorio → va”.

Ese recorrido es tu columna vertebral. Todo lo que está en él es candidato a entrar. Todo lo que no, no.

Paso 2: para cada paso, pregunta “¿se puede hacer a mano?”

Esta es la pregunta que más presupuesto ahorra. Muchas cosas que parecen requerir software se pueden hacer manualmente en la primera versión, mientras tienes veinte usuarios:

  • ¿Alta de negocios? La haces tú desde la base de datos.
  • ¿Facturación? Una hoja de cálculo el primer trimestre.
  • ¿Soporte? Tu correo.
  • ¿Moderación de contenido? A ojo, tú mismo.

Automatizar procesos que todavía no sabes si vas a necesitar es la forma más cara de aprender.

Paso 3: clasifica el resto en tres cajones

Imprescindible: sin esto, el recorrido se rompe. Entra.

Importante: mejora mucho la experiencia pero el recorrido funciona sin ello. Va a la versión 1.1.

Deseable: todo lo demás. A la lista de “algún día”, que en la práctica significa “cuando los usuarios lo pidan”.

Si el cajón de “imprescindible” tiene más de siete u ocho cosas, vuelve al paso uno: probablemente estás intentando resolver dos problemas a la vez.

Lo que nunca es opcional, aunque no se vea

Hay partes que no aparecen en el recorrido del usuario y que aun así tienen que estar desde el día uno:

  • Autenticación bien hecha. Retrofitear seguridad después es rehacer.
  • Cumplimiento de RGPD. Consentimientos, borrado de datos, política de privacidad. No es opcional legalmente.
  • Analítica básica. Si lanzas sin medir, no vas a poder decidir qué construir después. Es la diferencia entre iterar y adivinar.
  • Una forma de contactar contigo. Los primeros usuarios son tu mejor fuente de información y hay que ponérselo fácil.

Recortar aquí no es hacer un MVP: es acumular deuda.

Una señal de que lo estás haciendo bien

Si al terminar de definir el alcance te da un poco de vergüenza lo pequeño que es, probablemente has acertado. Si te parece completo y redondo, casi seguro que te has pasado.

Reid Hoffman, fundador de LinkedIn, lo dijo mejor que nadie: si no te avergüenza la primera versión de tu producto, has lanzado demasiado tarde.

Cómo lo hacemos nosotros

La fase de descubrimiento existe exactamente para esto. Antes de dar un precio, dedicamos un par de semanas a convertir la idea en un recorrido concreto y a decidir qué entra en la primera versión.

Con frecuencia el resultado es un proyecto más pequeño —y por tanto más barato— que el que venía a pedir el cliente. No es generosidad: es que los proyectos pequeños se terminan y los grandes se atascan.

Estamos aplicando exactamente esto en Bipsy, nuestro producto propio, y lo contamos en abierto. Si estás definiendo el alcance de algo, escríbenos y lo miramos juntos.