Allá por el año 2011, Eric Ries publicó su aclamado libro Lean Startup, que supo ganarse un prestigioso lugar en la biblioteca de cualquier aficionado de las empresas tecnológicas. En este mismo libro se popularizó el concepto de MVP o producto mínimo viable. Aquella mínima expresión de producto, esa primerísima primer versión que nos permitiría obtener la mayor cantidad de aprendizaje posible al menor esfuerzo con el objetivo de reducir los riesgos inherentes a crear proyectos en entornos de alta incertidumbre.

Con rapidez, el término MVP viajó a lo largo del globo para instaurarse en el vocabulario de todos los emprendedores de startups, inversores en firmas de venture capital, profesionales de producto, diseño y desarrollo e incubadoras y aceleradoras de negocios. De pronto todos comenzaron a referirse acerca de la importancia de experimentar pequeño y barato, de fallar de forma inteligente y de lanzar “un MVP” al mercado.

Pero, lo que no se extendió tan rápido fue un entendimiento común acerca del mismo concepto. A ver, sabemos que el MVP debe ser mínimo y viable, pero exactamente: ¿qué tan mínimo? y ¿qué tan viable?. Hay una gran disparidad de voces y opiniones contrarias sobre el asunto. Su propia ambigüedad sembró tanta confusión entre founders, inversores, profesionales y clientes, que incluso muchos equipos erradicaron de su jerga técnica la palabra MVP para no traer caos a la mesa.

En este artículo haremos énfasis en la cuestión de lo mínimo. Repasaremos las distintas metodologías existentes para validar una idea junto a su duración aproximada, listaremos algunos criterios acerca de qué es exactamente un MVP y su propósito frente a otras herramientas de validación y clarificaremos las distintas casuísticas que impactan en la complejidad de nuestro MVP y su esfuerzo necesario.

Bueno, fue bastante introducción. 😅 ¡Vayamos directo al contenido!

‍

Los pasos previos hacia el MVP

Comencemos con una afirmación fuerte: no es necesario pasar meses desarrollando un MVP para validar una idea. Veamos…

¿Cuántas veces de forma inesperada una idea surgió en nuestra cabeza que nos entusiasma y creemos que tiene un potencial enorme? ¿Es realmente necesario pasar meses trabajando para verificar si la idea es atractiva o viable?

La respuesta, como en muchos otros aspectos de la vida, es un DEPENDE.

Seguramente sea un NO rotundo sí lo que queremos validar es el interés o deseabilidad de nuestra idea. Podemos entender esto a partir de múltiples maneras, algunas más rápidas y otras un poco más complejas, pero todas nos brindarán resultados en menos de un mes. Algunas técnicas que podemos emplear para alcanzar este objetivo son:

• Videos tutoriales que demuestren y expliquen la idea
• Presentación de diapositivas sobre la idea
• Implementación de landing page con lista de espera
• Realizar entrevistas a usuarios
• Elaborar un prototipo el alta fidelidad (a partir de mockups)
• Prototipos de baja fidelidad (papel)
• Distribuir una encuesta
• Escribir un artículo para blogs y foros
• Campañas publicitarias
• Redes sociales
• Experimentos (A/B testing por ejemplo)

No todas estas técnicas representan de forma fiel y real a la idea, por lo que algunas nos darán resultados más confiables para elaborar conclusiones mientras que otras no tanto. Pero independientemente del mayor o menor riesgo, estas técnicas cumplen su objetivo de validar deseabilidad.

Por otro lado, sí queremos validar la factibilidad de una idea (es decir, si podemos llevarla a la práctica con la tecnología actual y nuestros recursos) nuevamente NO necesitamos dedicar cientos de horas en esto. En lugar de tratar de implementar todo un nuevo producto, podemos realizar una prueba de concepto (POC). Por ejemplo, si queremos crear una app que sincronice automáticamente todas las notas que tomamos en distintas plataformas, podemos probar de realizar una integración con una de estas plataformas para validar si es posible hacerlo.

Lo mismo aplica si queremos analizar la viabilidad financiera de la idea. Podemos realizar un pequeño experimento para ver si las personas estarían dispuestas a pagar o vender el producto de un futuro competidor para ver si puede construirse un negocio rentable al largo plazo.

Con mayor o menor grado de certeza, validar la deseabilidad, factibilidad o viabilidad de una idea es algo que podemos hacer en días. Entonces, ¿por qué muchas empresas y emprendedores pasan meses desarrollando un MVP?

Bueno, un MVP no solo cumple el propósito de validar las dimensiones mencionadas recientemente, sino que también buscar validar nuestra mismísima propuesta de valor. El MVP es un producto real. En su expresión mínima, sí, pero no deja de ser algo que puede ser utilizado y comprado. Y esto sí nos lleva un poco más de tiempo.

‍

‍

Dicho esto, tenemos tres populares herramientas que nos ayudan a validar distintos aspectos de una idea:

• Prototipo, para validar la deseabilidad
• POC, para validar su factibilidad (y viabilidad)
• MVP, para validar su potencial como negocio

Si bien hay muchas corrientes que consideran lanzamientos de landing pages, videos tutoriales o entrevistas como MVPs, personalmente creo que incluir estas estrategias dentro del concepto confunde más de lo que ayuda. Un MVP, al igual que un prototipo, puede ser de baja, mediana y alta fidelidad según que tan fiel es su representación a un producto real. Hay MVPs muy cortos de funcionalidad y otros un poco más completos, al igual que hay prototipos en papel y otros que son espejos de apps reales. Entonces, para no confundir, refirámonos a un MVP como algo que pueda ser usado y por el cual los usuarios pagarían.

A continuación, repasaremos cada instancia de validación, mencionando sus características y sus plazos de entrega

‍

Prototipo: validar la deseabilidad de tu idea

Un prototipo es una representación de tu producto, en el sentido de que tus potenciales usuarios pueden interactuar sobre el mismo para darse una idea del funcionamiento del producto final.

Los prototipos buscan que el usuario tenga un contacto más genuino y realista con la idea, para así aportar una opinión más precisa sobre la misma. Un prototipo suele ser una fachada: están desprovistos de funcionalidad y lógica, por lo que se consideran más bien como conceptos interactivos.

En productos de software, los prototipos se suelen arman a partir de pantallas que emulan el aspecto visual de la solución que uno quiere desarrollar. Estas pantallas se pueden diseñar a partir de programas como Adobe XD y Figma, y que luego se les puede aportar interactividad. Es decir, las pantallas quedan conectadas entre sí.

Por ejemplo, se puede establecer que al presionar cierto botón el diseño te lleve a una pantalla determinada, y al apretar otro botón, te lleve de vuelta a la pantalla inicial.

Esta combinación entre pantallas de alta fidelidad más interactividad es fundamental para construir una representación lo más fiel posible a tu idea y así validar su deseabilidad con el mayor grado de certeza posible.

‍

‍

Importante: no es necesario diseñar absolutamente todas las pantallas de nuestro producto. Al comienzo estamos interesados en validar la deseabilidad y el interés del usuario sobre su flujo principal de tareas. Si nos mantenemos enfocados, diseñar las pantallas, prototiparlas y agendar pruebas de usabilidad para exponer el prototipo al feedback de usuarios es un proceso que no debería tomar más de dos semanas.

Desde ya, si decidimos realizar un proceso de UX Research antes del diseño de interfaces para entender bien cuál es el problema a resolver y así diseñar con una base más sólida, debemos considerar unas semanas más. Pero incluso con UX Research, este proceso de validación no debería extenderse más de un mes. Incluso algunos expertos lo resuelven en una semana, en lo que se conoce como Design Sprint.

Un prototipo no es un MVP, pero nos permite, con cierta confianza, validar el interés sobre nuestra idea en muy poco tiempo e invirtiendo el menor esfuerzo posible.

‍

POC: validar la factibilidad y viabilidad de tu idea

La prueba de concepto, o proof of concept (POC), tiene como propósito validar la factibilidad de nuestra idea. Esencialmente, sí es posible llevar a cabo lo que tenemos en mente. Pensemos un escenario en donde podríamos llevar a cabo un POC:

Supongan que queremos desarrollar un app de viajes cuya principal funcionalidad es la de marcar los países que uno visitó en un mapa. Cuando marcas un país, se abre una pestaña donde puedes agregar detalles y fotos de tu experiencia en tal país.

La app completa no tendría sentido si no es posible realizar esta acción de marcar países en la interfaz. Por lo que es necesario realizar un POC para verificar si existe una integración con Google Maps o algún otro proveedor de mapas que nos permita marcar países y colorear su superficie al hacer tap dentro de sus límites. No es necesario que el POC funcione con absolutamente todos los países, con ya funcionar en uno solo, es suficiente para confiar en que no tendremos problemas en replicar la funcionalidad con los demás países.

Entonces el objetivo de la prueba de concepto es la de comprender si nuestra idea tiene un potencial práctico y puede ser llevada a cabo. Son pruebas pequeñas para analizar la factibilidad y que determinan si la idea es una fantasía o no.

‍

‍

Al igual que un prototipo, el POC no debería tomar más de un par de semanas.

De todas formas, un POC, a diferencia de prototipos creados desde plataformas como Figma, puede adoptar diversas formas en base a qué es lo que se quiere demostrar.

Esta menor previsibilidad ocasiona que el POC, si bien con el objetivo de ser una prueba rápida, pueda justificar semanas adicionales de desarrollo si la naturaleza de la idea es compleja o la industria esta altamente regulada. Esto hace que a veces acceder a una base de datos o realizar una integración se vuelva una tarea dificultosa.

Por último, es importante entender qué estamos validando dentro del POC, ya que este puede servir múltiples propósitos como:

• Entender si existe una tecnología que habilite nuestra idea
• Descubrir problemas, riesgos y restricciones técnicas
• Relevar áreas de oportunidad y posibles mejoras
• Comprender si disponemos los recursos (financieros, humanos y de tiempo) para llevar a cabo el proyecto
• Estimar si el proyecto puede ser redituable a largo plazo (análisis de viabilidad económica)

‍

MVP: validar el modelo de negocio y la propuesta de valor de tu producto

Un MVP nace con el propósito de validar la propuesta de valor de tu producto en el mercado. De aprender acerca de cómo tu producto será utilizado, de saber si funciona para sus usuarios, si resuelve una necesidad y si tu modelo de negocio tiene potencial de escalabilidad. Para llegar esta instancia, sabemos que el esfuerzo necesario será mayor al de un prototipo o POC.

La sabiduría popular indica que un MVP no debe exceder los 3-4 meses de desarrollo. Estos meses por lo general están instanciados en tres fases: análisis funcional, desarrollo y QA. En la primera se reúnen los requerimientos técnicos, que pueden estar redactados en formato user story, se definen criterios de aceptación, se establecen dependencias y prioridades y se detallan reglas de negocio y descripciones funcionales para que cada tarea pueda ser diseñada y desarrollada con precisión. En paralelo, el área de UX define los flujos de usuario, la arquitectura de la información, navegabilidad y sistema de diseño, mientras desarrollo avanza con el diseño de la bases de datos y APIs.

Ya la segunda fase es un esfuerzo en paralelo de diseño y desarrollo por crear las interfaces e implementarlas en el sistema. La tercera fase son las pruebas de calidad o QA, donde se realizan testeos para verificar que no existan errores o fallas en el uso del producto. Esta fase algunas veces se deja al final del proceso, pero en otras ocasiones sucede en paralelo o al finalizar cierto flujo de trabajo.

Por lo mencionado anteriormente, es difícil concebir un MVP en menos de un mes. No digo que sea imposible, pero en la mayoría de los casos suele tomar un par de meses al menos. Quizás un emprendedor serial que haya lanzado ya varios MVPs, tenga nociones de diseño y desarrollo y omita algunas fases del proceso tradicional podría llegar a lograrlo en ese plazo de tiempo. Pero no son muchos estos casos.

‍

‍

Realmente la duración del MVP puede depender de múltiples factores. Por ejemplo, uno de ellos es la naturaleza del producto. Hay industrias altamente reguladas y que exigen múltiples integraciones con proveedores para ofrecer un producto básico. Este es el caso de muchas fintech, ya que montar toda la infraestructura necesaria y cumplir con las normas de los distintos organismos reguladores pueden llevar el proceso de desarrollo a 9 meses sencillamente.

De hecho, un MVP a veces puede volverse lo suficientemente largo para justificar pequeños lanzamientos (o cortes técnicos) dentro del proceso de desarrollo.

Por otro lado, una mayor cantidad de miembros en el equipo suele acelerar el proceso de desarrollo hasta cierto punto, donde ya sumar más personas deja de ser productivo y comienza a existir solapamiento de tareas.

Otras variables que impactan en los tiempos de desarrollo de un MVP pueden ser:

• Nivel de conocimiento del equipo sobre la tecnología utilizada
• Disponibilidad horaria del equipo
• La tecnología en sí (desarrollo con código o a través de plataformas no-code/low-code)
• Tipo de MVP (single feature, wizard of oz, concierge, etc)
• Modularizacion de componentes
• Metodología de trabajo (desarrollo en cascada vs procesos agile)

Pero nuevamente, con todas las variables en cuenta, en la mayor parte de los casos un MVP no debería tomar más de 3-4 meses. Y estoy de acuerdo con estos plazos.

En caso de que las estimaciones originales den un plazo mayor a ese tiempo, entonces se puede trabajar sobre las variables mencionadas para acelerar el lanzamiento. También se pueden revisar las prioridades de las funcionalidades incluidas en el MVP, para ver si hay algo que podemos prescindir sin sacrificar el objetivo del MVP.

La idea detrás de todo es lanzar lo más pronto que podamos de forma que tenga sentido al usuario y este acorde con el contexto.

En resumen, está claro que cada instancia de validación tiene su propia complejidad. Validar el diseño y deseabilidad de una idea o su factibilidad técnica es algo que puede resolverse en días o pocas semanas. No es necesario elaborar un MVP para probar si la idea despierta interés o tiene potencial de convertirse en un negocio lucrativo. Pero cuando queremos dar nuestro primer paso al mercado, y validar nuestro producto junto a su propuesta de valor y modelo de negocios, necesitaremos algo que se pueda operar… algo que los usuarios puedan comprar y usar. Y esto requiere un esfuerzo mayor, que si bien no debe ser superior a los 4 meses, en la mayoría de los casos es algo que puede tomar fácilmente más de un mes.

¡Y eso es todo!  Espero que hayan disfrutado el artículo. Me ayudarían mucho en compartirlo con las personas que crean que les será útil. ¡Te aconsejo que te suscribas a Productified para no perderte ninguna novedad!