¿Qué es un MVP?

No todos los MVPs valen para lo mismo

Si le preguntamos a ChatGPT:

Un MVP (Minimum Viable Product) es la versión más simple y funcional de un producto que permite validar hipótesis y obtener retroalimentación del mercado con el menor esfuerzo y recursos posibles.

El término se empezó a utilizar en 2001 por Frank Robinson, quien trabajó el concepto en distintas startups con su consultora SyncDev. Diez años más tarde, Eric Ries publicó The Lean Startup libro que hizo que el término se popularizase y formase parte ya del ciclo de vida del producto. The Lean Startup tiene un enfoque tan aterrizado, que lo convierte en una obra maestra. El trabajo que hace Eric a través de todo el libro, planteando problemas, formulando su hipótesis, creando un MVP para validarla y medir para poder iterar es una auténtica maravilla.

Desafortunadamente, el concepto del MVP ha perdido su fuerza. Ya no forma parte de un experimento meditado, con una hipótesis acotada que validar. El MVP se ha convertido en la primera fase del producto. Un término que se usa por la organización para definir un estado del producto, que todos sabemos que no está terminado, pero que nos permite probarlo con clientes para aprender. Pero ¿qué queremos aprender? ¿para qué sirve ese MVP? La falta de claridad sobre el propósito de ese MVP hace que acumulemos funcionalidades MVP sin acabar y terminemos con productos que no terminan de funcionar o salir de esta fase.

Parte del problema es que, por lo general, es mejor lanzar una versión reducida de un producto sin tener ni idea de qué quieres validar, a sacar esa versión del producto completamente terminada 6 meses más tarde y sin saber qué se quería validar en un primer momento. El problema viene cuando no somos capaces de mirar hacia atrás y deshacer algunas de esas pruebas o funcionalidades que no restan, pero que tampoco suman.

¿Quieres validar una solución o un problema?

El principal reto al que se enfrentan las empresas que quieren lanzar un producto al mercado identificar qué parte de su propuesta será cierta y cuáles erróneas. Cuando empezamos, todo es un lienzo blanco sobre el que escribir y desde que escribes la primera línea de código todo se convierte en aciertos y errores. Estos aciertos se van materializando conforme vamos andando el camino y el producto se va desarrollando y los usuarios lo van probando. Para poder hacer un buen MVP hay que pensar si el foco está en validar a nivel técnico que la solución se puede hacer o en si el foco está en validar que los usuarios quieren el producto.

¿Podemos desarrollar la tecnología que prometemos?

Cuando Spotify salió el 7 de octubre de 2008 una cosa estaba clara: las personas querían acceso ilimitado a música en formato streaming. Por eso cuando el servicio salió, atraer usuarios a una cuenta gratuita no fue el problema. Ya se había validado por servicios como The pirate bay que el mercado demandaba música en streaming. El problema estaba en ser capaces de dar una experiencia musical que estuviera a la altura, antes de empezar a atraer a usuarios a la plataforma. El MVP de Spotify tenía que responder a una pregunta de su fundador. ¿Podemos hacer streaming de música en tiempo real utilizando internet? ¿Podemos quitar el buffer para poder escuchar música al instante?

No fue un reto trivial. De hecho, para lograrlo tuvo que sacar varios MVPs de distintas soluciones que cada uno les llevaba un paso más cerca de saber que su producto final era posible.

• Almacenamiento en caché y precarga

• Red de distribución de contenido

• Segmentación de archivos

• P2P networking

• Optimización del protocolo de streaming

• Control de calidad adaptativa

Con todo esto consiguieron bajar la latencia desde los 10 segundos que tardaba la primera versión hasta los 200 milisegundos que hacían que la calidad del servicio fuera la que haría que su producto triunfase. Todo este camino no se hizo de la noche a la mañana. Poco a poco MVP tras MVP llegaron a esa validación de que técnicamente se podía lograr lo que Spotify perseguía.

En estos casos donde no está claro que seas capaz de desarrollar el producto que prometes vender es importante que enfoques tu MVP a reducir esa incertidumbre técnica. Para ello no necesitas un login, una aplicación o incluso una web. Puede que con una demo (que funcione de verdad) seas capaz de validar, que eres técnicamente capaz de desarrollar el producto.

¿Los usuarios se van a comportar como esperamos?

El 4 de febrero de 2004, Mark Zuckerberg se registró como el primer usuario en Facebook. Mark no tenía amigos. 20 años más tarde casi la mitad del planeta usa Facebook de forma mensual. Para que Facebook llegase a su primer millón de usuarios, no tuvo que crear algoritmos especiales o incluir juegos en su plataforma. Facebook fue ajustando su producto y su estrategia hasta que dio con la clave de qué buscaban las personas en la plataforma.

Para conseguirlo fue iterando por distintas fases:

• Expansión fuera de las universidades

• La creación del muro estático con las publicaciones de tus amigos

• Creación de grupos de interés

• Capacidad de compartir fotos

Se puede observar que la latencia nunca fue un problema. Sin embargo, entender al usuario y validar su comportamiento han sido su obsesión durante todo este tiempo.

---

El concepto de MVP ha ido evolucionando desde su origen. Aunque inicialmente se concibió como una herramienta para validar hipótesis específicas con el menor esfuerzo y recursos posibles, su aplicación ha evolucionado en el contexto del desarrollo de producto digital. En su esencia, un MVP debe servir para reducir incertidumbres y proporcionar aprendizaje valioso, ya sea a nivel técnico o de comportamiento del usuario.

Casos como Spotify y Facebook ilustran enfoques diferentes, pero igualmente exitosos hacia el desarrollo de un MVP. Spotify se centró en resolver desafíos técnicos críticos, como la transmisión de música en tiempo real sin buffering, lo que requirió múltiples iteraciones y mejoras tecnológicas. Por otro lado, Facebook se enfocó en entender y validar el comportamiento del usuario, ajustando continuamente su producto para satisfacer las necesidades sociales de su base de usuarios.

Estos ejemplos subrayan la importancia de tener claros los objetivos de validación al desarrollar un MVP. Ya sea para comprobar la viabilidad técnica de una solución o para entender mejor a los usuarios, un MVP efectivo debe estar alineado con las hipótesis críticas que la empresa necesita probar. Al mantener este enfoque, las empresas pueden no solo ahorrar tiempo y recursos, sino también aumentar significativamente sus probabilidades de éxito en el mercado.