Qué debería —y qué no— incluir su MVP de SaaS en el lanzamiento

La palabra «mínimo» en producto mínimo viable es la parte que todos ignoran. Los fundadores asienten ante la idea de empezar pequeño y luego entregan una especificación con cuarenta pantallas, tres roles de usuario, un motor de facturación, un panel de analítica y un «ah, y debería integrarse con todo». Eso no es un MVP. Es un producto completo con el optimismo al máximo. Y es, con diferencia, la razón más común por la que los primeros lanzamientos llegan tarde, fuera de presupuesto y, aun así, sin lo único que los clientes realmente querían.

He ayudado a un buen número de pequeñas empresas y fundadores en solitario a sacar su primer producto de software. La parte técnica rara vez es lo que les hace tropezar. Lo difícil —siempre, sin excepción— es decidir qué no construir todavía. Un MVP no es una versión reducida de su producto soñado con funciones limadas al azar. Es una apuesta deliberada: la cosa más pequeña que puede poner delante de usuarios reales para demostrar que la idea central merece más de su dinero y su tiempo.

Así que esta es la guía que ojalá más fundadores leyeran antes de redactar su especificación. Sin jerga, sin teatro de «muévete rápido y rompe cosas». Solo una forma práctica de trazar la línea entre lo que pertenece a su primera versión y lo que puede —y debería— esperar.

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

Aclaremos la definición, porque casi toda la confusión empieza aquí. Un MVP es la versión más pequeña y sencilla de su producto que permite a una persona real hacer la única cosa valiosa que su producto promete, y que le permite a usted averiguar si volverá a hacerla. Eso es todo. Es una herramienta de aprendizaje que resulta estar hecha de software que funciona, no un lanzamiento recortado del producto terminado.

La palabra crucial es viable. Un error frecuente es leer «mínimo» y lanzar algo tan escueto que avergüenza al usuario: un flujo a medias que se cae, un registro que lleva a una pantalla vacía. Eso no es mínimo viable, es mínimo roto. El otro fallo es el opuesto: un producto tan «completo» que tardó un año en construirse, y para entonces ha gastado su margen demostrando una suposición que podría haber probado en ocho semanas.

Esta es la prueba mental que uso. Para cada función de la lista, pregunte: si la quitáramos, ¿podría aún un usuario lograr el único resultado central por el que existe el producto? Si la respuesta es sí, casi con seguridad no es del MVP. Esa sola pregunta recortará la mayoría de las especificaciones a la mitad, y la mitad que recorta es la que iba a hacerle llegar tarde.

Encuentre la única tarea que hace su producto

Antes de decidir qué construir, tiene que tener una claridad brutal sobre la única tarea que su producto hace por alguien. No la visión. No la hoja de ruta. La única acción repetible que, si funciona, mejora el día de una persona y la hace dispuesta a pagar. La mayoría de las especificaciones con problemas son vagas justo aquí: describen una plataforma, no una tarea.

Intente terminar esta frase en voz alta: «Un usuario viene a mi producto para ______, y se va habiendo ______». Una herramienta de turnos: un encargado viene a publicar el cuadrante de la semana, y se va con cada turno cubierto y el equipo avisado. Una app de facturación: un autónomo viene a facturar a un cliente, y se va con una factura enviada y rastreable. Si no puede completar esa frase con limpieza, no está listo para acotar: todavía está listo para pensar.

Lo que todo MVP de SaaS realmente necesita

Algunas cosas no son negociables, ni siquiera en la primera versión más austera, no porque sean emocionantes, sino porque sin ellas el producto o no se puede usar o no le enseña nada. Piense en ellas como el suelo, no el techo. Constrúyalas de forma sencilla, pero constrúyalas bien.

• Una forma de iniciar sesión. Incluso un único acceso con correo y contraseña sirve, pero uno real y seguro, porque todo lo demás depende de saber quién es el usuario.
• El flujo central, de principio a fin. La única tarea, desde el primer clic del usuario hasta el momento en que obtiene el resultado valioso: sin callejones sin salida, sin botones de «próximamente» en la ruta crítica.
• Algún sitio donde los datos vivan de verdad. Almacenamiento real, no un prototipo desechable, para que el trabajo de un usuario sobreviva a una recarga y pueda volver mañana.
• Una forma de que usted vea qué está pasando. Un registro básico o una vista de administrador sencilla, para que cuando algo se rompa —y se romperá— pueda averiguar por qué sin adivinar.
• Una forma de que los usuarios le contacten. Aunque sea solo un enlace de correo. Los primeros usuarios darán con límites que usted no previó; quiere que se lo cuenten, no que se vayan en silencio.
• El mínimo de confianza: un aviso de privacidad, un manejo sensato de los datos y no hacer nada imprudente con la información de las personas.

Fíjese en lo que no está en esa lista: facturación, onboarding sofisticado, páginas de ajustes, apps móviles, integraciones. Veremos por qué en un momento. La gracia del suelo es que es lo bastante pequeño para terminarlo y lo bastante sólido para aprender de él. Un inicio de sesión que funciona, un flujo que entrega, datos reales y una forma de observar y hablar con los usuarios. Eso es un producto viable.

Qué dejar fuera de la v1 deliberadamente

Esta es la sección a la que los fundadores se resisten, así que seré directo: la mayoría de las cosas que parecen esenciales para su primer lanzamiento no lo son. Parecen esenciales porque un «producto de verdad» las tiene, pero usted todavía no está construyendo un producto de verdad, está construyendo una pregunta. Dejar esto fuera no es recortar por lo fácil. Es toda la disciplina de un MVP.

Facturación automática y precios complejos

Casi con seguridad no necesita un motor de facturación de autoservicio, planes escalonados, prorrateo ni lógica de reclamo de impagos en la versión uno. Si los primeros usuarios quieren pagar, puede cobrarles manualmente: una factura, un enlace de pago, una llamada breve. La facturación manual para sus primeros diez clientes le dice algo que la automática no puede: si alguien va a pagar siquiera. Construya la máquina una vez que haya demostrado que hay dinero que cobrar.

Roles y permisos elaborados

Los sistemas de permisos con varios roles —administradores, gestores, observadores, reglas de acceso granulares— son un verdadero pantano de ingeniería y multiplican enormemente la superficie de pruebas. Para una primera versión, un solo tipo de usuario casi siempre basta. Aprenderá las necesidades reales de permisos viendo a equipos de verdad usar la cosa, y esas necesidades rara vez son lo que habría supuesto sobre el papel.

Integraciones, apps móviles nativas y el panel

«Tiene que integrarse con todo» es la frase que en silencio duplica los plazos. Elija como mucho una integración, y solo si forma parte de la tarea central. Las apps nativas de iOS y Android casi siempre pueden esperar: una web app responsive funciona hoy en un móvil. ¿Y el panel de analítica que todos quieren? Los usuarios no pueden analizar datos que aún no han creado. Lance primero lo que crea los datos; visualícelos cuando haya algo que mostrar.

Un método sencillo para trazar la línea

Conocer el principio es una cosa; aplicarlo a su propia especificación, donde cada función parece su criatura, es más difícil. Aquí va un método que funciona porque obliga a tomar una decisión sobre cada elemento en lugar de dejar que todo derive hacia «esencial».

1. 1
   Liste todas las funciones que ha imaginado

   Vuélquelo todo, sin filtrar todavía. Ponga la lista de deseos completa sobre la mesa para que nada quede acechando sin decirse y reaparezca a mitad de la construcción como sorpresa.
2. 2
   Marque cada una frente a la tarea central

   Para cada función, pregunte: ¿necesita un usuario esto para completar la única tarea central, de principio a fin? Márquela como «central», «útil» o «algún día». Sea honesto: la mayoría caen en las dos últimas.
3. 3
   Conserve solo lo «central» para la v1

   Su MVP es el montón «central» y nada más. Los montones «útil» y «algún día» no están rechazados: son su hoja de ruta, aparcados donde corresponde.
4. 4
   Compruebe el recorte con sentido común

   Mire lo que queda y pregunte: ¿puede un usuario real obtener valor real solo con esto? Si es sí, ha acotado un MVP. Si algo rompe de verdad el flujo central, recupere solo ese elemento, y nada más.

La disciplina está en el paso cuatro. Siempre hay la tentación de «recuperar solo una cosa más», y luego otra, hasta que ha reconstruido en silencio el producto completo. Permítase rescatar solo elementos que rompen de verdad el flujo central, no elementos que meramente lo harían más agradable. Lo más agradable es para lo que está la versión dos.

Viable sigue significando que tiene que sentirse real

Hay un modo de fallo al otro lado de la línea, y conviene nombrarlo. En las prisas por lanzar pequeño, algunos fundadores lanzan algo chapucero, y lo llaman MVP. Un flujo central que pierde su trabajo, un registro que da un 404, textos llenos de relleno de marcador. Eso no prueba su idea con justicia; prueba si los usuarios tolerarán una experiencia rota, y la respuesta siempre es no. Concluirá que la idea fracasó cuando en realidad fue la ejecución.

«Mínimo» se aplica al alcance, nunca a la calidad de la parte que conserva. Menos funciones, cada una sólida. El único flujo que lance debería sentirse terminado —rápido, claro y de fiar— aunque sea lo único que el producto haga. Un producto estrecho hecho bien gana a un producto amplio hecho mal cada vez, sobre todo cuando pide a desconocidos que le confíen su trabajo.

El MVP no es la meta: es la primera lectura

Esta es la parte que lo reencuadra todo: el lanzamiento no es el objetivo. El objetivo es lo que aprende en las semanas posteriores. Un MVP que se lanza y le dice «a los usuarios les encanta el núcleo pero piden X una y otra vez» es un éxito rotundo, aunque X signifique un mes más de trabajo. Un MVP que se lanza al silencio, sin que nadie vuelva, también ha cumplido su función: le ha librado de construir las otras treinta funciones sobre unos cimientos que nadie quería.

Así que planifique las primeras semanas con tanta intención como la construcción. Observe lo que la gente realmente hace, no lo que dice en encuestas. Hable con quienes volvieron y con quienes no. Deje que el uso real —no su especificación original— decida qué entra en la versión dos. La hoja de ruta que aparcó antes no es una promesa; es una hipótesis, y sus usuarios están a punto de calificarla.

Preguntas frecuentes