¿Prototipo, MVP o producto? Cómo validar una idea antes de invertir

Muchos proyectos de producto empiezan por el final: construyen la solución antes de saber si el problema existe, quién lo tiene y cuánto está dispuesto a pagar por resolverlo. Cuando llega la respuesta, el presupuesto ya se ha gastado.

Un prototipo, un MVP y un producto responden a preguntas distintas. Confundirlos es pagar por responder a la pregunta equivocada. Esta guía muestra qué construir en cada fase, un calendario de cuatro semanas para validar una idea y las señales que indican si debes avanzar o parar.

Primero el problema, después la solución

Antes de decidir qué construir, valida el problema y el proceso que lo rodea. ¿Quién tiene este problema? ¿Cómo lo resuelve hoy: con qué herramientas, con qué pasos, cuánto tiempo pierde? ¿Qué le cuesta no resolverlo?

Estas respuestas te dicen si hay un problema que merece la pena resolver y muestran por dónde tiene que pasar la solución. Una solución diseñada sin entender el proceso del cliente resuelve un problema que nadie tiene, o resuelve el correcto de la forma equivocada.

Escribe la hipótesis

Antes de escribir una línea de código, completa esta frase:

"Creo que [tipo de cliente] pagará [importe] por [solución] porque [problema]."

Si no puedes rellenar todos los huecos, todavía no estás listo para construir. Y define ya qué cuenta como éxito y qué como fracaso: qué respuesta, de cuántas personas, te haría avanzar o parar.

Prototipo, MVP o producto: qué construir en cada fase

Prototipo

• Pregunta a la que responde: "¿la gente entiende esto y lo quiere?"
• Qué tiene: pantallas clicables, una página de presentación, un vídeo corto que muestra la idea.
• Qué no tiene: backend real, autenticación, pagos.

MVP

• Pregunta a la que responde: "¿alguien lo usa y paga por ello?"
• Qué tiene: el flujo principal funcionando de verdad, solo con las funcionalidades que demuestran el valor. Por detrás, parte del trabajo puede hacerse a mano.
• Qué no tiene: nada que no haga falta para responder a la pregunta.

Producto

• Pregunta a la que responde: "¿cómo se lo ofrezco a muchos clientes de forma fiable?"
• Qué tiene: robustez, seguridad, rendimiento, pruebas, monitorización y soporte.
• Cuándo: solo después de que el MVP muestre una señal clara de demanda.

Qué es (y qué no es) un MVP

MVP significa Minimum Viable Product (producto mínimo viable), y las tres palabras cuentan:

• Minimum: lo mínimo posible para responder a una pregunta.
• Viable: funciona de verdad, no es una maqueta.
• Product: alguien puede usarlo y pagar por él.

No es un MVP:

• un Figma "interactivo" sin backend;
• una página de "próximamente" con lista de espera;
• una versión "beta" que tarda meses en salir.

Estas cosas tienen valor, pero validan interés, no un producto. Pertenecen a la fase de prototipo.

Un calendario de 4 semanas para validar

Cuatro semanas son un ritmo de trabajo, no una promesa: el objetivo es llegar a una respuesta, no a un producto terminado.

Semana 1: entrevistas. Habla con clientes potenciales sobre el problema y sobre cómo lo resuelven hoy. Sin demostraciones, solo preguntas. Sigue hasta que empieces a oír las mismas respuestas. Busca patrones, no elogios.

Semana 2: prototipo. Pantallas, una página de presentación y un vídeo corto. Todavía sin código real.

Semana 3: preventa o equivalente. Enseña el prototipo a personas que encajen en el perfil y pide un compromiso concreto: un pago anticipado, un piloto de pago, una carta de intención o una reunión con quien decide. Un sí con compromiso vale más que muchos elogios.

Semana 4: construcción mínima. Solo el flujo que necesitan las personas que se comprometieron. Hacer parte del trabajo a mano entre bastidores es aceptable en esta fase. El objetivo es entregar al primer cliente.

Señales para avanzar y señales para parar

Vas por buen camino cuando:

• hay clientes dispuestos a pagar antes de que exista el producto;
• piden funcionalidades específicas, no genéricas;
• se quejan cuando algo falla, porque ya dependen de ello.

Es momento de parar o cambiar de rumbo cuando:

• la respuesta de casi todo el mundo es "interesante, pero…";
• piden descuento antes de ver valor;
• nadie recomienda la solución a otras personas.

Parar también es un resultado. Descubrir en cuatro semanas que la idea no cuaja cuesta mucho menos que descubrirlo después de construir el producto.

Los MVP que fracasan (y por qué)

• Demasiado completos. Las ganas de "hacerlo bien" retrasan el lanzamiento hasta que el mercado ya ha cambiado.
• Construidos antes de entender el proceso. La solución no encaja en la forma de trabajar del cliente, y nadie la adopta.
• Sin plan de distribución. Se construyó, se lanzó y nadie se enteró. Hacer llegar el MVP a las personas adecuadas forma parte del MVP.
• Sin criterios de éxito y de fracaso. "Si va bien, seguimos" no es un criterio. Define antes de construir qué cuenta como señal para avanzar.

Conclusión

Construir en el orden correcto no es lento. Es la forma más rápida de llegar a algo que funciona: primero el problema y el proceso, después el prototipo, después el MVP y solo al final el producto. En cada fase, construye solo lo necesario para responder a la pregunta de esa fase.

Preguntas frecuentes

¿Cuál es la diferencia entre un prototipo y un MVP?

El prototipo comprueba si la gente entiende y quiere la idea, sin backend real. El MVP comprueba si alguien la usa y paga por ella, con el flujo principal funcionando de verdad.

¿Cuánto se tarda en validar una idea?

Depende del problema y del acceso a los clientes. El calendario de cuatro semanas de este artículo es una referencia de ritmo: entrevistas, prototipo, preventa y construcción mínima.

¿Un MVP puede tener procesos manuales por detrás?

Sí. En esta fase, hacer parte del trabajo a mano entre bastidores es una forma barata de probar el valor antes de automatizar.

¿Cuándo debo pasar de MVP a producto?

Cuando el MVP muestra una señal clara de demanda: clientes que pagan, que vuelven a usarlo y que recomiendan la solución.