Producto mínimo viable: qué es y cuándo construir uno

Si llevas un tiempo cerca del ecosistema emprendedor español habrás oído la expresión producto mínimo viable en cada evento, cada pitch y cada conversación de café. También habrás notado que cada persona quiere decir algo distinto con ella. Para unos es una versión recortada del producto final. Para otros es un prototipo bonito en Figma. Para bastantes, en la práctica, es “el producto entero pero con menos presupuesto”, que es justo lo contrario de lo que significa.

Esta confusión no es un problema semántico. Es la causa directa de proyectos que se alargan un año, se comen los ahorros del fundador y llegan al mercado sin haber aprendido nada que no supieran al principio. Merece la pena aclararlo bien, porque entender de verdad qué es un MVP cambia por completo cómo planteas los primeros meses de tu producto.

¿Qué es un producto mínimo viable, en una frase?

Un producto mínimo viable es la versión más pequeña de tu producto capaz de comprobar si una suposición concreta de tu negocio es cierta, puesta delante de usuarios reales. No se define por cuántas funciones tiene, sino por qué pregunta responde. Si no puedes nombrar esa pregunta, lo que estás construyendo no es un MVP.

Fíjate en lo que esa definición deja fuera. No dice nada sobre presupuesto. No dice nada sobre número de pantallas. No dice que tenga que ser feo, ni barato, ni rápido de hacer. Dice que existe una duda concreta y que el producto sirve para resolverla. Ese cambio de foco, de “qué construimos” a “qué queremos averiguar”, es todo lo que separa a un MVP de un producto pequeño.

La palabra que más se malinterpreta de las tres es “viable”. Mucha gente la lee como “que funciona más o menos”. Significa otra cosa: que es lo bastante bueno como para que alguien lo use de verdad y su reacción tenga valor informativo. Un producto que la gente abandona en treinta segundos porque va lento no te enseña si tu idea es buena. Solo te enseña que va lento.

Lo que un MVP no es

Vale la pena ser explícitos, porque la mayoría de errores caros vienen de confundir el MVP con otra cosa.

No es un prototipo. Un prototipo interactivo comprueba si la gente entiende tu producto y sabe moverse por él. Es rapidísimo y muy útil, pero nadie ha resuelto un problema real con él, así que no te dice si le importa. Son fases distintas, y la buena noticia es que la primera es barata.

No es una demo para inversores. Una demo está optimizada para impresionar en cinco minutos. Un MVP está optimizado para que alguien lo use un martes cualquiera sin nadie delante explicándoselo. Si construyes lo primero pensando que es lo segundo, acabas con una capa de barniz sobre funciones que no aguantan uso real.

No es la versión 1.0 con menos presupuesto. Este es el error más común y el más caro. Recortar un producto completo hasta que quepa en el dinero disponible no produce un MVP, produce un producto incompleto. Un MVP no es tu producto con menos, es una pregunta con la forma mínima de software que la responde.

No es necesariamente software. Muchas de las validaciones más útiles que hemos visto no tenían aplicación. Una landing con lista de espera, un proceso hecho a mano por detrás mientras el usuario cree que es automático, un grupo de WhatsApp haciendo de plataforma. Si eso responde tu pregunta, es mejor MVP que una app, porque cuesta la centésima parte. Lo desarrollamos en nuestra guía sobre cómo validar un MVP sin escribir código.

Si quieres el argumento largo sobre por qué esta palabra se ha vaciado de significado, lo escribimos aquí: MVP, la palabra más malinterpretada del sector.

Las tres preguntas que un MVP puede responder

Casi todas las dudas reales de una startup temprana caen en una de tres categorías, y cada una pide un MVP con una forma distinta.

1. ¿Existe el problema?

Es la pregunta de la demanda. ¿Le pasa esto a suficiente gente, con suficiente frecuencia, y les molesta lo bastante como para buscar solución? Es la más importante y la que menos software necesita. Aquí el MVP correcto casi nunca es una app: es hablar con clientes potenciales, una página con captación de correos, o un anuncio pequeño midiendo si alguien hace clic.

Construir una aplicación para responder esta pregunta es el error más caro que se comete en fase temprana, porque puedes contestarla por unos cientos de euros y en cambio te gastas decenas de miles. Antes de nada, habla con cinco clientes. Cinco conversaciones bien hechas cambian más planes de producto que seis meses de desarrollo.

2. ¿Mi solución resuelve el problema?

Es la pregunta de la propuesta de valor. Das por hecho que el problema existe, alguien te lo ha confirmado, y ahora quieres saber si tu forma concreta de resolverlo funciona mejor que lo que ya hace esa gente. Aquí sí suele hacer falta software, porque la única manera de saber si tu solución es mejor es que alguien la use en su día a día.

Este es el terreno natural del MVP tal como se entiende habitualmente: una aplicación acotada, con el flujo principal completo y prácticamente nada más. Sin ajustes, sin panel de administración bonito, sin las cinco funciones secundarias del plan. Solo el camino que va del problema a la solución, funcionando de verdad.

3. ¿Alguien pagará por ella?

Es la pregunta del modelo de negocio, y es distinta de las dos anteriores. Que la gente use algo gratis no significa que vaya a pagarlo. Responderla exige cobrar de verdad, aunque sea a diez personas y aunque sea poco, porque la intención declarada y el pago real no se parecen en nada.

Un MVP que valida esta pregunta necesita pasarela de pago desde el primer día, cosa que muchos fundadores posponen “para después de validar”. Si tu duda es el modelo de negocio, cobrar no es un extra: es el experimento entero.

Cómo saber si tu idea está lista para un MVP

Hay una prueba sencilla, de cuatro preguntas, y hay que poder contestarlas antes de hablar con nadie sobre desarrollo.

¿Puedes escribir tu suposición principal en una frase? Algo con la forma “creo que las gestorías pequeñas cambiarían su hoja de cálculo por una herramienta si les ahorra dos horas al mes en el IVA”. Concreta, con un sujeto identificable y algo comprobable. Si tu frase es “creo que a la gente le gustará”, no está lista.

¿Sabes cómo sería un no? Esta es la que más gente falla. Define antes de construir qué resultado te haría cambiar de rumbo. Si no existe ningún resultado posible que te lleve a abandonar la idea, no estás validando, estás buscando permiso para construir lo que ya habías decidido.

¿Tienes acceso a las personas que van a probarlo? Un MVP sin usuarios no es un experimento, es una demo cara. Antes de empezar el desarrollo deberías poder nombrar entre diez y veinte personas concretas, con nombre y apellidos, que lo van a usar. Si no las tienes, tu primer trabajo es conseguirlas, no construir.

¿Puedes vivir con el resultado? Si el dinero que vas a poner es dinero que necesitas, el riesgo no es de producto, es personal. Reduce el alcance o valida más barato antes.

Qué entra y qué se queda fuera

El recorte es la parte difícil, porque todo parece imprescindible cuando lo miras desde dentro. Una forma práctica de decidir: por cada función que quieras incluir, pregúntate si tu experimento fracasaría sin ella. No si el producto sería peor, sino si el experimento dejaría de funcionar.

Una excepción importante en España: la protección de datos no es recortable. Aunque estés en fase de experimento, si tratas datos personales te aplica el Reglamento General de Protección de Datos, con su base legal, su información al usuario y sus derechos de acceso y supresión. La Agencia Española de Protección de Datos publica guías específicas para pymes y proyectos que empiezan, y hacerlo bien desde el principio cuesta poco. Rehacerlo después cuesta mucho. Lo detallamos en nuestra guía sobre cómo cumplir el RGPD en una app española.

Cuánto cuesta y cuánto tarda, con honestidad

Un MVP bien acotado suele llevarnos entre 10 y 16 semanas desde el arranque hasta estar en manos de usuarios reales. Si el plan que te presentan supera los seis meses, la palabra “mínimo” ha dejado de aplicarse en algún punto del camino y merece la pena revisar el alcance antes de firmar.

Sobre el precio, en España hay mucho ruido. Las cifras redondas que circulan por LinkedIn rara vez corresponden a proyectos comparables, y escribimos sobre por qué la cifra de los 25.000 euros es un mito poco útil. Si lo que buscas son rangos reales por tipo de proyecto en el mercado español, están en nuestra guía de cuánto cuesta crear una app en España en 2026.

Lo que sí conviene interiorizar es esto: el coste de un MVP lo determina el alcance, y el alcance lo determina la claridad de tu pregunta. Los proyectos que se disparan de precio casi nunca se disparan por el desarrollo. Se disparan porque nadie decidió al principio qué se quería averiguar, y entonces todo parecía necesario.

Tres ejemplos de MVP bien planteado

Los ejemplos ayudan más que las definiciones, así que aquí van tres formas distintas de resolver la misma necesidad de aprender, ordenadas de más barata a más cara.

El MVP de conserje. Una startup quería automatizar la planificación de turnos en restaurantes. En lugar de construir el algoritmo, montaron un formulario y durante seis semanas hicieron los cuadrantes a mano, en una hoja de cálculo, y los enviaron por correo. El cliente recibía exactamente el resultado prometido; simplemente no lo producía una máquina. Aprendieron dos cosas que ningún desarrollo les habría dado: qué restricciones reales aparecían en la práctica y cuánto estaba dispuesto a pagar un local por quitarse ese trabajo. El software llegó después, y llegó mucho mejor informado.

El MVP de una sola pantalla. Una herramienta interna para gestorías cuyo valor entero estaba en una tabla: subir un fichero, ver los errores marcados, exportar. Sin registro, sin panel, sin ajustes. Se accedía con un enlace privado. Estuvo en manos de once despachos en cinco semanas. Cuatro de ellos preguntaron si podían pagarlo antes de que existiera un plan de precios, que es la señal más limpia que se puede pedir.

El MVP que cobraba desde el primer día. Un servicio por suscripción donde la duda no era si la gente lo usaría, eso ya estaba claro por conversaciones previas, sino si pagaría nueve euros al mes por ello. Metieron la pasarela de pago en la primera versión y quitaron todo lo demás, incluida la recuperación de contraseña, que hacían a mano por correo. La conversión a pago fue la mitad de lo previsto, ajustaron el precio y el posicionamiento, y evitaron construir un año sobre una hipótesis falsa.

Lo que comparten los tres no es el tamaño ni la tecnología. Es que en los tres casos alguien escribió antes qué quería averiguar y qué resultado le haría cambiar de idea.

Cómo saber si tu MVP ha funcionado

Un experimento sin criterio de éxito definido de antemano siempre se interpreta a favor de quien lo hizo. Por eso conviene fijar los números antes de lanzar, por incómodo que resulte.

Las métricas útiles en esta fase son pocas y casi nunca son las que se enseñan en las presentaciones. Descargas, visitas y registros no dicen nada por sí solos. Lo que informa es el comportamiento repetido y el dinero.

La última fila es la que más se ignora y la que más enseña. Un usuario que abandona y te explica por qué te está regalando la información que más te cuesta conseguir. Escríbele. Casi todos contestan, y sus respuestas suelen contener la siguiente versión del producto.

Y una advertencia sobre los números pequeños: con quince usuarios no vas a tener significación estadística, y no la necesitas. En esta fase buscas señales cualitativas fuertes, no certezas. Si de quince personas ocho vuelven solas la semana siguiente, eso significa algo. Si vuelve una, también.

Las señales de que aún no toca construir

Hay tres situaciones en las que nuestro consejo, aunque suene raro viniendo de un estudio de producto, es que no construyas todavía.

La primera es no poder nombrar la suposición. Si la conversación empieza por funciones y no por incógnitas, todavía estás diseñando un producto, no un experimento. Para eso, dos semanas de conversaciones con usuarios rinden mucho más que tres meses de desarrollo.

La segunda es no tener usuarios a mano. Construir primero y buscar usuarios después es el camino más caro posible hacia el mismo aprendizaje, y además introduce un retraso que suele coincidir con el momento en que se acaba el dinero.

La tercera es que la duda real sea la demanda. Si de verdad no sabes si alguien quiere esto, hay diez formas de averiguarlo que cuestan menos de mil euros. Úsalas todas antes de gastar treinta mil.

Por dónde empezar esta semana

Escribe tu suposición principal en una frase. Define qué resultado te haría abandonar. Haz una lista con quince personas concretas que la vayan a probar. Elige la más pequeña de las tres preguntas que necesitas responder ahora, no las tres. Y solo entonces decide si eso pide software o no.

Ese orden parece lento y es el más rápido que existe, porque evita el escenario que más veces hemos visto en España: seis meses de desarrollo, un producto correcto, y ninguna respuesta a la pregunta que de verdad importaba. Si quieres que revisemos tu suposición y te digamos con franqueza si tu idea pide un MVP o pide otra cosa más barata, cuéntanoslo en el formulario de proyecto. Decir que todavía no toca construir también forma parte del trabajo.