MVP · VALIDATION · PRODUCT DISCOVERY
Publicado: 9 septiembre 2026 · Lectura editorial
Product Discovery para startups: qué validar antes de seguir construyendo tu MVP
La startup ya tiene developers, backlog y presión por avanzar. La pregunta no es cómo detener delivery, sino cómo reducir la incertidumbre sobre lo que merece construirse después.
Product Discovery suele interpretarse como una fase previa: semanas de research, workshops y documentación antes de volver a construir. Para un equipo early-stage, esa interpretación puede hacer que aprender parezca incompatible con avanzar.
Discovery no debería detener el desarrollo. Debería generar suficiente evidencia para tomar la siguiente decisión.
Teresa Torres describe Continuous Discovery como pequeños contactos regulares con clientes por parte del equipo que construye el producto, orientados a un resultado. La idea central es integrar aprendizaje al trabajo, no crear una pausa ceremonial.
Ver cómo trabajamos validación de MVP01 · VELOCIDAD
El problema no es construir rápido
SHIPPING VELOCITY
La capacidad del equipo para entregar cambios.
LEARNING VELOCITY
La capacidad del equipo para aprender qué decisión merece el siguiente cambio.
Una startup puede entregar features rápidamente y seguir aprendiendo lentamente. El riesgo aparece cuando la secuencia se vuelve BUILD → BUILD → BUILD sin suficiente evidencia entre decisiones.
02 · DEFINICIÓN
Discovery es decidir qué vale la pena construir
Para Founders UX, Product Discovery es el proceso de reducir incertidumbre antes de comprometer más recursos con una decisión de producto. No es producir más research: es identificar qué no sabemos, elegir la evidencia adecuada y convertirla en una decisión.
Esta interpretación se apoya en el contraste entre Product Discovery y Product Delivery de Product Talk y en el enfoque de riesgos de SVPG.
DISCOVERY DEPTH × DECISION RISK
La profundidad de Discovery debe crecer con el riesgo de la decisión.
BAJO
Cambio reversible, barato y con poco impacto.
MEDIO
Más dependencia técnica, usuarios afectados o trabajo cruzado.
ALTO
Decisión costosa, difícil de revertir o conectada con revenue.
Es un principio de decisión de Founders UX, no una fórmula científica ni una regla de horas.
03 · CUATRO RIESGOS
No todas las decisiones necesitan la misma evidencia
SVPG organiza los riesgos de producto alrededor de value, usability, feasibility y viability. No hace falta validar los cuatro con la misma profundidad en cada decisión; hace falta identificar cuál puede volver más cara la siguiente apuesta.
VALUE
¿Los usuarios lo necesitan o elegirían usarlo?
USABILITY
¿Pueden entenderlo y completar lo que necesitan?
FEASIBILITY
¿Podemos construirlo razonablemente con nuestra tecnología, tiempo y capacidades?
VIABILITY
¿Tiene sentido para el negocio, la operación y sus restricciones?
Fuente conceptual: The Four Big Risks · SVPG.
04 · PENSAR ANTES DE CONSTRUIR
Las features son soluciones; las hipótesis explican por qué
FEATURE
Construir onboarding guiado.
HIPÓTESIS
Los usuarios abandonan porque no entienden qué deben hacer después de registrarse.
FACT
Lo observable.
↓INFERENCE
La interpretación provisional.
↓HYPOTHESIS
Lo que proponemos comprobar.
↓VALIDATION
La evidencia que cambia la decisión.
05 · EVIDENCIA
La evidencia debe responder la pregunta correcta
Analytics no reemplaza entrevistas. Entrevistas no reemplazan observar comportamiento. Cada método aporta una pieza distinta de la decisión.
Comportamiento existente
Analytics, funnels, session recordings y razones de soporte.
Responde: Qué hacen las personas y dónde aparece la fricción.
Comprensión
Pruebas de usabilidad y task testing con prototipos.
Responde: Si pueden entender y utilizar una solución.
Necesidad
Entrevistas, conversaciones con clientes y evidencia de ventas o soporte.
Responde: Qué problema existe y en qué contexto.
Demanda
Experimentos de landing, concierge tests, fake doors éticos, pre-sales o waitlists.
Responde: Si una propuesta genera una acción real de interés.
06 · DISCOVERY Y DELIVERY
Aprender sin detener al equipo
AHORA
Delivery trabaja en decisiones suficientemente entendidas.
SIGUIENTE
Discovery reduce incertidumbre sobre lo que podría entrar después.
DESPUÉS
Las hipótesis todavía exploratorias ganan evidencia antes de comprometer más trabajo.
No existe un calendario universal ni una cantidad fija de semanas “por delante”. Discovery y Delivery pueden solaparse cuando el tamaño de la actividad es proporcional a la decisión.
EJEMPLO HIPOTÉTICO
Una caída durante onboarding
MALA SECUENCIA
“Tenemos abandono → construyamos un nuevo onboarding.”
MEJOR SECUENCIA
FACT: existe una caída observable en un paso concreto.
INFERENCE: el paso puede estar generando fricción.
HYPOTHESIS: las personas no entienden qué información necesitan proporcionar o por qué.
VALIDATION: analytics, sesiones, pruebas de usabilidad o conversaciones adecuadas.
DECISION: después decidir qué intervención merece construirse.
07 · CUÁNDO ES SUFICIENTE
Discovery también tiene un costo
No necesitas más Discovery cuando la evidencia ya es suficientemente clara, el cambio es barato y reversible, existe una obligación técnica o legal, el problema está ampliamente observado o un experimento cuesta menos que seguir investigando.
La meta no es eliminar incertidumbre. Es reducirla lo suficiente para tomar una decisión proporcional al riesgo.
Ver cuándo tiene sentido trabajar con Founders UXMVP · VALIDATION
¿Estás por seguir construyendo, pero todavía hay decisiones que no están claras?
Conoce cómo Founders UX trabaja validación de MVP para reducir incertidumbre antes de comprometer más desarrollo.