El error más caro en producto es construir algo que nadie quiere. CB Insights reporta que el 35% de startups fallan porque no hay necesidad de mercado. Carta reporta que los fracasos de startups subieron 58% en 2024. Casi todos esos fracasos enviaron código, diseñaron interfaces, contrataron equipos y corrieron campañas de marketing para algo que el mercado nunca pidió en la forma en que se entregó.
El arreglo es product validation: un proceso disciplinado para probar si usuarios reales quieren lo que vas a construir, antes de invertir los recursos para construirlo. Este artículo destila un framework funcional de 30 días, construyendo sobre el enfoque de Eric Hoppe en el blog de Canny y adaptándolo para equipos de producto que usan portales de feedback y roadmaps públicos.
Qué es product validation realmente
Validation no es preguntarle a los clientes si usarían tu producto. Van a decir que sí. Validation es estructurar una situación donde el comportamiento del cliente revela si la demanda es real, idealmente antes de haber construido la cosa.
La distinción importa. "¿Pagarías $20 al mes por esto?" obtiene 70% de sí. "Aquí está el link de signup, $20 al mes" obtiene la respuesta real. Validation diseña experimentos que producen comportamiento, no solo preferencia declarada.
El framework de 30 días
Días 1-5: hipotetizar la necesidad
Empieza con una frase: "Creemos que [segmento] tiene [problema] y valoraría [solución] lo suficiente para [acción]". Haz el segmento específico (no "pequeñas empresas" sino "diseñadores freelance ganando entre 50.000 y 150.000 al año"). Haz la acción específica (registrarse, pagar, agendar demo, compartir contacto).
Escribe tres versiones de la hipótesis con framings distintos. Pásalas con dos asesores de confianza. Elige la versión más fuerte. Ya tienes algo testeable.
Días 6-10: investigar el mercado
Antes de hablar con nadie, entiende el paisaje:
- Competidores existentes: qué ofrecen, de qué se quejan las reviews, qué gaps existen
- Volumen de búsqueda: ¿la gente está activamente buscando soluciones a este problema?
- Soluciones adyacentes: ¿cómo resuelve la gente este problema hoy (aunque sea mal)?
- Señales de tamaño de mercado: ¿cuánta gente entra en el segmento? ¿qué tan accesibles son?
Un día por fuente. Para el día 10 deberías saber si el espacio de problema está vacío (mala señal, nadie busca), abarrotado (puede ser bueno si tienes ventaja real) o creciendo (la mejor señal).
Días 11-17: conversaciones con clientes
Haz 8-12 entrevistas a clientes con personas que encajen en el segmento. No amigos, no inversores, no tu equipo. Personas reales en el segmento objetivo.
Tres preguntas para anclar cada entrevista:
- Cuéntame de la última vez que intentaste resolver [problema].
- ¿Qué usaste? ¿Qué funcionó? ¿Qué no?
- Si existiera una solución perfecta, ¿qué cambiaría en tu semana?
Escucha las palabras que ellos usan, no las que tú usarías. El desajuste de vocabulario es a menudo donde falla la validation. La gente no tiene el problema enmarcado como tú lo enmarcas.
Días 18-22: construir el artefacto más pequeño posible
Ahora tienes suficiente señal para probar demanda con un artefacto. Opciones, ordenadas por fuerza de validation:
| Artefacto | Señal que produce | Coste de build |
|---|---|---|
| Landing page con signup | Interés al punto de precio | 1 día |
| MVP de concierge (lo haces a mano) | ¿La gente paga por el outcome? | 2-3 días |
| Prototipo clickable | Feedback de UX, fit conceptual | 3-5 días |
| MVP Wizard of Oz | Comportamiento end-to-end | 4-7 días |
Elige el que prueba tu suposición de mayor riesgo. Si el riesgo es "¿pagará alguien?", una landing page basta. Si el riesgo es "¿podemos entregar el outcome?", el MVP de concierge es lo correcto.
Días 23-27: probar, ajustar, mejorar
Pon el artefacto delante de usuarios reales del segmento objetivo. Veinte usuarios, mínimo. Mide comportamiento, no opiniones:
- ¿Se registraron?
- ¿Usaron el producto / tomaron la acción?
- ¿Pagaron (o se comprometieron a pagar)?
- ¿Se lo contaron a alguien?
La preferencia declarada es cómoda y poco fiable. La preferencia revelada es la señal que importa.
Días 28-30: chequear señal de product-market fit
Para el día 30 deberías saber una de tres cosas:
- Señal fuerte: Múltiples usuarios tomaron la acción, pagaron o se comprometieron, preguntaron cuándo habría más. Construye.
- Señal mixta: Algunos usuarios respondieron, pero no puedes decir si es el segmento o el framing. Refina y corre un segundo ciclo de 30 días en el sub-segmento más fuerte.
- Sin señal: Los usuarios fueron amables pero no actuaron. La hipótesis está mal. Mata la idea o pivota a otro espacio de problema.
El 35% de startups que fallan por falta de necesidad de mercado normalmente enviaron seis meses demasiado pronto. Una validation de 30 días no habría salvado a todas, pero habría salvado a muchas.
Cómo validation conecta con el roadmap
Para productos que ya envían, validation es una disciplina a nivel feature, no solo a nivel startup. Toda iniciativa significativa del roadmap debe pasar por un ciclo de validation escalado a la apuesta:
- Features pequeños: validation de 1 semana. Prototipo rápido con 3-5 usuarios.
- Features medianos: validation de 2 semanas. Concierge o wizard-of-oz con 10-15 usuarios.
- Apuestas grandes: validation de 30 días. Framework completo.
Validation no es fricción. Es el coste de evitar fricción mucho mayor después cuando descubres que el feature no funciona para la gente que pensabas.
Errores comunes de validation
- Hablar con la gente equivocada. Si tus entrevistados son amigos o contactos cálidos, serán de apoyo. Encuentra desconocidos en el segmento.
- Hacer preguntas guiadas. "¿Sería útil?" obtiene sí. "¿Qué hiciste la última vez que tuviste este problema?" obtiene verdad.
- Construir demasiado antes de probar. Una landing page prueba demanda en 1 día. Un feature construido prueba demanda en 6 semanas. Usa el test más barato primero.
- Confundir engagement con validation. Usuarios clickando en tu prototipo no es validation. Usuarios registrándose, pagando o volviendo sí.
- Ignorar los datos cuando desconfirman. Validation solo funciona si eres honesto sobre la desconfirmación. La mayoría de equipos encuentran formas de leer un resultado negativo como alentador.
Para llevar
Product validation es el seguro más barato contra construir lo equivocado. El framework de 30 días te mueve de hipótesis a evidencia en un mes: hipotetiza, investiga, entrevista, construye el artefacto más pequeño, prueba con usuarios reales, lee la señal honestamente. El 35% de startups fallidas son en su mayoría las que se saltaron esto. Incluso los productos maduros se benefician de la disciplina escalada al tamaño del feature. Construye menos, valida más, y la tasa de features que encuentran su audiencia mejora dramáticamente.
