Producto mínimo viable: la guía del fundador no técnico

Un producto mínimo viable no es la versión más barata que puedes lanzar. Es la más ajustada que aún demuestra si alguien va a pagar. Así decide ese alcance un fundador no técnico.

En la pizarra había 41 post-its, cada uno una funcionalidad que, según el fundador, “tenía que entrar en el MVP”: login social, dashboard, panel de administración, informes en PDF, dos idiomas. Le hicimos una pregunta que no esperaba: si solo pudieras quedarte con tres de esos post-its, ¿cuáles serían? Se quedó bloqueado, no por falta de respuesta, sino porque nadie le había pedido elegir antes. Ese es el problema real de casi todo producto mínimo viable. No es el tamaño. Es la elección.

Un producto mínimo viable (MVP, del inglés minimum viable product) es la versión más pequeña de un producto que ya permite poner a prueba la apuesta central del negocio con gente de verdad. La palabra que carga el peso de la frase no es “mínimo”. Es “viable”. Mínimo es fácil: recorta todo. Viable es difícil: significa que la versión reducida todavía tiene que demostrar algo que no sabías antes de construirla. La mayoría de los MVP falla exactamente ahí. Se hace pequeña en el eje equivocado.

Esta guía es para el fundador no técnico que va a pagar ese primer build y necesita decidir el alcance sin ser rehén de la lista de deseos de nadie. Vamos a definir bien el término, mostrar el error que esconde y darte un framework de cuatro preguntas para recortar 41 post-its hasta que quede lo que importa.

Qué es un producto mínimo viable (de verdad)

La definición más citada es la de Eric Ries, que popularizó el término en 2008: la versión de un producto nuevo que permite al equipo recoger el máximo aprendizaje validado sobre los clientes con el menor esfuerzo posible. Relee la parte del medio. La unidad de salida de un MVP no es un producto. Es aprendizaje. El producto es solo el instrumento que produce ese aprendizaje.

En la práctica, en 2026, el término se volvió sinónimo de “primera versión hecha con prisa”. Los dos sentidos parecen iguales y no lo son. Una primera versión hecha con prisa entrega software. Un MVP entrega una respuesta a una pregunta que antes no podías responder. Puedes construir las dos cosas con el mismo código y el mismo equipo. La diferencia está en qué decidiste poner a prueba antes de empezar.

Conviene despejar una confusión común de quien busca la sigla. MVP, en este contexto, es Minimum Viable Product. No es el “MVP” del deporte o de los videojuegos (Most Valuable Player), y no tiene relación con “dato mínimo viable”, una expresión que aparece suelta en las búsquedas pero que no es un concepto de producto. Cuando un inversor o un dev habla de MVP en una conversación sobre tu negocio, siempre es la versión mínima viable del producto.

El error que comete casi todo MVP

Ya defendimos en otro texto que la mayoría de los MVP no valida nada: construyen algo, sienten que avanzaron y no salen del sitio con ninguna certeza nueva. No vamos a repetir el argumento aquí. El punto operativo, el que cambia tu decisión de alcance, es este: el MVP se hace mínimo en la dimensión equivocada.

El fundador de los 41 post-its quería recortar funcionalidades hasta caber en el presupuesto. Lógico, pero insuficiente. Recortar a la mitad una lista mala te da media lista mala. La pregunta correcta no es “qué cabe en el plazo”, es “cuál es la única cosa que este build necesita demostrar”. Cuando respondes eso primero, el alcance prácticamente se dibuja solo: todo lo que no sirve a la prueba sale, por bonito que sea el post-it.

Por eso tantos MVP terminan con decenas de registros y cero aprendizaje. Pusieron a prueba si se podía construir el producto. Eso ya sabías que se podía. Lo que no sabías, y lo que el MVP existía para descubrir, era si a alguien le importa lo suficiente como para pagar.

Las cuatro preguntas que definen el alcance de tu MVP

Este es el framework que usamos con fundadores antes de escribir una línea de código. Cuatro preguntas, en orden. Cada una recorta el alcance de una manera distinta, y juntas convierten una lista de deseos en una apuesta ajustada.

1. ¿Cuál es la única cosa que tiene que ser verdad para que el negocio exista?

Todo negocio descansa sobre una hipótesis que, si es falsa, derrumba todo lo demás. Para un marketplace de servicios, es que aparecen proveedores cualificados cuando hay demanda. Para un SaaS de gestión de clínicas, es que el gestor cambia la hoja de cálculo por software si este le resuelve la parte pesada de la agenda. Escribe esa frase. Si no puedes escribirla, el MVP no tiene blanco, y ningún recorte de alcance va a arreglar eso.

La mayoría de las funcionalidades de tu lista no toca esa única cosa. Hacen el producto más completo, no la apuesta más comprobable. En la pizarra de los 41 post-its, exactamente cuatro tenían relación con la hipótesis central. Los otros 37 eran comodidad.

2. ¿Cuál es el camino más corto hasta que alguien pague?

Un registro no es validación. Un elogio no es validación. La única evidencia fuerte de que existe negocio es dinero saliendo de la cuenta de otra persona hacia la tuya, o al menos un compromiso formal de que va a salir. Así que pregunta: del estado actual hasta el primer cobro real, ¿cuál es el camino más corto? Todo lo que está en ese camino entra en el MVP. Todo lo que está fuera, espera.

Este test mata funcionalidades que parecen esenciales. El panel de administración no está en el camino del pago; al principio administras a mano. El informe en PDF no está en el camino; nadie deja de pagar por falta de PDF en la primera semana. El login social no está en el camino; correo y contraseña resuelven. Lo que queda en el camino suele ser incómodamente poco, y esa incomodidad es la señal de que acertaste con el alcance.

3. ¿Qué se puede hacer a mano antes de convertirse en código?

Buena parte de lo que parece necesitar software, al principio, es gente haciendo el trabajo que el sistema automatizará después. Eso tiene nombre: MVP concierge. Entregas el resultado manualmente, con hoja de cálculo, WhatsApp y esfuerzo humano, y solo construyes el software cuando ya demostraste que el resultado tiene valor. Es el consejo que Paul Graham resume en hacer cosas que no escalan: al principio, el trabajo manual es la estrategia, no el atajo. El clásico es la historia del fundador que vendió el producto en una landing page antes de que existiera producto, atendió los primeros pedidos personalmente y solo después escribió código.

Para el fundador no técnico, esta es la palanca más subestimada. Cada flujo que haces a mano durante unas semanas más es un flujo que no pagas por construir antes de saber si importa. Y en la atención manual aprendes cosas que ningún dashboard de analytics te cuenta. El coste es tu tiempo. El retorno es no quemar un presupuesto de desarrollo que todavía no se justifica.

4. ¿Qué te daría vergüenza mostrarle a un cliente que paga?

Aquí es donde “mínimo” se encuentra con “viable” y los dos tienen que coexistir. La versión correcta del MVP no es la más fea que puedes lanzar. Es la primera versión que te enorgullecería poner delante de alguien que va a pagar. Esas dos cosas no son opuestas. El concierge recorta la cantidad de cosas; el listón de calidad decide qué tan bien están hechas las pocas que quedaron.

Un producto puede tener una única funcionalidad y ser excelente en ella. Puede tener una sola pantalla, y esa pantalla funciona, carga rápido y no pierde datos. Mínimo es cuestión de alcance. Viable es cuestión de estándar. Cuando el fundador usa “MVP” como excusa para entregar algo roto, no está siendo austero, está saboteando su propio test: el cliente que rechaza un producto mal acabado no te enseñó que la idea es mala, te enseñó que el acabado era malo. Gastaste el tiro y no mediste nada.

Qué es un MVP: los ejemplos famosos y lo que de verdad enseñan

Quien busca “producto mínimo viable” siempre se topa con los mismos dos casos. Vale la pena revisitarlos, porque casi todo el mundo saca de ellos la lección equivocada.

El primero es el vídeo de Dropbox. Antes de construir la sincronización de archivos, que era técnicamente difícil, el equipo grabó un vídeo de tres minutos mostrando el producto funcionando como si ya existiera. La lista de espera explotó de la noche a la mañana. La lección que repiten es “haz un vídeo”. La lección real es que fueron mínimos en el build y máximos en la apuesta: pusieron a prueba la única cosa que tenía que ser verdad, que había deseo, sin construir la parte cara.

El segundo es el de la tienda de zapatos que se convirtió en un gigante del e-commerce. El fundador, antes de montar inventario, fotografiaba zapatos en tiendas físicas, los anunciaba online y, cuando alguien compraba, iba a la tienda, pagaba el precio completo y enviaba. Perdía dinero en cada venta. No importaba. No estaba poniendo a prueba la logística, estaba poniendo a prueba si la gente compraría zapatos por internet sin probárselos. Concierge puro. La apuesta venía antes del sistema.

Los dos casos pasan el mismo test de las cuatro preguntas. Aislaron la hipótesis central, fueron por el camino más corto hasta la evidencia e hicieron a mano todo lo que se podía hacer a mano. Ninguno de los dos era un producto completo. Los dos eran viables en lo que importaba.

Cómo crear un producto mínimo viable: el paso a paso

Juntando las cuatro preguntas, la secuencia queda así, y vale tanto para quien va a contratar una software house como para quien va a avanzar con un freelancer.

Primero, escribe la hipótesis central en una frase. Si depende de un “y” para tener sentido, tienes dos hipótesis; elige la que derrumba el negocio si es falsa. Segundo, dibuja el camino más corto hasta el pago y lista solo lo que está en ese camino; ese borrador suele convertirse en el punto de partida natural de un documento de requisitos ajustado. Tercero, marca lo que se puede hacer a mano y sácalo del build. Cuarto, define el listón de calidad de lo que quedó, porque ahí es donde vive lo “viable”. Solo entonces estimas plazo y coste, y casi siempre el número sale menor de lo que la lista original sugería.

Lo que este proceso evita es el patrón más caro del mercado: pagar por construir un producto completo, lanzarlo, descubrir que nadie lo quiere y solo entonces mirar el alcance. El orden correcto es mirar el alcance primero. Es más barato discutir un post-it que reescribir un sistema.

Antes de ir al producto, conviene haber hecho los deberes de entender el problema. El MVP responde “¿alguien quiere esto?”; el discovery de producto responde “¿qué es exactamente el esto?”. Las dos etapas se refuerzan, y saltarse la primera suele ser lo que hace que el fundador llene una pizarra con 41 post-its sin saber cuál de ellos importa.

El MVP no es excusa para software desechable

Existe un mito cómodo de que el MVP es código para tirar, así que cualquier chapuza sirve. A veces es verdad, y cuando lo es, tíralo de verdad. Pero el caso más común no es ese. El caso más común es el MVP que funciona, atrae a los primeros clientes y, precisamente por eso, se convierte en la base del producto de verdad, con toda la prisa y todos los atajos incorporados. Entonces lo que iba a ser un test barato se convierte en una deuda técnica que cobra intereses durante años.

La salida no es construir todo perfecto desde el inicio; eso contradice el sentido entero del MVP. La salida es ser deliberado: ajustado en el alcance, honesto sobre qué es desechable y qué se convertirá en cimiento, y exigente con la calidad de las pocas cosas que quedaron. El software bien hecho no es un lujo de quien tiene tiempo. Es lo que separa un test que enseña de uno que solo quema caja. Hecho a medida, made to fit, incluso cuando es pequeño.

Preguntas frecuentes sobre el producto mínimo viable

¿Cuál es el producto mínimo viable de un negocio?
Es la versión más pequeña del producto que ya pone a prueba la apuesta central de la empresa con clientes reales. No es la versión más barata ni la más rápida por sí sola; es la más ajustada que aún consigue demostrar si a la gente le importa lo suficiente como para pagar. Empieza definiendo la única hipótesis que, si es falsa, derrumba el negocio, y construye solo lo que sirve para ponerla a prueba.

¿Qué es un MVP, con ejemplos?
MVP es la sigla de minimum viable product, o producto mínimo viable. El ejemplo clásico es Dropbox, que validó la demanda con un vídeo antes de construir la sincronización; otro es el e-commerce de zapatos que vendía sin inventario, comprando en tienda física pedido a pedido. En ambos, el equipo fue mínimo en lo que construyó y riguroso en lo que puso a prueba.

¿Cómo crear un producto mínimo viable?
En cuatro pasos: escribe en una frase la hipótesis que tiene que ser verdad para que el negocio exista; mapea el camino más corto hasta que alguien pague e incluye solo lo que está en ese camino; haz a mano todo lo que se pueda hacer sin código; y define un listón de calidad del que no te avergüences delante de un cliente que paga. Estima coste y plazo solo después de esos recortes.

¿Qué es un verdadero MVP?
Es el que pasa el test de lo “viable”: una versión ajustada que aún demuestra algo que no sabías, con una calidad de la que no te avergüenzas delante de un cliente que paga. Una primera versión hecha con prisa entrega software; un verdadero MVP entrega una respuesta. Si el build no fue diseñado para poner a prueba una hipótesis específica, no es un MVP, es solo un producto pequeño.

¿Qué significa “dato mínimo viable”?
No es un concepto estándar de producto, y suele ser una confusión con “producto mínimo viable”. Lo que sí existe y es útil es la idea de recoger el conjunto mínimo de evidencias que confirma o derrumba tu hipótesis. En producto, el término correcto es producto mínimo viable (MVP).

¿El MVP es lo mismo que el MVP del deporte o de los videojuegos?
No. En el contexto de negocios y software, MVP es Minimum Viable Product. En el deporte y los videojuegos, MVP es Most Valuable Player. Son siglas iguales para conceptos sin relación; cuando la conversación es sobre tu producto, siempre es la versión mínima viable.