Lanzando un producto digital. El MPV

web project

Cuando quieres lanzar un producto digital que incluye numerosas funcionalidades, por regla general el cliente quiere tenerlo todo de golpe: La sección de noticias, una sección de prensa (con sistema de login para periodistas), la ayuda (cuando aun nos sabe que van a preguntar sus usuarios)… por de pronto hasta querría salir ya con 3.000 visitas diarias. Esto en un proyecto de corte editorial, pero cuando hablamos de un producto digital contemple perfiles de usuarios, funcionalidades especiales, APIs de terceros, la complejidad puede elevarse al infinito.

Y salir con todo significa una cosa: retrasos. La fecha prevista se dilata en espera de el departamento legal apruebe un texto, los comerciales den el visto bueno a los de marketing… un engranaje burocrático, puede que necesario, pero del todo ineficiente. A esto añadimos los problemas técnicos: una funcionalidad que no carga, una sección que no se ve en Explorer 7 (creo que Explorer 6 lo podemos dar definitivamente por difunto)… Y como la web no ha salido, nadie se da prisa en terminar su parte. Total, mi compañero tampoco ha terminado la suya…

Y los retrasos significan una cosa: dinero. Costes que aumentan, posible dinero que se pierde mientras el producto no está funcionando y generando ingresos.

El MPV (Mínimo Producto Viable)

El MPB, o como algunos señalan, MLP (Minimum Lovable Product) son las funcionalidades mínimas que harían funcionar (y generar engadgement) un producto digital. Y al mismo tiempo, medir la viabilidad (no hablo la rentabilidad) de nuestro producto, reduciendo tiempo y costes.

Un planteamiento de MVP nos permitiría:

  • Agilizar el desarrollo, enfocándonos primero en los puntos claves de nuestro proyecto.
  • Medir. Nos permite realizar tests sobre las necesidades y enfoque de nuestro producto. ¿Y si resulta que tenemos que variarlo? Suele pasar. Los usuarios no reaccionan como esperábamos, no cumplen las expectativas, o, por ejemplo, tiene éxito, pero detectamos que nuestro siguiente paso debería ser otro al que teníamos pensado. Y claro, si tuviéramos el proyecto ya desarrollado oiríamos eso de “guárdalo que igual lo podemos utilizar más adelante. Si, pero el gasto ya está hecho.
  • Ahorrar. Tiempo y dinero, evitando desarrollar funcionalidades sin testar primero si son viables, si tienen proyección de futuro o son directamente prescindibles.

Un ejemplo de la vida real

Hace poco realicé un site de tamaño mediano para un cliente que incluía noticias, mucha documentación propia que subir a la base de datos, perfiles de usuarios, y varios espacios y funcionalidades para los usuarios-socios de la web. En base a nuestra experiencia, intuía poco uso para algunas secciones, por lo que propusimos un desarrollo escalado, dejando funcionalidades de cierta complejidad (sobre todo técnica) y poca proyección para los usuarios para siguientes fases.

Ante la negativa del cliente, comenzamos el diseño global de todo el producto, pero, desafortunadamente, estas complejidades sobre todo a nivel técnico y problemas administrativos de nuestro cliente retrasaron el estrenos más de 6 meses. Los  resultados de los tests y estadísticas de uso, ya es otra historia.