Por qué casi siempre conviene empezar por un MVP.

La tentación, cuando empiezas un producto, es construir todo lo que imaginas antes de enseñarlo. Es comprensible: cuanto más completo, menos vergüenza al mostrarlo. Pero cada función que añades antes de salir es una apuesta sin confirmar — y cuanto más apuestas a ciegas, más tarde descubres qué funcionaba y qué sobraba.

Qué es (y qué no es) un MVP

Un MVP no es una versión a medias ni un prototipo feo. Es la versión más pequeña que resuelve un problema real de principio a fin para un usuario concreto. Si no resuelve el problema, no es mínimo: es incompleto. Si hace diez cosas, no es mínimo: es la versión 2 disfrazada.

La pregunta que lo define no es "¿qué más puedo añadir?" sino "¿qué puedo quitar sin que deje de resolver el problema?".

Por qué empezar pequeño gana casi siempre

• Aprendes con datos, no con opiniones. Diez usuarios reales usando algo te enseñan más que cien reuniones imaginando cómo lo usarían.
• Gastas el presupuesto donde importa. El dinero que no te gastas en la función que nadie pedía es dinero para la que sí.
• Sales antes. Un producto en la calle, aunque pequeño, ya genera conversaciones, feedback y a veces ingresos. Un producto perfecto sin lanzar genera factura de desarrollo.
• Te equivocas barato. Cambiar de rumbo con tres pantallas cuesta una semana; con treinta, cuesta un trimestre.

Cómo lo enfocamos

Antes de escribir código, recortamos el alcance a lo imprescindible: una hipótesis clara ("si hacemos X, el usuario consigue Y"), el camino más corto para probarla, y una forma de medir si funciona. Lo demás — por buena idea que sea — entra en una lista para después. No se descarta; se aparca hasta que los usuarios reales nos digan si hace falta.

Es la misma disciplina que aplicamos en proyectos como ListingOK: resolver primero el núcleo que sí es el producto (el motor de pricing, los conectores) y apoyarse en piezas ya resueltas para todo lo demás, en vez de reconstruir el mundo antes de validar nada.

Cuándo no

Hay excepciones honestas. Si el producto solo aporta valor completo (un sistema de pagos, una integración crítica que o funciona entera o no sirve), "mínimo" significa otra cosa: el mínimo que es fiable, no el mínimo que es pequeño. La regla no es "haz menos por hacer menos"; es "no construyas a ciegas lo que puedes validar antes".

← Volver al Blog