Cuando alguien tiene una idea de software, el impulso natural es empezar a construir. Contratar programadores, diseñar pantallas, agregar funciones. Se siente como avanzar. Y, según los datos, es la forma más común de perder tiempo y dinero.
El problema casi nunca es la idea: es el orden. La mayoría de los proyectos no mueren por falta de funciones, sino por resolver un problema que nadie tenía. La herramienta para no caer en eso tiene un nombre feo y un concepto simple: producto mínimo viable.
La creencia: primero construyo y después veo si sirve
La lógica parece razonable: para saber si a la gente le gusta mi producto, necesito tener el producto. Pero eso invierte el orden correcto. Primero hay que comprobar que el problema existe; recién después tiene sentido construir la solución completa.
Los números de fracaso apuntan en la misma dirección. Un análisis de CB Insights sobre cierres de empresas encontró que la causa principal no es la falta de dinero, sino el producto: 43% de los casos se explica por una mala adaptación al mercado (y en el análisis clásico de 2014, 42% por “falta de necesidad en el mercado”). Quedarse sin caja suele ser el final, no el motivo. Y el servicio de estadísticas laborales de Estados Unidos calcula que cerca de 48% de los emprendimientos no llega a los cinco años.
Construir primero y validar después es, en el mejor de los casos, caro. En el peor, es construir durante meses algo que nadie va a usar.
Qué es (y qué no es) un producto mínimo viable
La definición clásica, de Eric Ries, es precisa: es la versión de un producto que permite obtener la mayor cantidad de aprendizaje validado con el menor esfuerzo. En otras palabras: aprender con hechos, no con opiniones, gastando lo mínimo. La palabra clave es aprendizaje, no producto.
Un producto mínimo viable no es una versión barata y mal hecha del producto final. Es el experimento más pequeño que responde a la pregunta más riesgosa de tu idea. Tampoco es un prototipo: un prototipo sirve para mostrar una idea, mientras que un producto mínimo viable sirve para medir el comportamiento real de la gente. Que alguien diga “qué buena idea” no vale; que se registre, vuelva o pague, sí.
Eso obliga a definir una cosa antes de escribir código: qué necesito aprender. ¿Existe el problema? ¿La solución interesa? ¿El usuario actúa? Sin esa pregunta, el mínimo no tiene sentido.
El dato incómodo: la mayoría de las funciones no se usan
Hay un dato que se repite en todas las charlas: “64% de las funciones de un software nunca se usan”. Conviene saber de dónde sale antes de repetirlo. Proviene de una presentación del Standish Group en 2002, y —esto casi siempre se omite— se basaba en apenas cuatro aplicaciones internas, ninguna comercial.
El dato más sólido y reciente viene de otro lado: un análisis de la plataforma Pendo (2019) sobre cientos de productos encontró que 80% de las funciones se usan poco o nunca, y que 12% de las funciones concentran 80% del uso. La lección es la misma y es incómoda: si construís de más antes de validar, lo más probable es que la mayor parte de ese trabajo no se use. Por eso el producto mínimo viable no es una versión reducida del producto final: es la parte que sí importa.
Tres formas de validar sin construir el producto
Los ejemplos más conocidos son valiosos porque muestran que el experimento puede ser muchísimo más barato que el producto.
- Dropbox no construyó nada al principio: hizo un video de tres minutos que explicaba el servicio, lo publicó y midió el interés. La lista de espera pasó de 5.000 a 75.000 personas en un día. Antes de escribir el producto, ya sabía que había demanda.
- Zappos vendía zapatos por internet sin tener stock: el fundador iba al shopping, fotografiaba los modelos y, cuando alguien compraba, los compraba y los enviaba él mismo. Así validó que la gente se animaría a comprar calzado sin probárselo.
- Buffer empezó con una simple página que mostraba los precios y pedía el correo. No había producto todavía: estaba midiendo si la gente estaría dispuesta a pagar.
Ninguno de los tres empezó por el software. Empezaron por la pregunta.
Cómo se ve un producto mínimo viable, según el riesgo
No hay una sola forma. La regla es simple: el experimento debe ser lo más barato que pueda responder tu pregunta más riesgosa.
| Si el riesgo es… | El experimento suele ser… | Tiempo y costo aprox. |
|---|---|---|
| Que el problema no exista o no interese | Página que presenta el producto, video, encuesta a clientes reales | 1-3 semanas, muy bajo |
| Que nadie sepa usarlo | Una porción del producto que ya funcione | 4-8 semanas, bajo-medio |
| Que no quieran pagar | Venta anticipada, servicio hecho a mano por una persona | Depende del caso |
Las franjas de tiempo y costo son estimaciones de la industria y varían según el proyecto. Lo importante es el criterio: no construyas una aplicación para responder una pregunta que una página resuelve.
Los errores que arruinan un producto mínimo viable
Los tropiezos se repiten:
- Construir de más. Agregar funciones “por las dudas” infla el costo y retrasa el aprendizaje, que era el único objetivo.
- Complicar de más. Montar una estructura para millones de usuarios cuando todavía no hay cien.
- Confundir “mínimo” con “mal hecho”. La calidad de lo poco que mostrás importa: es tu única oportunidad de causar buena impresión.
- Validar con opiniones. Preguntarle a amigos y familiares da respuestas amables, no datos. El comportamiento (registrarse, repetir, pagar) es el que cuenta.
- No lanzar. Un producto mínimo viable que se queda en el cajón no enseña nada.
Por qué importa especialmente en Paraguay
En Paraguay, las micro, pequeñas y medianas empresas son 98% del tejido empresarial, y la mayoría maneja presupuestos ajustados. En ese contexto, construir de más no es un lujo malgastado: es el riesgo principal. Un emprendedor que gasta seis meses y todo su capital en el producto completo, sin validar antes, se queda sin margen para corregir.
La ventaja local es que el primer experimento puede ser casi gratis. Si tus clientes viven en WhatsApp, podés atender a mano las primeras consultas, tomar pedidos por mensaje y medir cuántos vuelven antes de invertir en un sistema. El canal que ya usás es, muchas veces, el mejor laboratorio.
Un test de tres preguntas antes de invertir
- ¿Qué es lo más riesgoso de tu idea: que exista el problema, que sepan usarla, o que quieran pagar?
- ¿Cuál es la forma más barata de responder eso? ¿De verdad hace falta código?
- ¿Qué número o comportamiento concreto te haría seguir adelante… o frenar?
Si podés responder esas tres, ya tenés el alcance de tu producto mínimo viable. Si no, todavía no estás listo para construir.
En YP Software ayudamos a definir ese alcance y construimos solo lo necesario para validar. Preferimos un experimento chico que te diga la verdad antes que un desarrollo grande que te deje sin presupuesto. Conversemos sobre tu idea.
Fuentes
- Causas de fracaso de emprendimientos: CB Insights y SegmentOS.
- Uso real de funciones (80% poco o nunca usadas; 12% concentra el 80%): Ant Murphy (datos de Pendo).
- El origen del “64%” y su límite: Mike Cohn / Mountain Goat Software.
- Definición de producto mínimo viable: Eric Ries, citado en Wikipedia.
- Ejemplos y tipos: Hostinger y Attract Group.
- Franjas de tiempo y costo: HubSpot.
- Pequeñas y medianas empresas en Paraguay (98% del tejido): MIC.
(Aclaración: las franjas de tiempo y costo son estimaciones generales de la industria y dependen de cada proyecto. El dato del “64%” se cita con frecuencia fuera de contexto; en esta entrada se explica su alcance real.)