Valida una idea antes de construir probando la demanda barato: habla con usuarios potenciales reales, pon una landing que mida interés, e intenta conseguir un compromiso — un registro, una preventa, un depósito — antes de escribir código. La meta es evidencia de que la gente quiere esto lo suficiente para actuar, no solo acuerdo amable. Si no consigues un sí barato, un producto terminado rara vez lo vuelve uno real. Demuestra demanda primero.
¿Cuál es la forma más barata de validar?
Conversaciones y una landing. Habla con diez usuarios potenciales reales sobre el problema — no tu solución — y escucha si es un problema real, doloroso y frecuente. Luego pon una sola landing que describa la oferta y mida interés con un registro o lista de espera. Ambas cuestan casi nada y toman días, no meses. Si ninguna produce interés, ese es el "no" más barato que tendrás, y acaba de ahorrarte un build entero. Mantén las conversaciones sobre su problema, no sobre tu idea — pregunta qué hacen hoy, cuánto les cuesta y qué ya intentaron para resolverlo. En cuanto vendes, la gente se pone amable; mientras preguntes sobre su mundo, obtienes la verdad.
¿Qué cuenta como validación real?
Un compromiso, no un cumplido. "Suena genial" es gratis; un registro de correo, una preventa, un depósito o una llamada agendada es evidencia, porque le cuesta algo a la persona. La señal más fuerte es alguien intentando pagarte antes de que la cosa exista del todo. Peso las acciones sobre las opiniones siempre — la gente es amable en entrevistas y honesta con su billetera y su bandeja. Busca la acción, no el aplauso, y confía en lo que la gente hace. Una escalera simple de señal, de más débil a más fuerte: un cumplido, un registro de correo, una preventa o depósito, y alguien persiguiéndote activamente para conseguir acceso. Cuanto más abajo en esa escalera logres llevar a alguien, más real es la demanda — y más confianza puedes tener en que un build vale la pena financiar.
¿Cuáles son los errores comunes de validación?
Construir primero y validar después, hacer preguntas dirigidas y solo hablar con amigos. Amigos y familia quieren apoyarte, así que son señal débil. Las preguntas dirigidas ("¿no sería genial si…?") te dan la respuesta que quieres, no la verdad. Y el mayor: saltarte la validación porque construir se siente como progreso. Meses de código es la forma más cara de descubrir que nadie lo quería. Pruebas baratas primero, código después. Una trampa más: tratar un solo "sí" entusiasta como prueba. Una persona emocionada es una anécdota, no un mercado — busca un patrón repetible en varios prospectos reales antes de comprometerte, porque la demanda que solo existe en una bandeja suele quedarse ahí.
¿Con cuántas personas necesitas hablar?
Menos de las que crees para ver un patrón — normalmente unas diez conversaciones enfocadas con usuarios potenciales reales bastan para ver si un problema es común, doloroso y frecuente, o solo tuyo. No estás corriendo una encuesta estadística; estás escuchando si el mismo dolor aparece una y otra vez en las palabras de gente que de verdad pagaría. Si ocho de diez se encienden con el problema, esa es una señal fuerte. Si te cuesta hasta encontrar diez personas que tengan el problema, eso también es una señal — y una más barata de recibir ahora que después de un build.
¿Puedes validar sin construir nada?
Sí — ese es justo el punto. Las pruebas previas más fuertes no usan código de producto: una landing que mide registros, una preventa o depósito, una lista de espera, o una prueba "concierge" donde entregas el resultado a mano para los primeros clientes. Cada una prueba demanda real con horas de trabajo en vez de semanas de construcción. Un video demo o un prototipo clicable pueden sustituir al producto mientras mides si la gente se inclina. Solo cuando algo real regresa — dinero, registros, gente persiguiéndote — escribir código se vuelve el siguiente gasto correcto, e incluso entonces construyes la versión más pequeña que prueba el núcleo.
¿Cómo ayudo a validar antes de un build?
Antes de acotar un MVP, empujo a confirmar que hay demanda real — y si aún no la hay, el siguiente paso más barato es una prueba, no un build. Cuando la señal está, acoto la versión más pequeña que prueba el núcleo, como describo en mi entrega SaaS. Validación y un MVP ajustado son el mismo instinto: gastar lo mínimo para aprender lo máximo. Construye cuando tengas una razón real para hacerlo.
Guías de estrategia relacionadas
Mira cómo acotar un MVP, sitio web, app o SaaS — qué construir primero y MVP vs prototipo vs prueba de concepto.
¿Probando una idea? Cuéntame qué estás construyendo — te ayudo a encontrar la forma más barata de probarla antes de gastar en código.
