Para aquellos que no han transitado la construcción de una solución de software, seguramente nunca escucharon sobre MVP, MMP o SLC. Éstos acrónimos en inglés pueden parecer raros y hasta indescifrables, pero esconden definiciones muy importantes a la hora de comenzar a construir una solución de software (y aplica también a otros productos).
Comencemos por las definiciones.
MVP (Minimum Viable Product)
Los equipos de producto vienen hablando de MVP (en inglés pronunciado como “em-vi-pi”) por más de diez años. Es el acrónimo de Minimum Viable Product, que en su traducción al español sería como un Producto Mínimo Viable. En otras palabras es la concreción de un “producto” (que para mí siempre ha sido software) con las suficientes características para satisfacer a los clientes iniciales y proporcionar retroalimentación para el desarrollo futuro[1].
El objetivo que persigue un MVP es:
- Ser capaz de probar una hipótesis de producto con recursos mínimos
- Acelerar el aprendizaje
- Reducir el desperdicio de horas de ingeniería
- Presentar el producto a los “primeros seguidores” tan pronto como sea posible
- Base para otros productos
- Demostrar las habilidades del constructor en la elaboración del producto requerido
“Estás vendiendo la visión y entregando el conjunto mínimo de características a visionarios, no a todo el mundo.” Steve Blank
MMP (Minimal Marketable Product)
El concepto de MMP (en inglés pronunciado como “em-em-pi”) y que es el acrónimo de Minimal Marketable Product o Producto Mínimo de Mercado, es distinto al MVP ya que es una herramienta para reducir el tiempo de puesta en el mercado para que se pueda lanzar más rápido que un producto “gordo” en funcionalidades.
En este punto es en donde por lo general, emprendedores en etapas tempranas fallan. La creación de un producto con la cantidad justa de funcionalidad a veces es difícil y he visto personalmente muchos productos que son sobre desarrollados con muchas funciones brillantes que no dan valor a los usuarios y que encima han saturado al producto e incrementado los costos de mantenimiento notablemente. Todos nos tentamos de manera constante a agregar otra funcionalidad nueva o agregar líneas extras a un blog.
Recordar este concepto de MMP hace que puedas enfocarte en lo que realmente hay que hacer.
Pensemos en el lanzamiento del iPhone, que fue puramente un MMP. Volvamos atrás con la máquina del tiempo al año 2007 y encontramos un Smartphone que no tenía muchísimos rasgos que los competidores y tenían (y cosas básicas que suenan hasta ridículas) como por ejemplo, no traía el copiar-pegar, no había integración con Outlook (O Exchange! Que hacía que los correos empresariales no pudieran utilizarse) y más… Pero pensemos el por qué tuvo éxito, simplemente porque desarrollaron el producto de menos a más.
SLC (Simple Lovable Complete)
El último concepto es una evolución del concepto de MVP, y en inglés se pronuncia “slick” es el acrónimo de Simple Lovable Complete o llevado a español: Simple, Enamorable y Completo.
Esta visión está más del lado del usuario, poniéndose en los zapatos de quién utilizará el producto y menos en las corazonadas del creador y haciendo elecciones más consistentes relacionadas con el beneficio al cliente y no tanto del producto en sí.
Desmenuzando el contenido de estos tres componentes llegamos a que:
- Simple: los usuarios “odian” la complejidad, eventos que los frustran, flujos confusos, que en la mayoría de los casos hacen que se van.
- Enamorable (Lovable): lo primero que nos viene a la mente es la experiencia visual, más que a la funcionalidad. Como constructores de producto, nosotros por lo general preponderamos la funcionalidad antes que el diseño, pero el balance es la ecuación perfecta para un producto exitoso. Un punto importante es que en esta función el énfasis es la evolución de los casos de uso del cliente.
- Completo: esta definición es la que diferencia este concepto del MVP y MMC, ya que por ejemplo en el MVP por definición no es “completo”. Significa que cambiamos la pregunta de “¿Cual es la funcionalidad mínima que el cliente necesita?” a una del estilo “¿Qué necesita este proyecto completar?”. Y desde ahí será mucho más sencillo priorizar los objetivos, y enfocarse en los casos de uso que son más importantes. No es una contradicción y si miramos ejemplos de las primeras versiones de Snapchat, Trello o Whatsapp, podemos ver como hicieron un producto inicial completo (con muy poca funcionalidad, que enamoraba), que luego evolucionó.
Siguiendo el razonamiento del ejemplo de los modos de transporte del equipo de producto de Spotify:
Volviendo a uno de los ejemplos mencionados antes, Snapchat tomó un método de SLC muy similar al del gráfico. La primera iteración del producto fue una pantalla donde tocando en cualquier lugar tomaba una foto que podías enviar a cualquiera, y que desaparecía. No había videos, ni filtros, ni red social, ni comentarios, y tampoco almacenamiento. Esto es, simple, enamorable, y completa. El echo de “no almacenar” fue de gran ayuda para el éxito y muchos pensaron que la simplicidad de la interfase también. Luego agregaron mucha funcionalidad -videos, filtros, timelines, y hoy en día se están convirtiendo en uno de los principales promotores de realidad aumentada.
Cuál es el camino a elegir
Pensar en una combinación entre MVP y MMP es uno de los caminos recomendados. Al combinar estos conceptos uno comienza probando ideas en un MVP y lanzando el producto correcto en un MMP, pero con el claro objetivo de enamorar en el intento (SLC).
Hay que evitar la entrega de “Big Bang” para el desarrollo de productos complejos e innovadores. Lo ideal es hacerlo de manera iterativa e incremental. Esto ya lo sabías, pero en realidad lo estás haciendo así?
En el momento que haz llegado a una solución perfecta, el problema ya ha cambiado. –@jshefrin
By the time you’ve come to the perfect solution, the problem’s already changed. –@jshefrin
La recomendación final es:
Comience por identificar su patineta, el primer producto comprobable. Apunte a las nubes, pero trague su orgullo y comience por entregar la patineta. Evite el término MVP. Sea más explícito sobre lo que realmente está hablando. El primer comprobable / usable / enamorable es solo un ejemplo, use los términos que sean menos confusos para su cliente.
[1] Ries, Eric (3 de agosto de 2009). «Minimum Viable Product: a guide».