Cómo validar una idea de SaaS antes de escribir una sola línea de código

La forma más cara de averiguar si la gente quiere su software es construirlo. Y, sin embargo, eso es exactamente lo que hacen la mayoría de los fundadores primerizos: pasan seis meses y sus ahorros convirtiendo una idea en código, la lanzan al silencio y solo entonces empiezan a preguntarse si alguien la necesitaba. La validación es la versión barata de esa lección. Es cómo se compra la respuesta con unas semanas de conversaciones en lugar de con un año de su vida.

He visto a mucha gente inteligente caer en la misma trampa. Tienen una observación genuinamente buena —una molestia real en un sector que conocen— y dan por hecho que la distancia entre la observación y el producto es solo cuestión de ingeniería. No lo es. Esa distancia está llena de preguntas sin responder: ¿siente alguien más ese dolor lo suficiente como para pagar? ¿Cambiarán de lo que hacen ahora? ¿Puede llegar a ellos sin quemar dinero? Esas preguntas no se responden escribiendo código. Se responden hablando con la gente y observando lo que realmente hace.

Así que esta es la guía que doy a los fundadores antes de que contraten a nadie para construir nada. No se trata de teatro lean-startup ni de rellenar un lienzo. Se trata de un puñado de experimentos honestos y baratos que le dicen si su idea tiene pulso, y de la disciplina de creer los resultados, aunque escuezan.

Por qué construir primero parece productivo y casi nunca lo es

Construir es seductor porque parece un avance que se puede ver. Al final de una sesión de código hay una pantalla que funciona, un botón que hace algo, una cosa que puede enseñar a su pareja. Hablar con desconocidos sobre un problema no produce ningún objeto. Es incómodo, es lento y, al terminar, no tiene más que notas. Por eso los fundadores recurren al teclado: el teclado los recompensa más rápido.

El problema es que una pantalla que funciona no le dice casi nada sobre si la idea es acertada. Puede construir un producto precioso y sin errores para un problema que nadie tiene, y estará igual de muerto que uno feo. El código es la respuesta a «¿cómo lo entregamos?», no a «¿lo quiere alguien?». Dedicar meses a la primera pregunta antes de haber respondido la segunda es como los buenos ingenieros acaban construyendo soluciones elegantes para problemas imaginarios.

La validación invierte el orden. Dedica unas semanas y muy poco dinero a demostrar —o desmentir— la suposición más arriesgada de su idea antes de comprometerse a construir. Si la idea es sólida, entra en el desarrollo con pruebas, una especificación más clara y sus primeros usuarios ya esperando. Si es débil, lo descubre por el precio de unos cafés y una página de aterrizaje, no por el de un producto.

Encuentre la única suposición que podría hundirlo todo

Toda idea de SaaS descansa sobre una pila de creencias, y no son igual de peligrosas. Algunas son seguras: «la gente usa el correo», «a las pequeñas empresas no les gusta el papeleo». Otras son apuestas de las que depende todo su proyecto y, si están equivocadas, nada más importa. La tarea de la validación no es probarlo todo. Es encontrar la suposición más arriesgada y atacar esa primero.

Para encontrarla, escriba su idea en una sola frase: «[estas personas] tienen [este problema] con la suficiente intensidad como para pagar por [esta solución] en lugar de [lo que hacen ahora].» Luego pregúntese, sin piedad: ¿qué palabra de esa frase, si resultara falsa, hundiría la idea? Por lo general no es la solución. Es si el problema duele lo bastante como para pagar por él, o si de verdad puede llegar a esas personas a un coste razonable.

Esta secuencia importa porque el coste de probar sube en cada paso. Una entrevista sobre el problema es gratis. Una prueba de disposición a pagar cuesta una página de aterrizaje. Una prueba de la solución quizá necesite un prototipo clicable. Construir es la prueba más cara de todas. Quiere fracasar barato y pronto, no caro y tarde, así que coloca las pruebas más baratas y letales por delante.

Hable con la gente, pero hágalo bien

Lo más útil que puede hacer es hablar con las personas que cree que tienen el problema. No con sus amigos, no con otros fundadores: los seres humanos reales que usarían esto. Y aquí está la trampa que arruina la mayoría de los intentos: la gente es educada. Pregunte «¿usaría una herramienta que hace X?» y casi todos dirán que sí, porque decir que sí es gratis y amable. Ese sí no vale nada. Ha hundido más startups que cualquier fallo técnico.

La solución es dejar de preguntar por el futuro y empezar a preguntar por el pasado. El futuro es donde la gente miente para ser amable; el pasado es donde vive la verdad. En lugar de «¿usaría esto?», pregunte «cuénteme la última vez que tuvo que lidiar con este problema». ¿Qué hizo? ¿Cuánto tardó? ¿Cuánto le costó? ¿Buscó una solución? ¿Pagó por alguna? El comportamiento real le gana al entusiasmo hipotético cada vez.

Preguntas que obtienen respuestas honestas

• «Lléveme a la última vez que esto ocurrió.» — saca a la luz el flujo de trabajo real, no uno idealizado.
• «¿Qué hizo al respecto?» — revela si de verdad le importa o si simplemente se encoge de hombros.
• «¿Cuánto tiempo o dinero le costó eso?» — convierte un dolor vago en una cifra.
• «¿Ha intentado resolverlo antes? ¿Qué pasó?» — le dice si hay presupuesto e intención.
• «¿Qué le molesta ahora mismo más que esto?» — comprueba si su problema entra siquiera en su top cinco.

¿Cuántas conversaciones? Menos de las que cree. Cuando haya hecho diez entrevistas honestas y bien llevadas con las personas adecuadas, el patrón suele ser obvio. O tres o cuatro de ellas se iluminan y describen el dolor con todo lujo de detalles, o todas están educadamente tibias, y ningún desarrollo por ingenioso que sea arreglará eso. De doce a quince son de sobra para tomar una decisión en la que pueda confiar.

Formas baratas de probar la demanda real

Las conversaciones le dicen si el problema es real. La siguiente pregunta es si la gente actuará, y la única forma de saberlo es pedir un pequeño compromiso antes de que exista el producto. Aquí la validación se vuelve un poco incómoda, y también es donde se vuelve honesta. Hablar es barato; un clic, una dirección de correo o un anticipo no lo son.

No necesita construir nada para realizar estas pruebas. Necesita una única página que describa con claridad la promesa y pida una acción concreta. La acción es el dato. Si la gente lee su propuesta y no hace nada, esa es su respuesta, y es una respuesta mucho más barata que lanzar al vacío dentro de seis meses.

1. 1
   Publique una propuesta de una sola página

   Describa el problema y su solución en lenguaje sencillo, con una llamada a la acción clara. Una página de aterrizaje simple basta, todavía sin ningún producto detrás.
2. 2
   Pida una señal real

   No un «me gusta». Pida a la gente que se apunte a una lista de espera con su correo, que reserve por adelantado o que agende una llamada. Cuanto más le cueste decir que sí, más significa ese sí.
3. 3
   Lleve un poco de tráfico honesto

   Compártalo donde ya esté su audiencia real: una comunidad relevante, un anuncio pequeño, unos cuantos mensajes directos. Quiere desconocidos, no su red de apoyo.
4. 4
   Lea la conversión, no los cumplidos

   De todos los que entendieron de verdad la oferta, ¿cuántos hicieron la acción? Un puñado de registros reales de las personas adecuadas le gana a mil buenos deseos vagos.

La prueba de demanda más potente de todas es pedir dinero por adelantado. Una preventa, un piloto de pago, un anticipo por acceso anticipado: cualquier cosa en la que se abra una cartera. Parece agresivo, y es lo más honesto que puede hacer por usted mismo. Quien entrega aunque sea una pequeña suma por un producto que aún no existe le está diciendo algo que ninguna encuesta podría. Si encuentra a tres o cuatro de esas personas, ya no tiene una idea. Tiene un negocio esperando a ser construido.

Véndalo antes de construirlo

Hay un paso entre «la gente está interesada» y «la gente pagará cada mes» que merece su propia atención: entregar el valor a mano antes de automatizarlo. Si su idea es, pongamos, una herramienta que convierte correos desordenados de proveedores en un informe semanal ordenado, hágalo a mano primero para tres o cuatro clientes. Usted se convierte en el software. Es lento y no escala, y ese es justo el punto: le permite aprender qué necesita hacer de verdad el producto antes de haberlo plasmado en código.

Esto consigue dos cosas a la vez. Demuestra que la gente pagará por el resultado, no solo por la idea de él. Y le enseña el flujo de trabajo real: los casos límite, las excepciones, los detalles que les importan a los clientes y que jamás habría adivinado en una entrevista. Cuando por fin construya, no estará adivinando la especificación. Estará codificando un proceso que ya ha ejecutado a mano y por el que le han pagado.

Leer las señales con honestidad

Todo esto solo funciona si está dispuesto a creer los resultados, y eso es más difícil de lo que parece, porque a estas alturas ya está apegado a la idea. El peligro no son los datos malos; es un fundador que interpreta cada señal como un aliento. Un interés tibio se recuerda como entusiasmo. Un registro educado en la lista de espera se convierte en «demanda fuerte». Aquí tiene que luchar contra su propio optimismo.

Ayuda decidir, de antemano, cómo es un aprobado. Antes de hacer una prueba, escriba el resultado que le haría seguir y el que le haría parar. «Si menos de X de mis entrevistas describen esto como un problema real y recurrente, lo abandono.» Fijar el listón antes de ver los datos es la única defensa fiable contra convencerse a sí mismo de un desarrollo que no debería hacer.

Y a veces la respuesta honesta es no. Eso no es un fracaso: es el sistema funcionando. Un proceso de validación que nunca puede devolver «no construyas esto» no es validación, es buscar permiso. Los fundadores que ganan a lo largo de una carrera no son los que nunca tienen malas ideas. Son los que matan las malas ideas en tres semanas por unos cientos de euros en lugar de cuidarlas durante un año.

Cuando esté de verdad listo para construir

Digamos que las señales son buenas. El problema es real, la gente lo describió con sentimiento, unos cuantos pusieron dinero. Ahora —y solo ahora— construir tiene sentido. Pero incluso aquí, la contención paga. El objetivo de su primera versión no es ser el producto que imagina. Es entregar el único resultado central por el que pagan sus clientes validados, y nada más por ahora.

Aquí es donde la validación le entrega en silencio un regalo: una especificación nítida y respaldada por pruebas. Sabe para quién es, cuál es la tarea central, por qué pagará la gente y qué funciones surgieron una y otra vez frente a las que solo le importaban a usted. Esa claridad vale más que cualquier cantidad de diseño previo. Es la diferencia entre construir la cosa pequeña correcta y construir un todo carísimo.

Preguntas frecuentes