El fallo más común en los servicios de desarrollo de MVP no es construir lo equivocado. Es construir una versión ligeramente más pequeña de todo, descubrir que llevó nueve meses en lugar de tres, y seguir sin saber si la idea funciona.
Esto pasa porque «producto mínimo viable» se lee como «el producto, pero menos». Cada función sobrevive en forma reducida. No se corta nada, solo se adelgaza. El resultado es un sistema que es demasiado amplio para construirse rápido y demasiado superficial para aprender nada definido de él: lo peor de ambas direcciones.
Empieza por la pregunta, no por el producto
Un MVP es un experimento. Los experimentos tienen una hipótesis. Antes de acotar nada, escribe la única frase que este desarrollo existe para responder, en una forma en la que un resultado concreto cambiaría lo que haces después.
«¿Le gustará a la gente?» no es esa frase: ningún resultado cambia ninguna decisión. «¿Subirán los responsables de compras de fabricantes medianos una lista de piezas para obtener un presupuesto, sin que un comercial se lo explique?» sí lo es. Si lo hacen, construyes el embudo de autoservicio. Si no lo hacen, construyes para un proceso de venta asistida. Dos productos de verdad distintos, y una pregunta los separa.
Una vez que la pregunta está escrita, acotar se vuelve mecánico en lugar de político. A cada función propuesta se le pregunta: ¿su ausencia nos impide responder esto? La mayoría de las funciones no pasan esa prueba, y no la pasan de forma visible, que es lo que hace la conversación soportable.
El supuesto más arriesgado primero, no el más fácil
Los equipos secuencian de forma natural hacia lo que saben construir. Eso produce un primer mes cómodo y aplaza toda cosa de verdad incierta al final, donde descubrir un problema es más caro.
Invierte el orden. Lista los supuestos de los que depende la idea, y ordénalos por lo que costaría equivocarse. Luego construye contra el primero de inmediato, en la forma que lo responda más rápido.
- Si el riesgo es si alguien lo quiere, una página de aterrizaje y un presupuesto de anuncios real pueden responder eso en dos semanas por menos de lo que cuesta un sprint.
- Si el riesgo es si el flujo de trabajo encaja con cómo trabaja la gente en realidad, prototipa la interfaz y pásala con ocho usuarios reales: sin backend alguno.
- Si el riesgo es la viabilidad técnica, construye la parte difícil sola sin interfaz. Un script de línea de comandos que demuestra que la precisión de extracción es alcanzable es un MVP, aunque nadie lo llamaría un producto.
- Si el riesgo es si la economía cuadra, el desarrollo puede ser irrelevante. Modélala, y prueba el precio con clientes potenciales reales.
Si puedes responder la pregunta sin construir software, ese es el mejor MVP. El código es la forma cara de aprender algo.
Estrecha el público, no la calidad
Cuando los equipos recortan alcance, suelen recortar el pulido: bordes ásperos, estados que faltan, errores no gestionados. Esto está al revés. Un producto chapucero prueba si la gente tolera la chapuza, lo cual ya sabes que no.
Recorta el público en su lugar. Construye una experiencia de verdad buena para un segmento estrecho, un flujo de trabajo, una geografía. Una herramienta que hace un trabajo de forma excelente para responsables de compras de fabricantes de 50 a 500 empleados te dirá algo real. Una herramienta que hace nueve trabajos de forma aceptable para todos no te dice nada, porque no puedes atribuir el resultado.
El corolario importa para la ingeniería: un alcance estrecho justifica calidad real dentro de ese alcance. La gestión de errores, la accesibilidad y una interfaz coherente no son adornos de lujo en un MVP: son lo que hace la señal fiable. Lo que te saltas es la amplitud.
Acuerda el continuar/parar antes de empezar
Fija el umbral que mataría la idea, por escrito, antes del primer commit. No «ya veremos cómo va»: un número real y una fecha real. «Si menos del 15% de los usuarios invitados completa una subida en cuatro semanas, paramos.»
Este es el paso que más se salta y el que más fiablemente predice si un MVP produce una decisión. Escritos después, los umbrales se ajustan en silencio a lo que haya salido. Escritos antes, son un compromiso hecho por gente que todavía no sabía en qué dirección iría, que es la única vez que un umbral significa algo.
Incluye qué harás en cada rama. Un «no» sin una alternativa definida no es un punto de decisión; es una invitación a seguir por inercia.
Construye sobre cimientos que sobreviven a un «sí»
Una tensión real: los prototipos desechables son más rápidos, pero aproximadamente la mitad de los MVP tienen éxito, y un desechable con éxito se convierte en un sistema de producción por accidente. Nadie consigue nunca el trimestre de reescritura.
Nuestro enfoque es un stack de nivel de producción con una superficie deliberadamente diminuta. Framework real, canal de despliegue real, pruebas reales alrededor de la única ruta que importa, pero solo una ruta. Eso cuesta quizá un 15% más que un desechable y elimina la reescritura por completo si la respuesta es sí. La excepción es una prueba de viabilidad pura, donde el artefacto de verdad es desechable y todos acuerdan por adelantado que lo es.
Cómo es una buena acotación sobre el papel
Un MVP bien acotado cabe en una página: la pregunta, el supuesto más arriesgado, el público estrecho, el desarrollo más pequeño que lo prueba, el umbral de continuar/parar con una fecha, y qué pasa en cada rama. Si no cabe en esa página, no está acotado todavía: es un plan de producto disfrazado de MVP, y llevará tres veces más de lo que nadie ha presupuestado.
