MVP, es decir, minimum viable product (producto mínimo viable), es la versión más pequeña de un producto que permite comprobar el supuesto más importante con usuarios reales. No se trata de una «versión barata de la aplicación», sino del camino más corto para responder a una pregunta: ¿alguien necesita esto de verdad y hará lo que usted espera?
Si ha llegado aquí desde el mundo de los videojuegos o el deporte: allí MVP significa «most valuable player», el mejor jugador. En este artículo hablamos de producto.
De dónde viene el término
La expresión apareció a principios de los años 2000 y la popularizaron Steve Blank y Eric Ries. En «The Lean Startup», Ries describe el MVP como la versión del producto que permite reunir la mayor cantidad de conocimiento validado sobre los clientes con el menor esfuerzo. Importan dos palabras: conocimiento y esfuerzo. Un MVP debe enseñar algo, no solo existir.
Qué significan las tres letras
- Minimum (mínimo) — solo lo necesario para comprobar un supuesto. Cada función añadida alarga el tiempo hasta la primera respuesta.
- Viable — el producto tiene que funcionar de verdad y aportar valor. Una maqueta que se desmorona no le dirá si la gente quiere la solución, solo que no quiere algo roto.
- Product (producto) — algo que la gente usa o por lo que paga. Una encuesta del tipo «¿lo compraría?» es una investigación, no un producto.
El error más común es quedarse solo con la primera letra. «Mínimo» sin «viable» da un producto que no demuestra nada.
Tipos de MVP
No todo MVP es una aplicación. Se empieza por la forma más barata de obtener una respuesta fiable.
Página con lista de espera (smoke test). Describe el producto como si ya existiera y mide cuántas personas dejan su correo o pulsan «comprar». Comprueba la demanda antes de escribir una sola línea de código del producto.
MVP concierge. El servicio lo presta usted a mano a los primeros clientes. Sabe enseguida por qué pagan y qué les importa, y automatiza después.
MVP «mago de Oz». El cliente ve un producto terminado, pero detrás de las cortinas parte del trabajo lo hace una persona. Comprueba si la gente usa la solución antes de construir una automatización costosa.
Producto de una sola función. Una aplicación que funciona y hace bien una cosa: por ejemplo, solo la reserva, sin programa de fidelización, chat ni informes. Es la forma más habitual cuando el supuesto es si la gente la usará con regularidad.
MVP con piezas ya hechas. Un formulario, una hoja de cálculo, una herramienta de pago y una automatización en lugar de un sistema propio. Rápido y barato, pero con límites cuando crece el tráfico.
Ejemplos conocidos
- Dropbox, antes de construir el producto completo, mostró un breve vídeo de cómo funcionaría la sincronización de archivos. La lista de interesados pasó de unos pocos a decenas de miles de personas en una sola noche. Fue una prueba de demanda, no una aplicación.
- Zappos al principio no tenía almacén. Su fundador fotografiaba zapatos en tiendas locales y, cuando llegaba un pedido, los compraba y los enviaba. Comprobaba si la gente compraría zapatos por internet.
- Airbnb empezó alquilando colchones en el piso de sus fundadores durante una conferencia en San Francisco, cuando los hoteles estaban llenos. Una web sencilla, unos pocos huéspedes, dinero real.
En los tres casos, la primera versión comprobaba un único supuesto que decidía el destino de toda la idea.
Qué no es un MVP
No es un prototipo para enseñar a inversores. Un prototipo comprueba si la solución se entiende y se puede manejar. El MVP comprueba si la gente la usa o paga por ella. Ambas cosas son útiles, pero responden a preguntas distintas.
No es una primera versión con la mitad de las funciones. Si la lista de funciones del MVP parece el plan de un año partido en dos, no es un MVP. Es un producto completo que se construye más despacio.
No es hacerlo a medias. Un alcance reducido no justifica errores, lentitud ni un almacenamiento de datos inseguro. Pocas funciones, pero bien hechas.
No es el final del trabajo. El MVP es el comienzo de un ciclo de aprendizaje. Después llegan los datos, las decisiones y las siguientes versiones.
Cómo elegir el alcance del MVP
- Anote los supuestos. Quién tiene el problema, cómo lo resuelve hoy, cuánto le cuesta, por qué le elegiría a usted.
- Elija los más arriesgados. Aquel que, si resulta falso, invalida el resto. Suele referirse a si el problema duele lo suficiente, no a si se puede resolver técnicamente.
- Defina qué considerará un éxito. De forma concreta y antes del lanzamiento: por ejemplo, «10 de las 50 personas de la lista pagan el primer mes». Sin eso, cualquier resultado puede interpretarse a favor de uno.
- Elimine todo lo demás. Inicio de sesión con cinco servicios, panel de informes, aplicación para dos sistemas: si no ayudan a comprobar ese único supuesto, pueden esperar.
Cómo llevar ese ciclo paso a paso lo explico en el tema sobre el método lean startup, y sobre cómo ordenar los supuestos en una sola hoja, en el de lean canvas.
Cuánto cuesta y cuánto tarda un MVP
Depende del tipo. Una página con lista de espera o un MVP concierge puede estar lista en unos días y costar poco. Una aplicación web que funcione, con una función principal, inicio de sesión y pagos, suele requerir varias semanas de trabajo.
Conmigo, un MVP de aplicación web con un alcance acotado cuesta 1.900–9.300 € a precio cerrado y lleva de 2 a 6 semanas. De dónde sale ese rango y cuáles son los costes ocultos, lo detallo en el artículo Coste de un MVP en 2026. Si quiere empezar, vea cómo construyo un MVP.
Preguntas frecuentes
¿Un MVP tiene que ser una aplicación? No. Si la pregunta más importante es «¿alguien lo quiere?», a menudo bastan una página, unas conversaciones y un servicio prestado a mano. Conviene construir la aplicación cuando quiere comprobar si la gente la usará con regularidad.
¿Se puede enseñar un MVP a los clientes si está «sin terminar»? Sí, siempre que lo que hace lo haga bien. Los primeros usuarios perdonan que falten funciones, pero no que falle lo básico.
¿Qué viene después del MVP? Mide lo que la gente hizo y decide: desarrollar, cambiar de rumbo o terminar. Cómo saber que el producto responde a una necesidad lo explico en el tema sobre product-market fit.