Un MVP es la versión más chica de tu producto que ya resuelve el problema principal de un usuario real. Se construye para aprender, no para impresionar: entra solo lo que prueba la hipótesis del negocio y espera todo lo que se pueda hacer a mano o más adelante.
¿Qué es un MVP y qué no es?
Un MVP es un producto completo pero angosto: hace una sola cosa de punta a punta y la hace bien. No es una demo, no es una maqueta y no es «la versión barata» de lo que querés construir.
La confusión más común es pensar el MVP como un producto al que le faltan partes. Un producto al que le faltan partes no se puede usar, y si no se puede usar no enseña nada. La forma correcta de recortar no es sacarle profundidad a todo, sino elegir un solo camino y hacerlo entero.
¿Cómo decido qué entra en la primera versión?
Entra lo que está en el camino crítico del usuario y prueba la hipótesis más riesgosa. Todo lo demás espera, se resuelve a mano o se saca.
Una regla que funciona: escribí la frase «esto sirve si un [tipo de usuario] logra [resultado] sin nuestra ayuda». Todo lo que no sea imprescindible para completar esa frase, queda afuera de la primera versión.
| Entra en el MVP | Puede esperar |
|---|---|
| El camino completo de la tarea principal | Los casos de excepción |
| Registro y acceso | Roles y permisos finos |
| El dato mínimo que hace falta cargar | Importaciones masivas |
| Una forma de cobrar, si el modelo es pago | Facturación automática y planes |
| Una métrica que diga si funcionó | El panel de métricas completo |
| Soporte por donde ya hablás con el cliente | Centro de ayuda y chatbot |
Si algo de la columna derecha aparece como imprescindible, casi siempre es señal de que la hipótesis todavía no está clara.
¿Cuánto tarda y cuánto cuesta un MVP?
Un MVP bien recortado se construye en semanas, no en meses. Si el plan de la primera versión pasa los tres meses, el alcance está mal recortado y conviene volver a la frase del camino crítico.
El costo depende de tres cosas y de ninguna más: cuántos caminos de usuario entran, con cuántos sistemas externos hay que hablar, y cuánta información hay que migrar. En un desarrollo a medida, el orden de magnitud lo define el primero: cada camino de usuario nuevo suele costar más que cualquier funcionalidad suelta.
La forma de que no se dispare es entregar por partes y mirar el uso real entre entrega y entrega. Un MVP que se construye entero antes de mostrarlo pierde el sentido: para cuando se ve, ya se gastó el presupuesto que servía para corregir.
¿Qué errores arruinan un MVP?
- Construirlo para el inversor y no para el usuario. Un producto lindo que nadie usa no valida nada.
- Automatizar antes de tiempo. Si diez clientes se pueden atender a mano, atendelos a mano y usá ese tiempo para aprender qué necesitan de verdad.
- Sumar una función por cada pedido. Los primeros usuarios piden lo que conocen, no lo que necesitan.
- No definir la métrica antes de empezar. Si no sabés qué número tiene que moverse, cualquier resultado se puede interpretar como éxito.
- Postergar el cobro. La única validación seria de que un producto sirve es que alguien lo pague.
¿Cómo sé que el MVP funcionó?
Cuando un usuario que no conocés completa la tarea principal y vuelve. Descargas, registros y visitas no son validación: la validación es uso repetido sin que nadie lo empuje.
Tres números alcanzan para decidir: cuántos de los que entran completan la tarea, cuántos vuelven a la semana siguiente, y cuántos pagan si el producto es pago. Con eso se sabe si conviene profundizar, corregir el rumbo o parar.
¿Qué pasa después del MVP?
Si funcionó, lo que sigue no es «agregar funciones» sino ensanchar el camino que ya se probó: soportar los casos de excepción que aparecieron, y recién después abrir un segundo camino de usuario.
Si no funcionó, el MVP hizo su trabajo: costó semanas en vez de un año, y ahora sabés algo que antes era una suposición. Ese es el punto de construirlo así.
Preguntas frecuentes
¿Cuánto tiempo lleva desarrollar un MVP?
Entre cuatro y doce semanas para un producto con un solo camino de usuario bien definido. Si el plan supera los tres meses, casi siempre es un problema de alcance y no de equipo.
¿Un MVP tiene que ser feo?
No. Tiene que ser chico, no descuidado. Un producto mal terminado genera desconfianza y ensucia el aprendizaje: no vas a saber si el usuario no volvió por la idea o por la experiencia.
¿Conviene usar no-code para el MVP?
Sirve para validar una idea sin escribir código, y para muchos casos alcanza. El límite aparece cuando hay que integrarse con sistemas propios, manejar datos sensibles o crecer en volumen: ahí el no-code se vuelve más caro que haberlo hecho a medida.
¿Quién define el alcance del MVP?
Lo define el negocio y lo acota el equipo técnico. Quien conoce el problema decide qué hipótesis hay que probar; quien construye dice cuánto cuesta cada camino y qué se puede resolver a mano en la primera versión.
¿Querés saber cuánto de esto aplica a tu empresa?
Media hora, sin compromiso. Miramos cómo trabajás hoy y te decimos qué conviene automatizar, qué no y cuánto tiempo se recupera — aunque la respuesta sea que todavía no nos necesitás.