MVP · VALIDATION · PRODUCT DISCOVERY
Publicado: 2026-10-02 · Lectura editorial
Tu MVP funciona. Eso no significa que tengas un producto validado.
Un MVP funcional demuestra que puedes construir una solución. La validación de producto requiere evidencia de que resuelve un problema, genera valor y cambia el comportamiento esperado.
Que una persona pueda registrarse, completar un flujo y obtener una respuesta demuestra que el producto funciona como software. Es una condición necesaria. No es todavía una prueba de que exista un producto validado.
La pregunta después de lanzar un MVP no es sólo si alguien puede usarlo. Es qué incertidumbre debía reducir el lanzamiento y qué comportamiento observable permitiría tomar la siguiente decisión.
01 · VALIDATION MAP
Un MVP no se valida en un solo salto
Capa 01 · EVIDENCIA DISPONIBLE
El software funciona
El flujo carga, acepta datos y produce el resultado diseñado.
Pregunta: ¿Podemos ejecutar la solución con usuarios reales?
Decisión: Pasar de la prueba técnica a observar el uso real.
Capa 02 · SIGUE ABIERTO
El usuario llega al resultado
Necesitamos ver si las personas completan el camino sin una intervención excepcional del equipo.
Pregunta: ¿El producto permite alcanzar first value en el contexto esperado?
Decisión: Investigar comprensión, fricción o una expectativa mal planteada.
Capa 03 · SIGUE ABIERTO
El resultado importa
Usar el flujo no equivale a reconocer que el problema quedó resuelto.
Pregunta: ¿Qué cambia para la persona después de usarlo?
Decisión: Revisar propuesta de valor, segmento o resultado prometido.
Capa 04 · SIGUE ABIERTO
El comportamiento se repite
Una sesión positiva no demuestra que la necesidad reaparezca ni que el producto sea la elección natural.
Pregunta: ¿La persona vuelve cuando vuelve el problema?
Decisión: Invertir en recurrencia sólo si existe evidencia de una necesidad repetible.
02 · SCENARIO
El MVP puede pasar una capa y fallar la siguiente
ESCENARIO ILUSTRATIVO
Una herramienta para preparar propuestas comerciales
El equipo construyó un flujo que recibe información del cliente, genera una propuesta y la deja lista para enviar. El lanzamiento funciona técnicamente y diez personas aceptan probarlo.
FUNCIONA
10 personas completan el flujo y el sistema genera el documento.
SE DEBILITA
Sólo 2 llegan a enviar una propuesta a un cliente real.
SIGUE ABIERTO
Ninguna vuelve sin que alguien del equipo la acompañe paso a paso.
HECHO
El flujo técnico se completa.
INTERPRETACIÓN
La solución podría ahorrar trabajo cuando el contexto es correcto.
INCERTIDUMBRE
Si el problema es suficientemente importante para repetirse y sostener adopción.
Decisión habilitada: No añadir más plantillas todavía: observar a esas dos personas, reconstruir el contexto y entender por qué ocho no llegaron al resultado.
El error sería llamar “validado” a todo el producto porque una parte del flujo funciona. La evidencia disponible es más precisa: sabemos que podemos ejecutar una solución; todavía no sabemos si esa solución merece convertirse en comportamiento recurrente.
03 · EVIDENCE
Qué buscar después de construir
EVIDENCIA OBSERVADA
- La persona explica el problema en su propio contexto
- Alcanza el resultado sin intervención excepcional
- Reconoce qué cambió después de usarlo
- Vuelve cuando vuelve la necesidad
INTERPRETACIÓN QUE AÚN NO DEBES DAR POR HECHA
- “Se registró, por tanto lo necesita”
- “Completó el flujo, por tanto encontró valor”
- “Le gustó la demo, por tanto pagará”
- “Dos casos funcionaron, por tanto es repetible”
La validación no es una etiqueta binaria: es saber qué parte de la hipótesis tiene evidencia y cuál sigue abierta.
DEFINICIÓN
Un MVP funcional demuestra capacidad de construir. Un MVP validado requiere evidencia de que la solución produce el comportamiento o resultado que justificó construirla.
La diferencia no es semántica: determina si la siguiente inversión debe mejorar el producto, investigar el problema o detener una dirección.
04 · DECISIÓN
La siguiente inversión debe seguir la incertidumbre crítica
Si el problema está claro pero el valor no aparece, investiga la propuesta y el momento de uso. Si el valor aparece pero nadie vuelve, investiga la frecuencia de la necesidad. Si sólo funciona con acompañamiento, separa la capacidad del equipo de la capacidad real del producto.
No preguntes si el MVP “pasó”. Pregunta qué hipótesis ya tiene evidencia suficiente y cuál cambiaría la decisión de continuar.
PRODUCT & UX DIAGNOSTIC
Analiza qué necesita validarse antes de seguir construyendo.
Ordena la situación, la evidencia disponible y la decisión que conviene preparar.
Analiza tu situación de productoFUENTES
Fuentes
- Silicon Valley Product Group · Product Success · discovery como reducción de riesgo antes de escalar una solución.
- Google Research · HEART · conectar objetivos de producto con señales observables.
FOUNDERS UX
Construir rápido no es suficiente.
Construir lo correcto es la diferencia.
Cuéntanos qué está frenando tu producto y lo revisamos contigo.