Casi todos los founders que llegan a Cambalache Studio con una idea nueva quieren lo mismo: el producto completo, con todas las funcionalidades que se imaginaron durante meses, listo para lanzar. Es una reacción lógica — si tenés clara la idea, ¿para qué construir "menos"? El problema es que esa lógica descansa en un supuesto que casi nunca se cumple: que lo que el fundador imaginó en su escritorio es exactamente lo que el mercado necesita.
Ese es el error de fondo que vemos una y otra vez, y esta nota es para el founder que todavía no está convencido de que necesita achicar el alcance antes de construir.
El error de fondo: construir todo lo que imaginaste, sin probar nada antes
Cuando una idea lleva meses (o años) dando vueltas en la cabeza, se vuelve muy concreta ahí adentro: la lista de features crece, el flujo de usuario se pule en la imaginación, y llega un punto en que parece que "ya está todo pensado, solo falta construirlo".
Ese es exactamente el momento de mayor riesgo. Porque todo lo que se pensó, se pensó sin un usuario real enfrente. Ninguna cantidad de research adentro de la cabeza del fundador reemplaza lo que pasa cuando alguien real, con su plata y su tiempo en juego, usa el producto por primera vez. Casi siempre aparecen sorpresas: features que nadie toca, un flujo que confunde donde en la imaginación era obvio, un problema que en realidad no dolía tanto como se pensaba.
Construir el producto completo antes de tener esa evidencia es apostar meses de desarrollo a que el fundador acertó en todo desde el escritorio. A veces pasa. La mayoría de las veces, no — y ahí es donde se pierde la plata.
Qué es un MVP, sin vueltas
Un MVP (producto mínimo viable) es la versión más chica de tu producto que ya le resuelve el problema central a un usuario real — lo suficiente como para que lo use o pague por él de verdad. No es una versión incompleta a medias ni una demo linda: es un recorte deliberado que hace una sola cosa bien, para aprender si tu idea funciona antes de invertir en construir todo lo demás.
La pregunta que responde un MVP no es "¿me gusta cómo quedó?". Es "¿alguien, con su plata o su tiempo real en juego, elige usar esto en vez de la alternativa que ya tenía?".
El riesgo real de saltearlo
El riesgo no es abstracto, es muy concreto: pasar entre seis y doce meses construyendo un producto con todas las funcionalidades imaginadas, gastando la plata del fundador o de los inversores, para descubrir recién en el lanzamiento que nadie lo quiere tal como está.
En ese escenario ya no queda margen para pivotar con calma. El equipo se armó pensando en un producto grande, los costos fijos corrieron durante todo ese tiempo, y la corrección que hubiera costado una semana de trabajo sobre un MVP ahora implica rehacer meses de código y de decisiones de arquitectura. Es la forma más cara de fracasar en desarrollo de producto: no por mala ejecución, sino por validar demasiado tarde, con la plata y el tiempo ya gastados.
Cuándo SÍ tiene sentido saltear el MVP (o achicarlo mucho más)
Esto no es un dogma. Hay situaciones reales donde construir en grande desde el principio es la decisión correcta:
- Ya validaste la demanda por otro lado. Tenés una lista de espera larga, preventas reales, o un negocio análogo (offline, manual, en otro mercado) que ya probó que la gente paga por esto.
- Es una feature nueva de un producto que ya tiene usuarios. Si ya tenés una base activa y le agregás una funcionalidad, no estás validando una idea de cero — estás iterando sobre algo que ya funciona, y podés apoyarte en esos usuarios para medir el impacto rápido.
- No es una idea nueva, es una réplica con ejecución superior. Si el mercado ya demostró que el modelo funciona (hay competidores con tracción real) y tu apuesta es ejecutarlo mejor, la incógnita no es "¿existe demanda?" sino "¿puedo ejecutar mejor?" — ahí el MVP sigue teniendo sentido, pero puede ser bastante más chico y más rápido.
Fuera de esos casos, saltear el MVP es apostar a que acertaste sin tener ninguna evidencia todavía.
¿Necesitás un MVP? Cuatro preguntas para saber
| Pregunta | Si la respuesta es NO |
|---|---|
| ¿Ya tenés usuarios reales pidiendo esto activamente? | Necesitás un MVP |
| ¿Podés validar la demanda sin código (landing, preventa, lista de espera)? | Necesitás un MVP |
| ¿Es una funcionalidad nueva sobre un producto que ya tiene usuarios y uso real? | Necesitás un MVP |
| ¿Existe ya un modelo de negocio probado en el mercado que estás replicando? | Necesitás un MVP |
Si respondiste que no a la mayoría, no es una señal de alarma — es la situación más común de todas. Simplemente significa que el paso que sigue es un MVP, no el producto completo.
Qué aprendés de un MVP bien hecho, más allá de "si funciona"
La pregunta binaria — "¿funcionó o no?" — es la menos interesante de las que un MVP responde. Lo que de verdad justifica la plata invertida es lo específico:
- Qué features usan de verdad. Casi siempre hay una o dos funcionalidades que concentran el uso real, y varias que el fundador consideraba "imprescindibles" que casi nadie toca.
- Qué le confunde a un usuario real. Un flujo que en la cabeza (o en Figma) se entendía perfecto, en producción genera fricción en un paso puntual que nadie había anticipado.
- Qué está dispuesto a pagar, y por qué exactamente. No alcanza con saber que alguien paga — importa saber si paga por la funcionalidad central que imaginaste, o por algo secundario que terminó siendo el verdadero valor percibido.
Esa información redefine el roadmap del producto completo con datos reales, en vez de con las mismas suposiciones con las que arrancaste el proyecto.
Conclusión
Querer el producto completo desde el día uno es una reacción natural cuando la idea ya está clara en tu cabeza — el problema es que "clara para vos" no es lo mismo que "validada con usuarios reales". Un MVP no es una versión inferior del producto que soñaste: es el paso que te dice, con evidencia real y antes de gastar meses de desarrollo, si ese sueño coincide con lo que el mercado necesita. Si todavía no sabés si tu idea tiene demanda real, el paso previo al MVP es validar la idea; y si ya tenés esa validación pero te confunden los términos "MVP", "prototipo" y "producto completo", conviene revisar en qué se diferencian los tres antes de definir el alcance.