Entiende el MVP (Producto Mínimo Viable) y por qué prefiero Producto que se pueda probar, utilizar y adorar más temprano

Por Henrik Kniberg. Publicado el 2016-01-25 – 12:14.

Hace un par de años dibujé esta imagen y comencé a usarla en varias presentaciones sobre desarrollo ágil y lean:

¡Desde entonces el dibujo se ha vuelto viral! Aparece en todas partes, en artículos y presentaciones, incluso en un libro ("User Story Mapping" de Jeff Patton, una lectura excelente por cierto). Muchos me dicen que el dibujo realmente captura la esencia del desarrollo iterativo e incremental, la puesta en marcha ajustada, el MVP (producto mínimo viable) y demás. Sin embargo, algunos lo malinterpretan, lo cual es bastante natural cuando sacas una foto de su contexto original. Algunos lo critican por simplificar demasiado las cosas, lo cual es cierto. La imagen es una metáfora. No se trata del desarrollo real de un automóvil, se trata del desarrollo de un producto en general, utilizando un automóvil como metáfora.

De todos modos, con todo este rumor, pensé que era hora de explicar el pensamiento detrás de esto.

Primer ejemplo: no así

La fila superior ilustra un concepto erróneo común sobre el desarrollo iterativo e incremental de productos (también conocido como Ágil).

Muchos proyectos fracasan gravemente porque realizan una entrega tipo Big Bang (construya la cosa hasta que esté 100% terminada y entregue al final). Perdí la cuenta de la cantidad de proyectos fallidos que vi debido a esto (ve más adelante para ver algunos ejemplos). Sin embargo, cuando Ágil se presenta como una alternativa, las personas a veces se resisten a la idea de entregar un producto sin terminar, ¿quién quiere la mitad de un automóvil? Imagina esto:

“Aquí señor, aquí está nuestra primera versión, un neumático delantero. ¿Qué piensa?"

El cliente dice "¿Por qué diablos me entregas un neumático? ¡Pedí un COCHE! ¿Qué se supone que debo hacer con esto?"

(Por cierto, estoy usando el término "cliente" aquí como un término genérico para representar a personas como gerentes de productos, dueños de productos y usuarios pioneros en la adopción).

Con cada entrega, el producto está más cerca de estar terminado, pero el cliente todavía está enojado porque en realidad no puede usar el producto. Todavía es un auto parcial.

Y finalmente, cuando el producto está terminado, el cliente dice “¡Gracias! ¡Finalmente! ¿Por qué no entregaste esto en primer lugar y te saltaste todas las demás entregas inútiles?”.

En este ejemplo, el cliente está contento con el producto final, porque es lo que pidió. En realidad, eso no suele ser cierto. Ha pasado mucho tiempo sin ninguna prueba de usuario real, por lo que es muy probable que el producto esté plagado de fallas de diseño basadas en suposiciones incorrectas sobre lo que la gente necesita. Entonces esa carita sonriente al final es bastante idealista.

De todos modos, la primera fila representa “ágil bastardo”. Técnicamente, puede ser una entrega incremental e iterativa, pero la ausencia de un ciclo de retroalimentación real lo hace muy arriesgado, y definitivamente no es ágil.

De ahí el título "No así".

Segundo ejemplo: ¡así!

Ahora para la segunda fila.

Aquí adoptamos un enfoque muy diferente. Comenzamos con el mismo contexto: el cliente pidió un automóvil. Pero esta vez no solo construimos un automóvil. En su lugar, nos centramos en la necesidad subyacente que el cliente quiere que se satisfaga. Resulta que su necesidad subyacente es "Necesito ir de A a B más rápido", y el Carro es solo una posible solución para eso. Recuerda, el automóvil es solo una metáfora, piensa en cualquier tipo de situación de desarrollo de productos personalizados.

Entonces, el equipo ofrece lo más pequeño que se les ocurre que hará que el cliente pruebe cosas y nos dé su opinión. Algunos podrían llamarlo MVP (Producto mínimo viable), pero yo prefiero llamarlo Producto Comprobable más Temprano (más sobre esto más adelante).

Llámalo como quieras (algunos incluso llaman a su primer lanzamiento "la versión en patineta" del producto, basándose en esta metáfora...).

Es poco probable que el cliente esté satisfecho con esto porque no está cerca del auto que ordenó. ¡Pero eso está bien! Aquí está el truco: no estamos tratando de hacer feliz al cliente en este momento. Podríamos hacer felices a algunos de los primeros en adoptarlo (o a los pragmáticosque están sufriendo), pero nuestro principal objetivo en este momento es simplemente aprender. Idealmente, el equipo explica esto claramente al cliente con anticipación, para que no se sienta demasiado decepcionado.

Sin embargo, a diferencia de la rueda delantera en el primer escenario, la patineta es en realidad un producto utilizable que ayuda al cliente a pasar de A a B. No es genial, pero es un poquito mejor que nada. Entonces le decimos al cliente "no se preocupe, el proyecto no está terminado, esta fue solo la primera de muchas iteraciones. Seguimos intentando fabricar un coche, pero mientras tanto, intente esto y envíenos sus comentarios”. Piensa en grande, pero entrega en pequeños incrementos funcionalmente viables.

Podríamos aprender algunas cosas realmente sorprendentes. Supongamos que el cliente dice que odia la patineta, le preguntamos por qué y dice "Odio el color". Estamos como "uh... ¿el color? ¿Eso es todo?". Y el cliente dice “¡Sí, hazlo azul! Aparte de eso, ¡está bien!”. ¡Acabas de ahorrar *mucho* dinero sin construir el auto! No es probable, pero ¿quién sabe?

La pregunta clave es "¿Cuál es la forma más barata y rápida en que podemos empezar a aprender?" ¿Podemos entregar algo incluso antes que una patineta? ¿Qué tal un tiquete de autobús?

¿Ayudará esto a resolver el problema del cliente? Tal vez, tal vez no, pero definitivamente aprenderemos algo al poner esto en manos de usuarios reales. Lean Startup ofrece un gran modelo basado en enumerar sus hipótesis reales sobre los usuarios y luego trabajar sistemáticamente para validarlas o invalidarlas.

No es necesario que pruebes el producto en todos los usuarios y no es necesario crear un producto para probar algo. Probar un prototipo incluso en un solo usuario te enseñará más que nada.

Pero bueno, volvamos al ejemplo de la patineta.

Después de jugar con él en la oficina, el cliente dice: “Está bien, es un poco divertido y me lleva a la máquina de café más rápido. Pero es inestable. Me caigo con demasiada facilidad”.

Así que en la próxima iteración intentamos resolver ese problema, o al menos aprender más sobre él.

¡El cliente ahora puede moverse por la oficina sin caerse!

¿Contento? En realidad, no, todavía quiere ese coche. Pero mientras tanto, en realidad está usando este producto y nos está dando su opinión. Su mayor queja es que es difícil viajar distancias más largas, como entre edificios, debido a las ruedas pequeñas y a la falta de frenos. Entonces, el siguiente lanzamiento, el producto se transforma en algo así como una bicicleta.

Ahora el cliente puede moverse por el campus. ¡Yiihaaa!

Aprendemos algunas cosas en el camino: al cliente le gusta la sensación de aire fresco en su rostro. El cliente está en un campus y el transporte consiste principalmente en desplazarse entre edificios.

La bicicleta puede llegar a ser un producto mucho mejor que el automóvil que se imaginó originalmente. De hecho, mientras probamos este producto, podemos aprender de todos modos que los caminos son demasiado estrechos para un automóvil. ¡Le ahorramos al cliente toneladas de tiempo y dinero, y le dimos un producto mejor en menos tiempo!

Ahora puedes estar pensando "¿pero no deberíamos haberlo sabido ya a través de un análisis inicial del contexto y las necesidades del cliente?" Buen punto. Pero en la mayoría de los escenarios de desarrollo de productos de la vida real que he visto, no importa cuánto análisis inicial hagas, todavía te sorprendes cuando pones la primera versión real en manos de un usuario real y muchas de tus suposiciones resultan estar muy lejos.

Entonces, sí, haz algo de análisis inicial, descubre todo lo que puedas antes de comenzar el desarrollo. Pero no le dediques demasiado tiempo y no confíes demasiado en el análisis; en su lugar, comienza a crear prototipos y a publicar, ahí es cuando ocurre el verdadero aprendizaje.

Como sea, volviendo a la historia. Quizás el cliente quiera más. A veces necesita viajar a otra ciudad y el paseo en bicicleta es demasiado lento y sudoroso. Entonces, en la próxima iteración agregamos un motor.

Este modelo es especialmente adecuado para software, ya que el software es, bueno, Soft. Puedes "transformar" el producto a medida que avanzas, a diferencia del hardware en el que esencialmente debes reconstruir cada vez. Sin embargo, incluso en proyectos de hardware, la entrega de prototipos tiene un gran beneficio para observar y aprender de cómo el cliente usa su producto. Es solo que las iteraciones tienden a ser un poco más largas (meses en lugar de semanas). Incluso las empresas de automóviles reales como Toyota y Tesla hacen muchos prototipos (bocetos, modelos 3D, modelos de arcilla a gran escala, etc.) antes de desarrollar un nuevo modelo de automóvil.

¿Y ahora qué? Una vez más, tal vez el cliente esté contento con la motocicleta. Podríamos finalizar el proyecto antes de lo planeado. La mayoría de los productos están plagados de complejidad y características que nadie usa. El enfoque iterativo es realmente una forma de entregar menos o encontrar la forma más sencilla y económica de resolver el problema del cliente. Minimiza la distancia a Impresionante. Muy zen.

O, nuevamente, el cliente puede optar por continuar, con o sin modificaciones a los requisitos. De hecho, podemos terminar con exactamente el mismo automóvil que se imaginó originalmente. Sin embargo, es mucho más probable que obtengamos conocimientos vitales en el camino y terminemos con algo ligeramente diferente. Me gusta esto:

¡El cliente está encantado! ¿Por qué? Porque en el camino aprendimos que aprecia el aire fresco en su rostro, así que terminamos con un descapotable. Después de todo, consiguió un coche, ¡pero mejor de lo planeado originalmente!

Así que retrocedamos un paso.

¿Cuál es tu patineta?

El escenario principal (entregar una llanta delantera) apesta porque seguimos entregando cosas que el cliente no puede usar en absoluto. Si sabes lo que estás haciendo (tu producto tiene muy poca complejidad y riesgo, tal vez hayas construido ese tipo de cosas cientos de veces antes), entonces sigue adelante y haz una única entrega tipo “big bang”. Construye la cosa y entrégala cuando esté lista.

Sin embargo, la mayoría de los esfuerzos de desarrollo de productos que he visto son demasiado complejos y arriesgados para eso, y el enfoque del Big Bang con demasiada frecuencia conduce a fallas enormes y costosas. Entonces, la pregunta clave es ¿Cuál es tu patineta?

En el desarrollo de productos, una de las primeras cosas que debes hacer (después de describir qué problema estás tratando de resolver para quién) es identificar su equivalente en patineta. Piensa en la patineta como una metáfora de lo más pequeño que puedes poner en manos de usuarios reales y obtén retroalimentación real. O usa un "boleto de autobús" si esa metáfora funciona mejor.

Esto te dará el circuito de retroalimentación vitalmente necesario y te dará a ti y al cliente el control sobre el proyecto; puedes aprender y hacer cambios, en lugar de simplemente seguir el plan y esperar lo mejor.

Veamos algunos ejemplos de la vida real.

Ejemplo 1: reproductor de música Spotify

“Con más de 75 millones de usuarios, es difícil recordar un momento sin Spotify. Pero hubo una época en la que todos estábamos reflexionando sobre los pasillos de Target en busca de nuevos CD. Un momento de nuestras vidas en el que todos nos convertimos en ladrones en Napster. Una época en la que iTunes nos obligaba a comprar canciones por 2 dólares la pieza. Y luego vino Spotify". –Tech Crunch.

Spotify es un producto bastante elegante ahora. Pero no empezó de esa manera. Tuve la suerte de estar involucrado muy temprano en este viaje increíble (y todavía lo estoy).

Como startup en 2006, Spotify se fundó sobre algunas suposiciones clave: que la gente está feliz de transmitir (en lugar de poseer) música, que los sellos discográficos y los artistas están dispuestos a permitir que la gente lo haga legalmente y que la transmisión rápida y estable es técnicamente factible. Recuerda, esto fue en 2006 cuando la transmisión de música (como Real Player) era una experiencia bastante horrible, y la música copiada por piratas era prácticamente la norma. La parte técnica del desafío fue: “¿Es posible crear un cliente que transmita música instantáneamente cuando presionas el botón Reproducir? ¿Es posible deshacerse de esa molesta barra de progreso de 'Buffering'?"

Empezar de a poco no significa que no puedas pensar en grande. Este es uno de los primeros bocetos de lo que tenían en mente:

Pero en lugar de pasar años construyendo todo el producto y luego averiguar si las suposiciones se mantenían, los desarrolladores básicamente se sentaron y piratearon un prototipo técnico, pusieron cualquier música copiada que tuvieran en sus computadoras portátiles y comenzaron a experimentar salvajemente para encontrar formas de hacer que la reproducción fuera rápida y estable. La métrica de conducción fue "¿cuántos milisegundos se necesitan desde que presiono Reproducir hasta que escucho la música?". ¡Debería reproducirse casi instantáneamente y continuar reproduciéndose sin problemas sin tartamudear!

“Pasamos una gran cantidad de tiempo enfocándonos en la latencia, cuando a nadie le importaba, porque estábamos empeñados en hacer que pareciera que tenías toda la música del mundo en tu disco duro. Obsesionarse con los pequeños detalles a veces puede marcar la diferencia. Eso es lo que creo que es el mayor malentendido sobre el concepto de producto mínimo viable. Esa es la V en el MVP". -Daniel Ek, cofundador y CEO.

Una vez que tenían algo decente, comenzaron a probarse a sí mismos, con su familia y amigos.

La versión inicial no se pudo lanzar a una audiencia más amplia, estaba totalmente sin pulir y básicamente no tenía características excepto la capacidad de encontrar y reproducir algunas canciones codificadas, y no había acuerdo legal o modelo económico. Era su patineta.

Pero descaradamente pusieron la patineta en manos de usuarios reales, – Amigos  y familiares –  y rápidamente obtuvieron las respuestas que necesitaban. Sí, era técnicamente posible. Y sí, a la gente le encantó el producto (o más bien, ¡en lo que el producto podía convertirse!) ¡Las hipótesis fueron validadas! Este prototipo en ejecución ayudó a convencer a los sellos discográficos y a los inversores y, bueno, el resto es historia.

Ejemplo 2: Minecraft

Minecraft es uno de los juegos más exitosos en la historia del desarrollo de juegos, especialmente si se tiene en cuenta el costo de desarrollo. Minecraft es también uno de los ejemplos más extremos de la mentalidad de lanzamiento temprano y frecuente. El primer lanzamiento público se realizó después de solo 6 días de codificación, ¡por un solo hombre! No se podía hacer mucho en la primera versión: era básicamente un paisaje en 3D feo y en bloques donde se podían desenterrar bloques y colocarlos en otro lugar para construir estructuras toscas.

Esa fue la patineta.

Sin embargo, los usuarios estaban muy comprometidos (la mayoría de las comunicaciones entre desarrolladores y usuarios se realizaban a través de Twitter, bastante divertido). Entre los primeros usuarios estábamos mis cuatro hijos y yo. Se realizaron más de cien lanzamientos durante el primer año. El desarrollo de juegos es todo acerca de encontrar la diversión (algunas compañías de juegos con las que he trabajado usan el término "Definición de Diversión" en lugar de "Definición de Terminado"), y la mejor manera de hacerlo es haciendo que personas reales efectivamente jueguen ese juego. – En este caso, se trataba de miles de personas reales que habían pagado para probar la versión de acceso anticipado y, por lo tanto, tenían un incentivo personal para ayudar a mejorar el juego.

Gradualmente, se formó un pequeño equipo de desarrollo alrededor del juego (en realidad, eran 2 chicos), y el juego se convirtió en un gran éxito en todo el mundo. No creo haber conocido a ningún niño en ninguna parte que no jugara Minecraft. Y el año pasado, el juego (bueno, la compañía que se formó alrededor del juego) se vendió a Microsoft por $ 2.5 mil millones. Bastante sorprendente.

Ejemplo 3: Un gran proyecto gubernamental

Alrededor de 2010, la policía sueca lanzó una gran iniciativa para permitir que la policía pasara más tiempo en el campo y menos en la estación: PUST (Polisens Utrednings STöd). Un proyecto fascinante, participé como coach y escribí un libro sobre lo que hicimos y lo que aprendimos (Lean from the Trenches).

La idea era colocar computadoras portátiles en los automóviles y software personalizado para que la policía tuviera acceso a los sistemas que necesitaran en tiempo real, por ejemplo, mientras se interroga a un sospechoso (estábamos en la era anterior a las tabletas).

Habían intentado construir sistemas similares en el pasado y fracasaron estrepitosamente, principalmente debido al pensamiento Big Bang. Me dijeron que uno de sus intentos anteriores tomó 7 años desde el inicio hasta el primer lanzamiento. ¡SIETE AÑOS! Para entonces, por supuesto, todo había cambiado y el proyecto fue un fracaso total. Así que esta vez querían hacerlo de otra manera.

El proyecto de 60 personas (más tarde denominado "PUST Java") tuvo un éxito sorprendente, especialmente por ser un gran proyecto gubernamental (incluso quedó en segundo lugar en los premios CIO "Proyecto del año"). Uno de los principales factores de éxito fue que no intentaron construir todo de una vez, sino que dividieron al elefante en dos dimensiones:

• Por región. No es necesario que lo publiquemos en TODA Suecia a la vez, podríamos comenzar publicando solo en una región.
• Por tipo de delito. No es necesario que soportemos TODOS los tipos de delitos inicialmente, podríamos comenzar apoyando solo 1-2 tipos de delitos.

La primera versión, la 1.0, fue su patineta.

Era un sistema pequeño, que soportaba solo un par de tipos de delitos, y se probó sobre el terreno con un puñado de policías en Östergötland (una región de Suecia). Otros tipos de delitos tenían que tratarse a la antigua: conducir hasta la estación y hacer el papeleo. Sabían que eran conejillos de indias y que el producto no estaba ni cerca de estar terminado. Pero estaban felices de probarlo, porque conocían la alternativa. Habían visto qué tipo de sistemas asquerosos surgían de procesos que carecían de retroalimentación temprana de los usuarios, ¡y ahora finalmente tenían la oportunidad de influir en un sistema mientras se estaba construyendo!

Sus comentarios fueron duros y honestos. Muchas de nuestras suposiciones volaron por la ventana, y uno de los grandes dilemas fue qué hacer con todas las especificaciones de casos de uso cuidadosamente elaboradas que se estaban volviendo cada vez menos relevantes a medida que llegaba la retroalimentación de los usuarios reales (esta era una organización con un historial en cascada y el hábito de hacer un extenso análisis al principio de los proyectos).

De todos modos, en pocas palabras, la retroalimentación temprana se canalizó hacia mejoras del producto y, gradualmente, a medida que a los policías de Östergötland les empezó a gustar el producto, pudimos agregar más tipos de delitos y difundirlo a más regiones. Para cuando llegamos al gran lanzamiento (1.4), con el despliegue a nivel nacional y la capacitación de 12000 policías, no estábamos tan preocupados. Habíamos hecho tantos lanzamientos, tantas pruebas de usuarios, que dormimos bien la noche del lanzamiento nacional.

Desafortunadamente, la victoria duró poco. Un proyecto de seguimiento (PUST Siebel) lo estropeó y volvió al pensamiento de cascada, probablemente debido a un viejo hábito. 2 años de análisis y pruebas sin lanzamientos ni pruebas de usuario, seguidos de un lanzamiento espectacular de la "próxima generación" del producto para los 12.000 policías a la vez. Fue un desastre absoluto, y después de medio año de hemorragia cerraron todo. El costo del desarrollo fue de unos 20 millones de euros, pero los estudios internos estiman que el coste para la sociedad sueca (porque la policía se vio perjudicada por el horrible sistema) fue del orden de mil millones de euros.

¡Una forma bastante cara de aprender!

Ejemplo 4: Lego

Actualmente estoy trabajando en Lego y estoy asombrado por su capacidad para ofrecer nuevos éxitos, año tras año, sin falta. Escucho muchas historias interesantes sobre cómo hacen esto, ¡y el tema común es la creación de prototipos y las primeras pruebas de usuario! A menudo veo grupos de niños en la oficina y los diseñadores colaboran con los jardines de infancia, las escuelas y las familias locales para probar sobre el terreno las últimas ideas de productos.

Aquí hay un ejemplo reciente: Nexo Knights (lanzado en enero de 2016):

Cuando comenzaron a explorar este concepto, hicieron prototipos en papel y se los llevaron a los niños pequeños. La primera reacción de los niños fue "oye, ¿quiénes son los malos? ¡No veo quién es bueno y quién es malo!". ¡Ups! Así que los diseñadores siguieron iterando y probando hasta que encontraron un diseño que funcionó con los niños. Apuesto a que incluso tú puedes ver quién es el bueno y quién es el malo en la imagen de arriba...

No estoy seguro de dónde está exactamente la patineta en esta historia, pero entiendes la idea: ¡retroalimentación temprana de usuarios reales! No te limites a diseñar el producto y construirlo todo. ¡Imagínate si hubieran construido el producto basándose en sus supuestos de diseño originales y hubieran aprendido sobre el problema después de entregar miles de cajas a tiendas de todo el mundo!

Lego también tiene su parte de fracasos duramente ganados. Un ejemplo es Lego Universe, un mundo Lego en línea multijugador masivo. Suena divertido, ¿eh? El problema es que se volvieron demasiado ambiciosos y terminaron tratando de construir todo a la perfección antes de lanzarlo al mundo.

Aproximadamente 250 personas trabajaron durante 4-5 años (por el constante cambio de alcance debido al perfeccionismo), y cuando finalmente llegó el lanzamiento, la recepción fue... tibia. El juego terminado fue hermoso, pero no tan divertido como se esperaba, por lo que el producto se cerró después de 2 años.

¡No hubo patineta!

¿Por qué no? Porque las patinetas no son geniales (al menos no si esperas un automóvil), y la cultura de Lego se trata de brindar experiencias increíbles. Si trabajas en los cuarteles generales de Lego en Billund, Dinamarca, pasas por este enorme mural todos los días:

Se traduce aproximadamente como "Solo lo mejor es suficientemente bueno". Ha sido el principio rector de Lego desde que la empresa comenzó hace más de 80 años y les ha ayudado a convertirse en una de las empresas más exitosas del mundo. Pero en este caso se aplicó mal el principio. La búsqueda de la perfección retrasó la retroalimentación vital, lo que significó suposiciones erróneas sobre lo que a los usuarios les gusta y no les gusta. Exactamente lo contrario de Minecraft.

Curiosamente, los equipos de Lego Universe estaban usando Scrum e iterando en gran medida, al igual que los chicos de Minecraft. Pero los comunicados fueron solo internos. Así que lo más probable es que hubiera una patineta y una bicicleta, etc., pero esos productos nunca llegaron a los usuarios reales. No es así como se pretende utilizar Scrum.

Fue una falla costosa, pero Lego aprendió de ella y constantemente mejoran en las primeras pruebas y de la retroalimentación de los usuarios.

Mejora sobre el "MVP"

Y eso (respiración profunda…) me lleva al tema de MVP - Producto Mínimo Viable.

La idea subyacente es genial, pero el término en sí mismo causa mucha confusión y angustia. He conocido a muchos clientes que dicen "De ninguna manera quiero una entrega de MVP – ¡esa es la última entrega que recibiré!" Con demasiada frecuencia, los equipos entregan el llamado Producto Mínimo Viable, y luego rápidamente son llevados al siguiente proyecto, dejando al cliente con un producto sin terminar y con errores. Para algunos clientes, MVP = MRC (Basura Mínima Liberable - Minimum Releasable Crap).

Lo sé, lo sé, esto se reduce a una mala gestión en lugar del término MVP, pero aun así... el término invita a malentendidos. “Mínimo” y “Viable” significan cosas diferentes para diferentes personas y eso causa problemas.

Así que aquí hay una alternativa.

En primer lugar, reemplaza la palabra "Mínimo" por "Temprano". La idea principal detrás del lanzamiento de un MVP es obtener retroalimentación temprana: al entregar un producto mínimo en lugar de un producto completo, podemos obtener la retroalimentación antes.

¡Pocos clientes quieren "mínimo", pero la mayoría de los clientes quieren "temprano"! Entonces ese es nuestro primer cambio:

Mínimo => Más temprano

A continuación, elimina la palabra "Viable", ya que es demasiado vaga. Tu "viable" es mi "horrible". Algunas personas piensan que Viable significa “algo que puedo probar y de lo que puedo obtener comentarios”, otras piensan que significa “algo que el cliente realmente puede usar”. Así que seamos más explícitos y dividámoslo en tres cosas diferentes:

El producto comprobable* más temprano es la patineta o el tiquete de autobús, el primer lanzamiento con el que los clientes pueden hacer algo. Puede que no resuelva su problema, pero genera al menos algún tipo de retroalimentación. Dejamos muy claro que el aprendizaje es el objetivo principal de esta versión y que cualquier valor real para el cliente será una ventaja.

El producto utilizable más temprano es quizás la bicicleta. La primera versión que los primeros usuarios realmente usarán, de buena gana. Está lejos de estar terminado y puede que no sea muy agradable. Pero pone a tus clientes en una mejor posición que antes.

El producto adorable más temprano es quizás la motocicleta. El primer lanzamiento que los clientes adorarán, les contarán a sus amigos y por el que estarán dispuestos a pagar. Todavía hay mucho que mejorar y es posible que acabemos con un descapotable, un avión o algo más. Pero hemos llegado al punto en el que tenemos un producto realmente comercializable.

Consideré agregar un paso anterior, "Producto con retroalimentación más temprana", que es básicamente el prototipo en papel o equivalente que usas para obtener tu primera retroalimentación del cliente. Pero cuatro pasos parecen demasiados, y la palabra retroalimentable... ¡Uf! Sin embargo, ese también es un paso importante. Algunos llamarían a un prototipo de papel el Producto que se puede probar más temprano, pero supongo que eso se reduce a cómo se define “Comprobable”. Consulta la Guía de MVP de Martin para conseguir más información – tiene muchos ejemplos muy concretos de cómo obtener retroalimentación temprana con una inversión mínima.

Por supuesto, la gente todavía puede malinterpretar el Más temprano probable / Usable / Adorable, pero es al menos un paso más explícito que el nebuloso Producto mínimo viable.

Puntos para llevarte

Buen momento para terminar. Nunca pensé que sería tan largo, ¡gracias por quedarte! Conclusiones clave:

• Evita la entrega Big Bang para el desarrollo de productos complejos e innovadores. Hazlo de manera iterativa e incremental. Eso ya lo sabías. ¿Pero, lo estás haciendo realmente?
• Empieza por identificar tu patineta, el producto comprobable más temprano. Apunta a las nubes, pero trágate tu orgullo y comienza entregando la patineta.
• Evita el término MVP. Sé más explícito acerca de lo que realmente estás hablando. El más temprano comprobable / utilizable / adorable es solo un ejemplo, usa los términos que sean menos confusos para tus partes interesadas.

Y recuerda: el dibujo de la patineta / automóvil es solo una metáfora. No lo tomes tan literal: o)

PD: aquí hay una historia divertida sobre cómo mis hijos y yo usamos estos principios para ganar una competencia de sumo de robots: o)

Gracias Mary Poppendieck, Jeff Patton, Alistair Cockburn, Anders Haugeto, Sophia, colegas de Crisp, Spotify y Lego, y todos los demás que dieron toneladas de retroalimentación útil.

***

Artículo original de Henrik Kniberg: Making Sense of MVP

***