Cómo Definir el Alcance de Tu MVP (Sin Construir Demasiado)
El error más costoso en el desarrollo de apps no es una mala elección tecnológica o una mala contratación. Es construir demasiado antes de averiguar si alguien quiere lo que estás construyendo.
El antídoto es un proceso riguroso de definición del alcance del MVP. Aquí está el que funciona.
Comienza con el trabajo principal
Escribe una frase: "Mi app ayuda a [tipo específico de persona] a [lograr un resultado específico] cuando [contexto específico]."
Si no puedes escribir esa frase, no estás listo para definir el alcance. Si puedes escribirla, cada decisión de funcionalidad se convierte en una pregunta de: ¿esto ayuda con ese resultado específico, o no?
Ejemplos: - "Mi app ayuda a los entrenadores personales independientes a rastrear el progreso de entrenamiento de los clientes entre sesiones." - "Mi app ayuda a los propietarios de restaurantes pequeños a gestionar la programación de turnos sin usar grupos de WhatsApp." - "Mi app ayuda a los propietarios de propiedades en alquiler a generar informes de inspección profesionales en menos de 10 minutos."
El recorrido principal del usuario
Mapea la secuencia mínima de pasos que un usuario debe seguir para completar el trabajo principal exactamente una vez. No un usuario avanzado, no un caso extremo: el camino absolutamente mínimo viable.
Para el ejemplo del entrenador personal: el entrenador crea el perfil del cliente → el entrenador asigna el entrenamiento → el cliente registra el entrenamiento → el entrenador revisa el entrenamiento completado.
Ese es el recorrido principal. Todo lo demás (notificaciones, funcionalidades sociales, gráficos de progreso, biblioteca de ejercicios, seguimiento nutricional) es candidato para la versión 2. No porque esas funcionalidades sean malas ideas, sino porque no son necesarias para probar si tu propuesta de valor principal funciona.
La auditoría de funcionalidades
Lista cada funcionalidad en tu lista de funcionalidades actual. Para cada una, pregunta:
- ¿Está en el recorrido principal del usuario? (Si es así: obligatoria)
- ¿El recorrido principal del usuario falla o se vuelve complicado sin esto? (Si es así: obligatoria)
- ¿Es esto algo que los usuarios pueden hacer de otra manera por ahora? (Si es así: posponer)
- ¿Es esta infraestructura que habilita funcionalidades principales? (Autenticación, pagos, obligatoria)
Cualquier cosa que no supere las preguntas 1, 2 o 4 debe marcarse explícitamente como "v2" y eliminarse del documento de alcance que le des a tu desarrollador.
Prevención del aumento del alcance
El aumento del alcance ocurre porque: (a) los fundadores añaden funcionalidades a medida que las piensan durante el desarrollo, y (b) los desarrolladores añaden funcionalidades porque creen que están siendo útiles.
Prevénlo con una regla simple: cualquier funcionalidad que no esté en el documento de alcance firmado requiere una solicitud de cambio por escrito con un coste estimado e impacto en el plazo antes de que comience cualquier trabajo. Esto crea fricción que filtra las adiciones impulsivas de las adiciones genuinamente importantes.
¿Qué tan pequeño debe ser realmente tu MVP?
Más pequeño de lo que crees. Los fundadores que lanzan más rápido y aprenden más están construyendo rutinariamente apps que su visión inicial habría considerado embarazosamente simples.
Referencia: si tu MVP puede describirse en un solo párrafo y construirse en menos de 10 semanas por un desarrollador, probablemente estás en el rango correcto. Si la estimación de tu desarrollador supera los 4 meses, recorta el alcance hasta que no sea así.
El objetivo de un MVP no es impresionar a la gente. Es averiguar si la hipótesis central es verdadera. Esa prueba casi siempre puede ejecutarse con menos de lo que crees.
Cómo eran en realidad los mejores MVP
La parte más difícil de definir el alcance es creer que "menos" puede funcionar. Por eso conviene mirar con qué lanzaron en realidad algunas de las apps de más éxito. Ninguna empezó siendo el producto pulido que conoces hoy.
Dropbox vendió la idea antes de construirla
Dropbox es una herramienta para sincronizar archivos. Construir una que funcione de forma fiable en varios dispositivos es ingeniería genuinamente difícil. Los fundadores no querían pasar meses construyendo el producto completo solo para descubrir que a nadie le importaba.
Así que en 2007 su fundador, Drew Houston, hizo algo más sencillo. Grabó un vídeo corto de captura de pantalla que mostraba cómo funcionaría Dropbox: dejas un archivo en una carpeta y lo ves aparecer en otro ordenador. El vídeo enseñaba la experiencia, no un producto terminado detrás de ella. Lo publicó en una comunidad de usuarios pioneros.
La respuesta le dijo que la gente lo quería. La lista de espera para la beta creció enormemente de un día para otro. Houston ha hablado de esto en público muchas veces, y se ha convertido en uno de los ejemplos más citados de cómo probar la demanda antes de construir.
La lección para ti: tu MVP no siempre tiene que ser una app funcional. A veces la prueba válida más barata es un vídeo, una página de aterrizaje o un prototipo donde se pueda hacer clic y que muestre lo que hará la app. Si la gente se registra, reserva por adelantado o se apunta a una lista de espera, tienes evidencia. Si no lo hace, acabas de ahorrarte meses de desarrollo.
Airbnb lo hizo todo a mano primero
Antes de ser una plataforma global, Airbnb eran dos fundadores con colchones inflables.
En 2007, Brian Chesky y Joe Gebbia no podían pagar el alquiler en San Francisco. Llegaba a la ciudad un gran congreso de diseño y los hoteles estaban llenos. Montaron una web sencilla que ofrecía un sitio para dormir sobre colchones inflables en su piso, con desayuno incluido. La llamaron "Air Bed and Breakfast". Algunos huéspedes pagaron y se quedaron de verdad.
Esa fue la primera prueba. Sin sistema de reseñas, sin reserva instantánea, sin infraestructura de pagos, sin mapas, sin panel para anfitriones. Solo una página básica y dos fundadores haciéndolo todo a mano.
A esto se le suele llamar MVP de conserjería: en lugar de construir software para automatizar un proceso, haces el trabajo a mano para tus primeros usuarios. Aprendes lo que la gente necesita de verdad sirviéndola directamente y luego construyes software solo para las partes que demuestran que merece la pena automatizar.
Para un fundador sin perfil técnico, esto es liberador. A menudo puedes probar tu idea central con una hoja de cálculo, unos cuantos correos, un formulario sencillo y tu propio esfuerzo, mucho antes de pagar a nadie para escribir código. La versión manual te enseña qué construir. Y además te consigue clientes reales y dinero real mientras aprendes.
Instagram lanzó con una sola cosa
Instagram hoy tiene mensajería, vídeo, compras, reels, historias y más. Cuando se lanzó en octubre de 2010 no tenía casi nada de eso.
La primera versión hacía tres cosas: hacer una foto, aplicar un filtro y compartirla. No había mensajería directa en el lanzamiento (Instagram Direct llegó a finales de 2013). No había historias (esas llegaron en 2016). Ni vídeo. Ni mensajes privados, ni compras, ni anuncios.
En realidad, los fundadores habían empezado con un producto más complicado, una app para registrar ubicaciones con muchas funciones. Recortaron casi todo lo demás y se quedaron con lo único que la gente más usaba: compartir fotos que se veían bien. A ese enfoque se le atribuye ampliamente que la app creciera tan rápido en sus primeros días.
La lección: un gran MVP suele salir de recortar una idea existente, no de añadir a una sencilla. Si tu lista de funciones parece una navaja suiza, encuentra la única hoja que la gente usará primero y lanza eso.
Cómo presentar los recortes de alcance a quienes se resisten
Recortar el alcance es fácil sobre el papel. Se complica cuando un socio, un inversor o un asesor insiste en que una función es "imprescindible". Así puedes manejar esa conversación sin pelear.
Replantea el recorte como ordenar, no como eliminar. No estás matando la función. Estás decidiendo qué va primero. El lenguaje importa. "Vamos a quitar el chat dentro de la app" suena a pérdida. "El chat va en la versión 2, después de confirmar que la gente usa el flujo de reserva principal" suena a plan. Mantén una "lista v2" visible para que nadie sienta que su idea se tiró a la basura.
Conecta cada función con el trabajo principal y con el presupuesto. Lleva a la reunión la frase del trabajo principal del comienzo de este artículo. Para cada función en disputa, haz una pregunta en voz alta: ¿esto ayuda a probar si funciona el trabajo principal? Si no es así, no forma parte de la prueba. Luego muestra el coste. Cada función extra tiene un precio en euros y en semanas, y retrasa el día en que recibes feedback real.
Usa los ejemplos anteriores como respaldo. Cuando una empresa respetada hizo primero lo sencillo, tu decisión gana una autoridad que tu opinión por sí sola no tiene. "Instagram se lanzó solo con fotos y filtros" es una frase que termina muchas discusiones.
Ofrece una regla de decisión en lugar de un debate. Propón esto: todo lo que no sea necesario para el recorrido principal del usuario pasa a la lista v2, y revisamos la lista completa la semana siguiente al lanzamiento con datos de uso reales. Esto mueve la conversación de "qué opinión gana" a "qué nos dirán los datos". La mayoría de personas razonables aceptarán una regla que promete una respuesta pronto.
Haz concreto el riesgo. El verdadero peligro no es lanzar sin una función. Es gastar todo el presupuesto, lanzar tarde y descubrir que la idea central nunca funcionó. Dilo con claridad. Un lanzamiento más pequeño y más rápido es la forma de proteger el dinero y el tiempo de todos, incluido el de ellos.
Los fundadores de Dropbox, Airbnb e Instagram no fueron más valientes que tú. Solo fueron disciplinados a la hora de probar una cosa primero. Tú también puedes serlo.