- The Startup Eye
- Posts
- 🦄 El Anti-Manual de Startup · Cap. 3
In partnership with
❌ No valides todo antes de construir
Si consumes contenido sobre producto, hay otro dogma que se repite sin descanso:
“Habla con usuarios”
“Valida antes de construir”
“No escribas una línea de código sin feedback”
Suena sensato
Y, llevado al extremo, es una de las formas más eficaces de no construir nada relevante
La creencia es clara:
Hay que validar absolutamente todo con usuarios antes de construir.
La realidad es bastante más incómoda
El usuario no sabe lo que quiere… hasta que lo ve
Los usuarios son excelentes detectando problemas
Son terribles diseñando soluciones
Y hay otra realidad que casi nadie te dice:
Equivocarte rápido suele ser muchísimo más barato que intentar tenerlo todo claro y perfecto antes de mover un dedo.
La perfección previa no reduce riesgo.
A menudo lo aplaza… y lo encarece.
Aquí encaja muy bien la filosofía “Musk” aplicada a producto:
menos PowerPoints, más prototipos
menos certezas inventadas, más pruebas reales
si algo falla, que falle pronto, pequeño y con datos
Patrocinador de hoy:
Gracias a este patrocinio, podemos seguir enviándote contenido gratuito cada día.
Solo con hacer clic aquí ya estás apoyando muchísimo a The Startup Eye.
No tienes que pagar nada. Solo haces CLIC y listo.
Want to get the most out of ChatGPT?
ChatGPT is a superpower if you know how to use it correctly.
Discover how HubSpot's guide to AI can elevate both your productivity and creativity to get more things done.
Learn to automate tasks, enhance decision-making, and foster innovation with the power of AI.
Si le preguntas a alguien qué quiere, te responderá desde su marco actual:
lo que ya conoce
lo que ya usa
lo que sabe explicar
No desde lo que podría existir
La mayoría de productos que hoy parecen “obvios” no habrían pasado una validación clásica:
“¿Te gustaría trabajar sin oficina?”
“¿Confiarías tu dinero a una app sin sucursales?”
“¿Usarías un editor de código que te sugiere lo que escribir?”
La respuesta inicial suele ser tibia, confusa o directamente negativa
No porque la idea sea mala, sino porque el cerebro humano es conservador por defecto
Demasiada validación mata la visión
Validar no es gratis
Cada conversación añade fricción cognitiva
Cuando validas todo:
diluyes la idea original
introduces compromisos prematuros
empiezas a optimizar antes de entender
Peor aún: empiezas a construir por consenso, no por convicción
Y los productos por consenso rara vez destacan
Son correctos
Son aceptables
Son olvidables
Confundir educación con rechazo es un error clásico
Muchos “no” no son rechazo
Son falta de contexto
El usuario dice:
“No lo usaría”
Lo que muchas veces quiere decir es:
“No entiendo aún por qué lo necesitaría”
Hay productos que requieren:
aprendizaje
cambio de hábito
un pequeño salto mental
Si interpretas eso como invalidación, abortas ideas que solo necesitaban exposición, no aprobación
Qué sí validar (y qué no)
Aquí está el matiz que casi nadie explica
Sí tiene sentido validar:
que el problema exista
que el dolor sea real
que alguien esté dispuesto a pagar
que el flujo básico no sea incomprensible
No tiene sentido validar:
la solución exacta
cada feature
la forma final del producto
la visión a largo plazo
La visión no se valida
Se ejecuta
Cuándo la validación se convierte en ruido
La validación empieza a ser ruido cuando:
haces más entrevistas que iteraciones
buscas confirmación, no señales
cambias de dirección cada semana
retrasas construir “una última ronda de feedback”
Ahí no estás validando
Estás evitando tomar decisiones
Ejemplos incómodos de productos “no validados”
Muchos productos que hoy se estudian como casos de éxito:
no hicieron encuestas masivas
no pidieron permiso
no ajustaron la visión para gustar
Construyeron algo claro
Lo pusieron delante del usuario
Y dejaron que el uso real hablara
La validación más honesta no es una entrevista
Es alguien usándolo sin que le expliques nada
Ejemplos reales de productos que no se “validaron” como te dicen que lo hagas
Figma
Figma no nació de entrevistas masivas preguntando “¿qué tool quieres?”
Dylan Field tenía una tesis clara: el diseño debía ser colaborativo, en el navegador y en tiempo real
Si hubiera validado eso con diseñadores en 2012, la respuesta habría sido: “Sketch ya funciona” o “eso será lento”
No validaron la solución
Construyeron algo que hacía obvio el valor al usarlo
Stripe
Stripe no preguntó a desarrolladores qué querían en pagos
Observó que todos odiaban integrar pagos y que PayPal era un infierno técnico
La “validación” fue una hipótesis interna: “si lo hacemos absurdamente simple, se usará”
Dos líneas de código bastaron para demostrarlo
No focus groups. Código funcionando
Notion
Notion pasó años sin un mensaje claro de mercado
Durante mucho tiempo, si preguntabas a un usuario qué era Notion, no sabía explicarlo
Eso en validación clásica es una señal roja
En realidad, era una señal de algo más profundo: el producto era flexible, no categorizable.
No se validó una propuesta clara
Se dejó que el uso definiera el producto
Airbnb
Antes de existir Airbnb, la idea de dormir en casa de un desconocido era incómoda
Si lo validas con encuestas, te dicen que no
Lo que sí validaron fue una cosa:
¿alguien paga cuando el producto existe?
Construyeron, alquilaron, cobraron
Eso fue toda la validación necesaria
Superhuman (matiz importante Superhuman es famoso por su “validación obsesiva”)
Pero ojo: no validaban qué construir, sino cómo se sentía usarlo
La visión (email ultra-rápido para power users) nunca se discutió
La experiencia sí
Es justo el límite que casi todos cruzan mal
El patrón que se repite en todos ellos
En ninguno de estos casos:
se pidió permiso para la idea central
se votó la visión
se diseñó por encuesta
Lo común fue:
una hipótesis fuerte
algo construido
uso real como juez
Eso es poca validación externa… y mucha convicción interna
El contexto ha cambiado (y casi nadie lo está asumiendo)
Aquí es donde entra algo clave en 2026
Hoy, construir algo básico es ridículamente fácil
Herramientas como ClaudeCode, Cursor o Windsurf han reducido el coste de pasar de idea a algo funcional a horas, no meses
Incluso con poco conocimiento técnico puedes:
montar un prototipo
probar un flujo real
enseñar algo tangible
Sí:
para cosas complejas sigue haciendo falta criterio técnico
Arquitectura
Decisiones sólidas
Pero el go-to-market inicial es muchísimo menor que hace cinco años
Eso cambia completamente la ecuación:
ya no necesitas “validar” durante meses
puedes construir, mostrar y observar
el producto se convierte en la validación
Y aquí vuelve la idea central:
si el experimento es barato, equivocarte rápido es una ventaja competitiva
Es la lógica detrás de iterar a velocidad absurda en ingeniería (y sí, también en Musk-land):
probar pronto
romper pronto
arreglar con datos
y repetir hasta que sea inevitable que funcione
Hoy, no construir rápido no es prudencia
Es inercia
La pregunta incómoda para cerrar
Antes de pedir otra ronda de feedback, pregúntate esto:
¿Estoy validando para reducir riesgo…
o para evitar comprometerme con una idea?
Porque muchas veces no falta validación
Falta decisión
En la próxima entrega del anti-manual hablaremos de otro error socialmente aplaudido:
por qué contratar rápido suele romper más cosas de las que arregla, incluso cuando “el negocio va bien”
Comparte The Startup Eye para acceder a contenido exclusivo
Actualmente tienes 0 referidos, solo te quedan 1 para conseguir acceso a las Herramientas TOP.
O copia y pega este enlace a otros: https://thestartupeye.com/subscribe?ref=PLACEHOLDER
Gracias por leer
Alek.
Reply