Programar es una forma cara de descubrir que a nadie le importa el producto. Antes de elegir framework o contratar equipo, convierte la idea en hipótesis comprobables: quién sufre el problema, cómo lo resuelve hoy, cuánto cuesta, quién compra y por qué cambiaría ahora.
Escribe un problema que se pueda refutar
Define un segmento, un trabajo recurrente y una consecuencia medible. “Las pymes necesitan IA” no se puede probar. “Las gestoras con más de 200 viviendas dedican diez horas semanales a clasificar incidencias” sí. Escribe qué evidencia invalidaría la hipótesis antes de pedir opiniones.
Entrevista comportamientos, no intenciones
Pregunta por la última vez que ocurrió el problema: qué lo desencadenó, qué hicieron, cuánto tardaron, cuánto pagaron y quién aprobó la solución provisional. No vendas durante el descubrimiento. Los cumplidos y un “yo pagaría” hipotético son señales débiles; presupuestos actuales, hojas de cálculo, proveedores y ventas perdidas pesan más.
Prueba el mayor riesgo con el artefacto más pequeño
Elige el experimento más barato que pueda cambiar la decisión: prototipo navegable para usabilidad, landing para claridad del mensaje, servicio manual para validar el flujo o piloto pagado para comprobar demanda. Explica con honestidad qué existe; no presentes una maqueta como producto terminado ni recojas datos personales sin finalidad legítima y protecciones adecuadas.
Define compromiso y éxito antes de probar
Un experimento útil fija audiencia, canal, muestra, duración y umbral. Mide acciones cercanas al valor: reuniones cualificadas, datos relevantes entregados, cartas de intención, depósito para un piloto, uso repetido o recomendaciones. El tráfico y las encuestas ayudan con adquisición, pero no prueban retención ni voluntad de pago.
Mapea el proceso antes que las funcionalidades
Documenta entradas, decisiones, excepciones, salidas, integraciones y límites de cumplimiento. Ejecuta el flujo manualmente y registra dónde se rompe. Descubrirás si hace falta software y cuál debe ser la frontera del MVP. Después aplica cómo pensar un proyecto técnico antes de escribir código para convertir evidencia en arquitectura.
Errores comunes
- preguntar a amigos si les gusta la idea
- explicar la solución antes de conocer comportamientos pasados
- confundir registros de email con intención de pago
- probar varios segmentos simultáneamente
- crear software pulido para validar una hipótesis básica
- ignorar comprador, presupuesto y proceso de aprobación
- cambiar el criterio de éxito al recibir malos resultados
- recoger datos personales innecesarios
- continuar por coste hundido y no por evidencia
Checklist práctico de validación
- nombra un cliente concreto y un problema recurrente
- escribe hipótesis y evidencia que las invalidaría
- entrevista comportamientos reales de personas relevantes
- cuantifica frecuencia, coste y alternativas actuales
- identifica usuario, comprador y decisión
- selecciona la hipótesis de mayor riesgo
- ejecuta el experimento honesto más pequeño
- fija el umbral de éxito antes de empezar
- registra evidencia, objeciones y excepciones
- decide parar, iterar o acotar el MVP
Cuándo tiene sentido contratar a una persona técnica
Incorpora un responsable técnico de producto o fractional CTO cuando la validación dependa de integraciones, seguridad, datos regulados, costes relevantes de infraestructura o una estimación creíble del MVP. Su función es reducir incertidumbre, no empujar prematuramente al desarrollo. Con demanda creíble, sigue un proceso de idea a MVP con alcance controlado.
Conclusión
Validar es un sistema de decisión: hipótesis, experimentos honestos, compromiso observable y umbrales explícitos. Si necesitas una revisión técnica independiente antes de invertir en un MVP, contacta conmigo.