Falso MVP

Sin dudas desde hace unos años la sigla MVP se puso de moda en la industria de software; y luego de trabajar en algunas empresas de tecnología, primero desarrollando en diferentes lenguajes, luego liderando equipos de desarrollo y hoy viviendo tecnología como parte esencial para construir productos, he visto como el concepto se fue deformando al punto tal, que hoy un MVP en realidad es ya no es un verdadero MVP.

MVP (Minimum viable product): "es un producto con suficientes características para satisfacer a los clientes iniciales, y proporcionar retroalimentación para el desarrollo futuro".

MVPs que no lo son

Suelo ver en las etapas de definición cómo los equipos que trabajan desarrollando negocios basados en tecnologías y nosotros mismo desde tecnología cometemos el mismo error una y otra vez definiendo "Falsos MVPs".

Ya te imaginarás de que va — Todo comienza cuando pensamos en el producto que necesitamos y el que nos gustaría tener, entonces comenzamos a bajar ciertos hitos y features a un roadmap, en el cual participan diferentes áreas con sus métricas de negocio. Lo cual parece obvio tener para poder comenzar, ya que hipotéticamente esos features que componen nuestro roadmap son los que definen el éxito de nuestro producto!

Y con todo el peso y presión que el propio roadmap propone, comenzamos a definir la experiencia y la solución técnica! Listo! El error ya sucedió.

Aunque es un error tan silencioso que el proceso sigue con la definición de la experiencia y la estimación del equipo de desarrollo, el cual se prepara para despegar en un viaje que como mínimo durará al menos 3 MESES (1 Quarter).

Acá ya hicimos todo mal. WHAT!? — un MVP de 3 meses de desarrollo!? — ya hay algo que anda mal.

¿Por qué tendrías 3 meses a un equipo de desarrollo escribiendo código sin validar las hipótesis? Justamente para esto es que existe el MVP, el cual por definición es la mínima expresión de tu producto (repite: mínima mínima mínima) y te debes proponer hacerlo con el MENOR esfuerzo posible, ya que tiene como objetivo validar las hipótesis de aquel roadmap de negocio.

Equipo A vs Equipo B

Pensemos el siguiente escenario: Hemos definido un roadmap con cierta cantidad de features para hacer en un Q y tenemos 2 equipos clonados haciendo el mismo producto para el mismo universo de usuarios.

El equipo A comienza definiendo el "MVP" según el roadmap recibido y junto al equipo de UX y al equipo de desarrollo, despegan en ese precioso viaje de 3 meses!

El equipo B comienza definiendo el MVP y deciden junto al equipo de UX, pensar en una versión extremadamente chica, simple y lanzar algo en no más de 2 o 3 semanas para medir el comportamiento y la valoración de los usuarios, en base a estas métricas, mejorar el producto y volver a lanzar, medir, aprender y volver a mejorar.

Resultado a la mitad del Q: El equipo A tiene la mitad de la funcionalidad desarrollada y está ciego en cuanto a la valoración de los usuarios. Mientras que el equipo B, tiene la mitad de la funcionalidad desarrollada, pero ya conoce la valoración de los usuarios.

Para la 2da mitad del Q, resulta que uno de los requisitos originales del roadmap no es bien apreciado por nuestros usuarios y esto solo lo sabe el equipo B.

Mientras tanto, el equipo A, sigue desarrollando ciego y convencido de que está dando el máximo para poder meter dentro de los 3 meses toda esa cantidad interminable de código y funcionalidades que hipotéticamente nuestros usuarios desean.

Repasemos un momento esto: "el equipo A trabajó la 2da mitad del Q sobre funcionalidades que nuestros usuarios no aprecian". ¿Eso significa que esa porción del código no impactará sobre negocio tal como estaba esperado? — Correcto! Y no solo eso, tiramos una porción muy grande de código a la basura y además ahora ya tienes deuda técnica!

La clave

La clave está en desafiar las definiciones, pensar en chiquito, escalable y simple, desplegar, medir y volver a comenzar lo más rápido posible.

Desafiemos los MVPs y ojo! Que un MVP no te da la licencia de atar las cosas con alambres, un MVP es hacer las cosas muy bien! para luego disfrutar de iterarlas una y otra vez hasta lograr el producto que tus usuarios aman en perfecto equilibrio con el negocio.

La próxima vez que seas parte de un supuesto MVP o simplemente en la construcción de feature, ten el coraje de desafiar la definición y busca ser del equipo B.