Cómo definir el alcance de un MVP: reduzca su primera versión a lo que de verdad importa

Casi todo el que viene a nosotros con una idea de app ya ha construido la versión completa en su cabeza. Pueden describir el panel, la página de ajustes, el programa de referidos, el modo oscuro. Lo que normalmente no saben decir es qué parte concreta de esa imagen, si funcionara, haría que todo el conjunto mereciera la pena. Definir el alcance de un MVP es el trabajo poco glamuroso y algo doloroso de encontrar esa única parte, y de tener el valor de dejar el resto para más adelante.

He visto construirse muchos primeros productos, y los que tienen dificultades casi nunca fracasan porque el equipo fuera perezoso. Fracasan porque el alcance estuvo mal desde la primera semana. Se metió demasiado en la versión uno, el presupuesto se agotó antes de que nadie aprendiera nada y, al llegar el lanzamiento, el equipo lo había gastado todo solo en llegar a la línea de salida, sin dinero para reaccionar a lo que los usuarios reales hacían en realidad.

Así que esta es la guía que doy a la gente antes de escribir una sola línea de código. No va de rituales ágiles ni de marcos de trabajo sofisticados. Va de una pregunta honesta — ¿qué es lo más pequeño que podemos construir para saber si esta idea es real? — y de la disciplina de seguir respondiéndola mientras la tentación de añadir ‘solo una función más’ vuelve a aparecer. Porque siempre vuelve a aparecer.

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

La expresión está tan desgastada por el uso que conviene ser precisos. Un producto mínimo viable es la versión más pequeña de su idea que aporta valor real a un usuario real y le enseña algo que jamás habría aprendido de una presentación de diapositivas. La palabra clave que la gente olvida es viable. Tiene que funcionar de verdad para alguien, de principio a fin, aunque solo haga una cosa.

Esto es lo que un MVP no es. No es una versión a medio hacer del producto completo con esquinas rotas por todas partes. No es un prototipo que se tira. Y desde luego no es ‘la versión barata’: lo barato es un efecto secundario de un buen alcance, no el objetivo. El objetivo es aprender. Está gastando el mínimo dinero posible para responder a la pregunta más cara que tiene: ¿lo usará alguien, y lo usará como yo creo?

Esa distinción pesa más de lo que parece. La mentalidad del ‘primer 20 %’ lleva a algo que está roto en todas direcciones y no sirve en ninguna. ‘Una cosa, bien hecha’ lleva a algo que una persona puede coger, usar de verdad y tener una opinión al respecto. Las opiniones son el objetivo entero. Sobre el silencio no se puede iterar.

La trampa de construir de más, y por qué es tan fácil caer en ella

Nadie se propone excederse en el alcance. Ocurre una decisión razonable tras otra. Añade el inicio de sesión, porque claro que necesita cuentas. Las cuentas implican un flujo para restablecer la contraseña, una verificación por correo y una página de ajustes. Los ajustes implican un perfil, que implica subir imágenes, que implica un sitio donde guardarlas. Cada paso es sensato por sí solo. Apilados, ha gastado dos meses y parte del presupuesto antes de empezar siquiera la parte que hace especial su idea.

La otra mitad de la trampa es emocional. Recortar funciones se siente como admitir que su idea es pequeña. No lo es: es admitir que aún no sabe qué funciones importan, lo cual es sencillamente la verdad. Cada función que construye antes de tener usuarios es una apuesta a ciegas. Algunas serán erróneas, y las que recorta del MVP son las apuestas más baratas en las que equivocarse, porque nunca las hizo.

Encuentre la única tarea que su MVP debe cumplir

Todo producto, por grande que llegue a ser, tiene un bucle central: la única secuencia que un usuario repite y que genera el valor. En una app de reservas es encontrar un hueco, reservarlo, recibir un recordatorio. En un marketplace es publicar algo, alguien lo encuentra, el dinero cambia de manos. En una herramienta interna es capturar el dato una vez, usarlo en todas partes. Todo lo demás del producto existe para apoyar, decorar o ampliar ese bucle. Su MVP es el bucle. Solo el bucle.

Para encontrar el suyo, complete esta frase en voz alta: «Un usuario viene a mi producto para ______, y queda satisfecho si ______.» El primer hueco es la tarea. El segundo es cómo sabrá que funcionó. Si no puede llenar ambos huecos de un tirón, aún no ha encontrado el núcleo, y no está listo para definir el alcance, y mucho menos para construir.

Sea implacable con la diferencia entre el bucle central y las cosas que parecen esenciales pero no lo son. El inicio de sesión parece esencial. Normalmente no lo es en la versión uno: muchos MVP se lanzan con un solo enlace compartido, una invitación manual o sin cuentas, y aprenden todo lo que necesitan antes de construir la maquinaria de autenticación. Los paneles de analítica parecen esenciales. No lo son; puede leer la base de datos a mano cuando tiene once usuarios. Reduzca al bucle y se asombrará de cuánto desaparece.

Clasifique cada función en debe, debería y no va

Una vez nombrado el bucle central, coja su gran lista de funciones y clasifique cada una en tres cubos. Los cubos son deliberadamente tajantes, porque lo tajante es lo que detiene las interminables conversaciones de ‘pero quizá’.

• Debe: el bucle central literalmente no funciona sin ella. Si la quita, no hay producto. Mantenga esta lista asombrosamente corta, normalmente de tres a seis elementos.
• Debería: mejora el producto, pero el bucle sigue funcionando sin ella. Todo lo de aquí espera a la versión dos. Sin excepciones en la primera versión.
• No va (todavía): las funciones que conscientemente elige no construir ahora. Anotarlas importa: así se tranquiliza usted, y su equipo, de que la idea no se abandona, solo se secuencia.

El truco que hace que esto funcione es el tercer cubo. La mayoría solo discute entre debe y debería, lo cual es agotador y nunca termina. La lista de ‘no va todavía’ es donde reside el alivio: es una promesa a su yo futuro de que la idea genial está a salvo y planificada, solo que no ahora. Cuando la gente confía en que nada se tira, deja de pelear por mantenerlo todo en la versión uno.

Defina el alcance por tiempo y dinero, no por lista de funciones

Hay un cambio silencioso que lo transforma todo: deje de definir el alcance por ‘qué queremos’ y empiece a definirlo por ‘qué cabe en el presupuesto y el plazo’. Decida primero cuánto dinero y cuántas semanas está dispuesto a gastar para responder a su pregunta central. Luego haga que la lista de funciones quepa dentro de esa caja. Suena al revés, pero es la restricción más útil que puede imponerse, porque fuerza la priorización que de otro modo evitaría.

Una caja fija también hace algo psicológico. Cuando el presupuesto es abierto, toda función es discutible y la lista solo crece. Cuando la caja es fija —digamos, ocho semanas y una cantidad determinada—, la conversación se invierte. Deja de ser ‘¿deberíamos añadir esto?’ y pasa a ser ‘¿qué sale si esto entra?’. Esa segunda pregunta es la que construye buenos MVP. Los compromisos se ven en vez de ocultarse, y el equipo los toma a propósito.

Un ejemplo real: reducir el alcance de una idea de gestión de trabajos

Permítame concretarlo con un caso en el que trabajamos —anonimizado, pero fiel a cómo van estas cosas—. Una pequeña empresa de calefacción y fontanería vino a nosotros queriendo una app para su equipo de campo. El encargo, sobre el papel, era enorme: planificación de trabajos en vivo, seguimiento por GPS de las furgonetas, un portal de clientes, facturación automatizada, inventario de las piezas en cada vehículo, un generador de presupuestos, documentación fotográfica y un conjunto de informes para el propietario. Un producto genuinamente útil, con el tiempo. Como primera versión, una forma garantizada de gastar el presupuesto de un año antes de aprender nada.

Así que hicimos el ejercicio. Le planteamos al propietario la frase: ‘Un usuario viene a esto para ______, y queda satisfecho si ______.’ Tras algunas idas y venidas, salió a la luz la respuesta real. El mayor dolor diario de los técnicos no era la planificación ni la facturación: era el ir y venir del papeleo. Terminaban un trabajo, garabateaban horas y piezas en una hoja, conducían de vuelta y alguien en la oficina lo retecleaba todo en el sistema de contabilidad, a menudo días después, a menudo con errores. El bucle central era simplemente: capturar lo que pasó en el trabajo, una sola vez, en el sitio, para que nadie lo reteclee.

Qué entró en el corte y qué no

Se clasificó todo. El cubo debe se redujo a cuatro cosas: una lista de los trabajos del día para cada técnico, un formulario sencillo para registrar horas y piezas usadas por trabajo, un adjunto de foto y una forma de que la oficina viera esos datos en el momento en que se enviaban. Ese era todo el MVP. Sin GPS, sin portal de clientes, sin generador de presupuestos, sin informes sofisticados: todo aparcado, explícitamente, en la lista de ‘no va todavía’ con una nota de que llegaría.

Construimos ese núcleo en unas pocas semanas en lugar de en buena parte de un año. Y aquí está la parte que justifica todo el enfoque: una vez en marcha, las prioridades reales del equipo resultaron diferir del encargo. El propietario había supuesto que el seguimiento por GPS sería lo siguiente; los técnicos apenas lo mencionaron. Lo que querían, a voces, era enviar al cliente por mensaje una franja de llegada desde dentro de la app, una función que ni siquiera estaba en la lista original. Como el MVP era pequeño y barato, quedó presupuesto para construir lo que de verdad querían, en lugar de lo que habían supuesto meses antes.

Los errores que arruinan en silencio el alcance de un MVP

Hasta los equipos que asumen ‘mantenlo pequeño’ tienden a tropezar con las mismas pocas cosas. Ninguna es dramática. Son fugas lentas que vuelven a inflar el alcance mientras usted no mira, hasta que un día el producto ‘mínimo’ tiene treinta pantallas y un plazo de seis meses otra vez.

• Pulir los bordes en exceso: pasar días perfeccionando un panel de administración que solo usted verá, mientras el bucle central sigue tosco. Pula lo que tocan los usuarios; deje la trastienda fea y funcional.
• Construir para una escala que no tiene: diseñar la arquitectura para un millón de usuarios cuando necesita demostrar que los primeros diez volverán. Resuelva el problema de escala cuando tenga el buen problema de la escala.
• Confundir ‘imprescindible’ con ‘estándar del sector’: que todo competidor tenga la función X no significa que su MVP la necesite para probar su idea central. No está lanzando un producto terminado, está haciendo un experimento.
• Diseñar de antemano todos los casos límite: manejar las entradas raras e infrecuentes antes de saber si alguien usa el camino común y normal. Deje que el uso real le diga qué casos límite son siquiera reales.
• Sin definición de hecho: sin una línea escrita que describa cómo es ‘terminado’, la construcción no acaba nunca. La expansión del alcance adora un proyecto sin línea de meta.

Si solo se protege de uno de estos, que sea el último. Una definición de hecho clara y escrita —‘un técnico puede registrar las horas y piezas de un trabajo en su móvil, y la oficina lo ve al instante’— es la herramienta más poderosa para mantener el alcance honesto. Cada añadido propuesto se contrasta con esa frase. Si no sirve a la frase, es una idea de versión dos, por buena que sea.

Un proceso sencillo para definir el alcance de su MVP

Recapitulando, esta es la secuencia que recorrería con cualquiera antes de empezar una primera versión. Es deliberadamente sencilla: gran parte puede hacerla con un documento y una conversación honesta, mucho antes de necesitar a un desarrollador en la sala.

1. 1
   Nombre el bucle central

   Complete la frase: ‘Un usuario viene a ___, y queda satisfecho si ___.’ Si no puede, no está listo para definir el alcance: siga hablando hasta que la verdadera tarea aflore.
2. 2
   Vuelque cada función y luego clasifique

   Saque toda la lista de deseos de su cabeza al papel. Clasifique cada elemento en debe, debería o no-va-todavía. Mantenga la lista de ‘debe’ brutalmente corta.
3. 3
   Fije la caja

   Decida el presupuesto y el plazo antes de cerrar la lista de funciones. Haga que la lista quepa en la caja, no al revés.
4. 4
   Escriba la definición de hecho

   Una frase concreta que describa el bucle central en funcionamiento. Es su escudo contra la expansión del alcance durante el resto del proyecto.
5. 5
   Construya, lance, observe y luego decida

   Ponga el núcleo ante usuarios reales. Observe qué hacen de verdad. Deje que su comportamiento —no sus suposiciones previas— elija qué sale a continuación de la lista de ‘debería’.

Fíjese en que el último paso le devuelve al principio. Un buen MVP no es un evento único, es la primera vuelta de una rueda. Define un alcance pequeño, lanza, aprende, y lo que aprende redefine el alcance de la siguiente versión. Los equipos que ganan no son los que planificaron el producto perfecto de antemano —nadie hace eso—. Son los que pusieron algo real ante los usuarios lo bastante rápido como para que la realidad aún pudiera guiarlos.

Preguntas frecuentes