Qué es un MVP y cómo saber si el tuyo lo es de verdad

Un MVP es la versión más pequeña de tu idea que sirve para averiguar si a alguien le importa. Producto mínimo viable, en inglés. Mínimo de verdad, no mínimo comparado con lo que tenías en la cabeza.

La palabra clave no es "mínimo". Es "viable": tiene que funcionar de verdad para alguien de verdad. Si no resuelve nada, no es un MVP, es una maqueta.

Y aquí está el problema. La mitad de los MVP que veo son productos completos a medio hacer. Eso no es lo mismo, y la diferencia importa mucho más de lo que parece.

¿Qué tiene que tener un MVP?

Tres cosas, y solo tres:

Una función que resuelva algo. Una. La que justifica que exista el producto. Si tu idea es una herramienta para gestionar clientes, la función es guardar clientes y verlos. No es el panel de estadísticas ni la integración con el calendario.

Alguien que la use que no seas tú. Sin esto no estás midiendo nada. Un usuario de verdad, con un problema de verdad, que la abra sin que tú estés al lado explicándole dónde hacer clic.

Una forma de saber si funciona. Que vuelvan, que paguen, que te escriban quejándose. Cualquier señal sirve mientras la puedas ver. Si no sabes qué estás midiendo, no vas a aprender nada aunque lo lances.

Lo que no aparece en esa lista: diseño bonito, registro de usuarios, panel de administración, aplicación móvil, tu logo. Nada de eso hace falta para responder la única pregunta que importa al principio.

Cómo saber si el tuyo lo es de verdad

Tres preguntas. Si fallas una, no tienes un MVP.

¿Cuánto has tardado? Si llevas más de unas semanas, probablemente estés construyendo el producto, no la prueba. El tiempo largo es el síntoma más fiable de todos.

¿Qué has quitado? Si no has tenido que renunciar a nada que te dolía, es que no has recortado. Un MVP de verdad se hace amputando, y duele. Si tu lista de funciones es la lista original entera pero "en versión sencilla", no has recortado nada.

¿Qué vas a aprender exactamente? Escribe la frase: "con esto voy a saber si...". Si no puedes terminarla, no tienes un MVP. Tienes un producto pequeño.

Esa tercera es la que más gente falla. Un MVP no existe para vender. Existe para aprender. La venta es una forma de aprender, la mejor de todas, pero el objetivo es la información.

Tres MVP que no parecen MVP

Un formulario y tú detrás. La gente pide algo por un formulario y tú lo haces a mano. No hay app, no hay automatización, no hay nada. Y aprendes exactamente lo mismo que aprenderías con la app: si alguien lo pide o no.

Una página que vende algo que no existe. Explicas el producto, pones el botón, y cuando alguien lo pulsa le dices que aún no está listo y le pides el correo. Cruel pero brutalmente informativo. Si nadie pulsa, te acabas de ahorrar tres meses.

Una hoja de cálculo compartida. Sirve para probar la lógica entera de un negocio antes de montar la herramienta. Muchas aplicaciones que hoy son productos empezaron siendo una hoja que alguien mantenía a mano.

Los tres tienen algo en común: no hay producto. Hay una pregunta contestada. Y en los tres, si la respuesta es que sí, ya construyes con la certeza de que hay alguien esperando.

El error que cometemos todos

Meter la función que hace que el producto "esté completo".

Es una tentación curiosa, porque no viene de la ambición. Viene de la vergüenza. Te da apuro enseñar algo tan simple, así que le añades una cosa más para que no parezca de juguete. Y luego otra. Y así se te van seis semanas puliendo algo que nadie ha pedido todavía.

La forma de salir de ahí es aceptar que el MVP va a dar un poco de vergüenza. Tiene que darla. Si al enseñarlo no piensas "esto está muy verde", es que has construido de más.

Lo que compensa esa vergüenza es la velocidad de la respuesta. Enseñas algo cutre en una semana y sabes en tres días si vas por buen camino. Enseñas algo pulido en dos meses y sabes lo mismo, pero has perdido siete semanas para saberlo.

Lo que un MVP no es

No es un producto malo. Mínimo no significa cutre. Lo que hace, lo tiene que hacer bien. Puedes tener una sola función y que esa función funcione perfectamente. De hecho es lo que tiene que pasar.

No es una demo. Una demo la enseñas tú. Un MVP lo usa alguien solo, en su casa, con sus datos y sus problemas. Es una diferencia enorme y es donde se aprende de verdad.

No es la versión 1 de tu plan. Si tienes una hoja de ruta con cinco fases y llamas MVP a la fase 1, estás haciendo trampas contigo mismo. El MVP no es el primer trozo del plan: es la prueba de si el plan tiene sentido.

No es gratis por obligación. Se puede cobrar por un MVP, y de hecho conviene. Que alguien pague es la señal más fuerte que existe. Preguntar "¿lo usarías?" no vale nada. Preguntar "¿me pagas veinte euros?" vale todo.

No dura para siempre. Un MVP tiene fecha de caducidad. O lo tiras porque nadie lo quiere, o lo reescribes porque sí lo quieren. Enamorarse del código del MVP es un clásico y siempre acaba mal.

Por qué ahora es más fácil y más peligroso

Con las herramientas de hoy puedes tener algo funcionando en un fin de semana. Base44 y compañía te montan una aplicación con base de datos y usuarios describiéndola en español. Eso hace veinte años era un trimestre de trabajo de un equipo.

Lo cual es maravilloso y es una trampa a la vez.

Es maravilloso porque el coste de probar una idea se ha desplomado. Puedes permitirte equivocarte diez veces en un año.

Y es una trampa porque, cuando construir es barato, construyes en lugar de preguntar. Antes te lo pensabas mucho porque montar algo dolía. Ahora montas cuatro versiones distintas en un mes y sigues sin haber hablado con un solo cliente. El proceso completo de montarlo rápido está en montar un MVP en un fin de semana con IA.

La otra trampa de la misma familia es pasarte tres semanas eligiendo con qué herramienta montarlo. De eso hablo en dejar de buscar la herramienta perfecta, que es el post que más me ha servido a mí mismo de todos los que he escrito.

Cómo montar el tuyo esta semana

Escribe la frase de una línea: "esto sirve para que alguien pueda hacer X".

Tacha todo lo que no sea X. Todo. Sin piedad, sin "pero es que sin esto no se entiende". Si duele, vas bien.

Ponle fecha límite de una semana. La fecha no es motivación, es un filtro: te obliga a decidir qué cabe y qué no, y esa decisión es exactamente el trabajo de diseñar un MVP.

Y consigue tres personas que lo usen. Tres. No treinta. Con tres personas usándolo de verdad ya vas a saber si tu idea se sostiene, y vas a saberlo con un detalle que ningún cuestionario te va a dar.

El resto del camino, desde la idea hasta la app montada sin programar, está en el hub de crear apps sin programar.

Algunos enlaces de este artículo son de afiliado: si contratas la herramienta, me llevo una comisión sin que a ti te cueste más.

Un MVP validado sin un negocio detrás se queda en un experimento simpático. Cómo convertirlo en algo que te dé de comer siendo una sola persona es lo que trabajo en Yo SA.

Ver Yo SA