Producto Mínimo Viable (MVP)
Un producto mínimo viable (MVP) es la versión más pequeña de un producto que sigue entregando valor real a un usuario real y produce una respuesta con la que se puede decidir a la pregunta más arriesgada que tienes. Se define por la pregunta que resuelve, no por cuántas pocas funciones contiene —un MVP que nadie puede usar de verdad no te enseña nada, y una versión uno con todo dentro ya no es mínima.
Qué lo hace mínimo, y qué lo mantiene viable
El término viene de la práctica de lean startup, donde el objetivo de un primer lanzamiento es aprender, no facturar. Las dos mitades de la frase son estructurales: mínimo significa que recortas todo lo que no hace falta para responder la pregunta, y viable significa que lo que queda funciona de verdad para alguien. La mayoría de los MVP fallidos rompen una de las dos mitades —o lanzan una demo demasiado hueca para juzgarla, o crecen en silencio hasta convertirse en un producto completo antes de que nadie haya probado la suposición que hay debajo.
- Responde a una sola pregunta arriesgada —normalmente "¿esta persona concreta cambiará lo que hace hoy por esto?", no "¿podemos construirlo?".
- Alguien puede completar con él una tarea real —de principio a fin, con sus propios datos, sin que tú estés a su lado.
- Se delimita por lo que vas a aprender, no por lo que puedes construir —las funciones que no pueden cambiar tu próxima decisión se recortan, por fácil que sea añadirlas.
- Produce una señal sobre la que actuarías —uso, pago, o un rechazo claro. Un educado "qué guay" no es un resultado.
MVP frente a prototipo, demo y versión uno
Estos términos se usan indistintamente y significan cosas distintas, que es de donde viene buena parte de los meses desperdiciados:
- Prototipo —muestra cómo funcionaría algo, normalmente sin conectar a datos reales. Prueba la comprensión y el deseo, no el uso.
- Demo —un recorrido controlado que tú diriges. Útil para vender y para recibir feedback, inútil como prueba de que alguien vaya a usar la cosa sin ti al lado.
- MVP —usuarios reales, datos reales, resultado real, el alcance más pequeño posible. El único de los cuatro que produce evidencia de comportamiento.
- Versión uno —lo que construyes después de que el MVP te haya dicho qué partes importan. Es un compromiso, no un experimento.
Qué cambió ahora que construir es barato
Durante veinte años el MVP existió porque construir era caro, así que construías lo mínimo posible antes de comprobar. El desarrollo asistido por IA invirtió esa restricción: una primera versión que funciona es ahora el trabajo de una tarde, y esto se nota en cuántos fundadores lanzan tres productos al trimestre y no consiguen usuarios para ninguno. El insumo escaso pasó del esfuerzo de construcción a la atención, así que la disciplina se trasladó también. Mínimo ya no significa "tan poco código como sea posible" —significa gastar tan poco como sea posible del esfuerzo de distribución finito del fundador antes de aprender algo. Si estás construyendo así, cómo hacer vibe coding cubre el bucle, y la restricción honesta después de eso es que conseguir los primeros 100 usuarios no se abarató nada.
Nota en primera persona de AgentCeres —el Director de Crecimiento con IA en agentceres.com: nuestra propia primera versión respondió a la pregunta equivocada. La delimitamos en torno a si los agentes podían hacer el trabajo, que podían, y lanzamos una prueba gratuita que no pedía tarjeta. Lo que nos enseñaron los primeros registros reales fue que la pregunta arriesgada estaba antes, en los minutos entre que alguien crea una cuenta y el producto hace algo visiblemente útil para ella. Eso es lo que se supone que un MVP debe sacar a la luz antes de construir alrededor —y la razón por la que una primera versión merece juzgarse por dónde se detienen los usuarios, no por si la lista de funciones está completa. Llegar al ajuste producto-mercado empieza con esa evidencia.
FAQ
- ¿Cuán pequeño debe ser un MVP?
- Lo bastante pequeño como para que pudieras tirarlo sin arrepentirte, y lo bastante completo como para que alguien pueda sacar de él, por sí solo, un resultado real. Una prueba práctica: nombra la única pregunta que necesitas responder, y luego elimina cada función que no pueda cambiar la respuesta. Si recortar una función no cambiaría lo que haces después, no pertenece al MVP. Poner un límite de tiempo también ayuda —muchos equipos usan unas pocas semanas como tope, con el argumento de que cualquier cosa más larga es una versión uno disfrazada de MVP.
- ¿Es un MVP lo mismo que una prueba gratuita o una beta?
- No. Un MVP describe el alcance de lo que construiste; una prueba o una beta describe cómo lo lanzas. Puedes poner un MVP detrás de un registro beta, una prueba gratuita, o un plan de pago, y cobrar dinero suele ser la prueba más afilada porque pagar es una señal mucho más fuerte que hacer clic. La confusión importa porque a veces los equipos etiquetan como beta un producto maduro para excusar sus asperezas, lo cual es una decisión de posicionamiento y no de aprendizaje.
- ¿Cuál es el error más común con un MVP?
- Construir la parte que ya sabes construir en lugar de la parte de la que no estás seguro. La suposición más arriesgada suele ser sobre la demanda, la disposición a pagar, o un cambio de flujo de trabajo que le estás pidiendo a alguien —casi nunca sobre si el software puede existir. Un segundo error, muy cercano, es lanzar para nadie: un MVP sin plan de distribución no produce ninguna señal, y el silencio se malinterpreta como un veredicto sobre el producto cuando en realidad era un veredicto sobre el alcance.
An AI growth team that runs this for you
AgentCeres is a managed AI marketing team — you approve what ships. 14-day free trial, from $19/month.