Mínimo producto viable - Parte 1

Qué es el mínimo producto viable? En este artículo inicial sentamos las bases de qué es el MPV y que características debe tener un buen prototipo que sea rápido de producir y que nos permita probar nuestra idea de aplicación directamente con los usuarios finales.

minimo_producto_viable
minimo_producto_viable

Aunque la estrategia del MPV puede emplearse en muchos ámbitos, el enfoque del artículo se orienta al desarrollo de aplicaciones web y sobre todo aplicaciones web en modo Software as a Service (SaaS).

 El Mínimo Producto Viable

En primer lugar tenemos que tener claro que el Mínimo Producto Viable es una estrategia y no un producto en sí mismo ni una metodología de desarrollo.   MPV es una estrategia orientada a que sean los propios consumidores finales a los que va dirigido nuestro producto/idea quienes lo prueben y nos den su opinión.

Al estar centrado en los consumidores/usuarios finales el MPV es una estrategia centrada en el usuario.

Para llevar a cabo esta estrategia existen dos partes fundamentales que debemos cumplir: Creación de un prototipo y Metodología de desarrollo.

En esta primera parte del post vamos a ver en detalle las características que debe cumplir un buen prototipo: Útil, medible e incompleto.  En una segunda parte hablaremos sobre la metodología de desarrollo del prototipo.

Creación de un prototipo

Para conseguir que los usuarios finales prueben nuestra aplicación web debemos construir un prototipo que puedan utilizar.  Este prototipo será la base sobre la que, en función de la opinión de quienes lo prueben, decidiremos nuestra estrategia futura.

Caracterísiticas

Estas son las tres principales características que definen un buen prototipo MPV: útil, medible e incompleto.

mínimo producto viable
mínimo producto viable

Útil .- Para que los usuarios puedan emplear nuestra aplicación web el prototipo debe ser útil.  Debe ofrecer la funcionalidad necesaria (y nada más que la funcionalidad necesaria) para que quienes se registran en nuestra aplicación puedan utilizarla y solventar su necesidad.  A pesar de que le llamamos prototipo, la funcionalidad que se incluya debe ser robusta y sin fallos.  No estamos planteando desarrollar un producto a medio hacer, se trata de hacer una mínima parte de nuestra aplicación pero los estándares de calidad para esa parte deben ser los mismos que aplicaríamos a un producto completo.

Medible .- El prototipo va a ser la base sobre la que tomaremos decisiones que pueden afectar de forma significativa al futuro de nuestra aplicación y de nuestra empresa.  Debemos medir con la mayor exactitud posible todo lo que ocurre cuando los usuarios lo utilizan.  No solo debemos instalar una buena herramienta de analítica web sino otras herramientas complementarias que nos permitan realizar mapas de calor, pautas de navegación, VoC (Voice of Customer) que nos permitirá conocer la opinión de quienes están utilizando la aplicación y no debemos olvidar el teléfono como forma efectiva de sondear a nuestros usuarios.

Incompleto .-  Hay que recordar que estamos hablando de un prototipo, 100% funcional pero prototipo al fin y al cabo.  Siempre es complicado decidir que funcionalidad no vamos a desarrollar todavía pero es un ejercicio necesario y sobre todo muy útil.  Quitar funcionalidad nos permitirá reducir el tiempo entre el desarrollo y la puesta en producción.  Cuanto menor tiempo de desarrollo menores costes y sobre todo, antes empezaremos a validar nuestra idea con las opiniones que verdaderamente importan: las de los usuarios finales.

producto
producto

Cuando, en el año 2005, decidí dejar de desarrollar la aplicación de gestión inmobiliaria que hasta ese momento tenía (una aplicación de escritorio tradicional) y comenzar el desarrollo de la aplicación en modo SaaS, me di cuenta de que si intentaba trasladar toda la funcionalidad del producto de escritorio a la web tardaría mucho tiempo en tenerla terminada.  Como el tiempo es dinero, no me podía permitir invertir en un desarrollo largo y costoso por lo que decidí aplicar la estrategia del MPV.

En 6 meses tuve desarrollada la aplicación inicial sobre la que empezaron a trabajar los nuevos clientes y a la que fui migrando los existentes.  Como era una aplicación de gestión inmobiliaria esa primera versión hacía solamente eso:  gestionar el mantenimiento y la búsqueda de inmuebles.   Altas, bajas y modificaciones de inmuebles y el buscador que utilizaban para acotar los inmuebles en función de las necesidades de los clientes.  Las dos opciones sobre las que los usuarios trabajaban el 80% del tiempo.

De los más de 30 informes que había en la versión de escritorio la primera versión web tenía 4.  La agenda de los comerciales no existía, ni el mantenimiento de clientes, ni el aviso por email.....

Y lo mejor de todo es que los pocos clientes iniciales que migré a esta versión en su mayoría estaban encantados.  Las ventajas de tener la aplicación en un navegador, con una mejor presentación de los inmuebles, una búsqueda mejorada y una mejor experiencia de usuario compensaban las otras carencias.

Adoptar la estrategia del MPV estuvo, en mi caso, motivada por la necesidad, pero sin duda fue un acierto que me evitó invertir mucho tiempo en desarrollar funcionalidad que no era necesaria.

Resumen

En esta primera parte hemos visto las características que debe cumplir un buen prototipo.  En una segunda entrega abordaremos el proceso de desarrollo del prototipo: qué metodologías utilizar y cómo poner al cliente como el centro de todas nuestras acciones.

Mínimo producto viable - Parte 2