Habrás escuchado cientos de veces el concepto de MVP (producto mínimo viable), sobre todo desde que la metodología Lean nos ha invadido en nuestro día a día.

¿Para qué un MVP?

Pero si podemos sacar un producto completado, ¿porqué vamos a lanzar un Producto Mínimo Viable?

Pues simplemente para empezar a escuchar a nuestros clientes lo antes posible. Es nuestro proyecto, nuestro niño pequeño, pero no puedes perder el foco de por y para quién está hecho, para el cliente final, por lo que todo el foco debe estar en ellos, ellos son los verdaderos Product Owners.

¿Por dónde empezamos?

Difícil respuesta, cada producto, cada mercado y cada tipo de cliente es un mundo, y deberemos adaptarnos a ellos, pero veamos algunos puntos que nos pueden ayudar a analizar por dónde empezamos.

• Objetivo / propósito del producto. Tener siempre presente hacia donde queremos ir es fundamental para ver los pasos que vamos a necesitar para llegar. Quizás cada uno de esos pasos sea una iteración sobre tu MVP.
• El foco, el cliente. Pensemos en el cliente, hablemos con ellos, empecemos a escucharles antes de empezar nada. ¿Qué es lo que más valoraría sobre el producto? ¿Qué es lo mínimo minimísimo que necesita para empezar a funcionar? Mejor que él, nadie nos puede orientar para definir las características de nuestro MVP.
• Divide y vencerás. Un clásico en el desarrollo software. Divide el todo en tareas más pequeñas, que podamos analizar, ver costes (tanto de esfuerzo como dinero). Teniendo tareas menores, podremos ver si serán parte de nuestro producto mínimo viable o no.

M: Mínimo

¿Pero cuánto de mínimo? Siempre he estado a favor de lo mínimo posible, siempre y cuando no dejes una mala imagen del producto. Que el usuario que vaya a usar esta primera versión sea consciente de que vienen cambios, sé sincero, indícale que es una versión Beta, sin complejos.

Que sepa que esto es todo … por ahora. Esto además le motivará para darte feedback, no cabrearse porque algo en concreto no vaya 100% y se sienta parte del equipo si sus aportaciones son escuchadas.

V: Viable

Quizás el punto más complicado de definir. ¿Cuanto es necesario para considerarse viable? Dificil contestación en muchos proyectos.

Para mi viable es que resuelva parte del problema del usuario final. No es necesario que resuelva todos sus problemas o dé respuestas a todas sus inquietudes. Empieza resolviéndole algo, que vea que el producto es útil, y que en futuras iteraciones le podrá aportar más valor.

Veamos un ejemplo muy muy sencillo: Queremos crear una página web corporativa, para dar a conocer nuestros servicios, nuestros productos, … En vez de esperar a tener una web diseñada de la muerte, con varios efectos, decenas de secciones para SEO, etc, que nos llevará un par de meses (con suerte) desarrollarla, ¿qué tal si montamos una landing con la información básica que el usuario que nos visite pueda usar, como son los métodos de contacto, y alguna que otra descripción de servicios/productos? Esto podemos tenerlo en 1 o 2 semanas, o quizás menos, el usuario tendrá información útil, y encima el señor Google puede empezar a indexarnos. win-win

P: Producto

Pues eso, estamos trabajando con un producto, así que centrémosnos en el producto. Genera un buen producto, y los clientes ya vendrán.

Be Agile my MVP

Aunque son conceptos distintos, adoptar un modelo de desarrollo de productos basados en MVP, nos permitirá adaptarnos a alguna metodología agile de forma natural. Podremos por ejemplo aportar valor al producto/usuario, con cada Sprint Scrum de 3 semanas, generando y sacando a producción versiones MVP evolucionadas de una original (que sacaríamos en la primera iteración).

Validación del MVP

He aquí el tesoro de todo esto. Un MVP se desarrolla para poder tener feedback y validación por parte del cliente final lo antes posible. El producto es para ellos, no para ti como desarrollador, por lo que serán ellos los que digan qué quieren y qué no quieren.