Mi novia usa un tono dulzón para este diálogo:
—Mi amor.
—¿Qué, mi cielo?
—Tengamos un MVP.Ingenioso. Desconcertante. Terrorífico.
¿Quién querría tener un MVP?
Puede que no tengamos claro qué es un MVP
El origen y desarrollo teórico de este concepto tiene más drama que telenovela de la tarde: gente que dice que lo creó, gente que dice que ya existía o que lo aplicaba desde antes, gente que dice que a lo de antes y a lo de ahora le dio una vuelta superadora, gente que asegura que esa vuelta superadora no es en verdad superadora, y vuelta a empezar.
Si el saber no fuera poder, no habría tantas “guías definitivas” para crear nuestros propios “productos mínimos viables”.
Por eso podemos encontrar diversas definiciones de MVP. Repasemos las de algunas de las voces fundacionales.
SyncDev, la empresa que preside Frank Robinson, aparentemente la garganta que primero dijo emvipí fuera de una cancha de básquet, dice en su sitio web que es “ese producto único que maximiza rentabilidad sobre riesgo para el proveedor y el cliente”.
Más centrado en las personas usuarias, Eric Ries, autor de The Lean Start Up, dice que “es esa versión de un nuevo producto que le permite a un equipo recolectar la mayor cantidad de aprendizajes sobre los clientes con el mínimo esfuerzo”. En esa línea distingue: “A diferencia de la investigación de mercado tradicional, el MVP está basado en el comportamiento del cliente, no en su opinión”.
Steve Blank, creador de metodologías de desarrollo de cliente, dice qué es y qué no es un MVP: “Es un pequeño experimento que estás corriendo de cara a los clientes. No es una versión más pequeña y barata del ‘gran producto’. El MVP es un atajo al aprendizaje”.
Me llamó la atención que los blogs de dos referentes del paradigma iterativo con foco en productos tecnológicos estén basados en templates de hace dos décadas:
Este es el blog de Steve Blank.
En casa de herrero, cuchillo de palo.
Entonces, ¿qué es un MVP? ¿Una versión mínima y barata del producto o un experimento? ¿Un producto, el prototipo de un producto o una prueba de concepto del producto? ¿“Ese producto único que maximiza la rentabilidad” o un medio para alcanzarlo? ¿Una metodología recetada para startups o para todo tipo, tamaño y recorrido de empresas y productos?
Podés constatar estas diferencias en libros, artículos y podcasts: ¡hay definiciones, opiniones, casos de éxito y fracaso para todo gusto e interés! Y no siempre vienen con el detalle de a qué enfoque suscriben, lo cual hace que indagar al respecto sea un tanto difícil y confuso.
Un gran problema es que esas diferentes definiciones de MVP conviven al interior de las empresas para las que trabajamos, y acaso porque es un concepto que tiene más de dos décadas y que a esta altura —creemos— debería ser obvio, damos por sentado que estamos hablando de lo mismo. Not.
Quiero mencionar dos factores que agudizan estas divergencias.
Por empezar, la fragmentación del producto, que puede ser in-house o a través de proveedores. Hablando mal y pronto, consiste en la división de un gran producto en un conjunto de “productitos”, partes más pequeñas. En empresas de tecnología que trabajan sobre MVPs y tienen múltiples product owners y equipos de IT desalineados en esta definición, el gran producto deviene en un conjunto desparejo, de relieves y asincronías, que son las que al cabo las personas usuarias vivencian como a un todo.
Si en la pileta de la cocina el agua te llega con poca presión, en la pieza hace mucho calor, en el living tenés humedad y en el baño no hay espacio para moverte, es más posible que entiendas que la casa que estás alquilando no está buena y no que se trata de detalles aislados, con responsables diferenciados. Es decir, si la casa no está buena por esa “resta” de partes, es un tema de arquitectura, no de albañilería. Si podés, te vas de la casa. Aún aunque cumpla su objetivo más importante: ofrecerte refugio y habitación.
El segundo factor es el dinamismo de la industria en lo que respecta a talento humano. Las empresas de tecnología con productos más o menos exitosos crecen a ritmos acelerados, y eso implica la constante entrada y salida de profesionales que van y vienen de distintos tipos de empresa (distintas industrias, tamaños, culturas, liderazgos, etcétera) y con distantes visiones y prácticas a propósito del concepto de MVP.
Hace unos días charlaba con un colega UX que ahora trabaja en una reconocida fintech, y me contaba que, a diferencia de su experiencia previa, los MVPs se piensan “desde arriba”, como Leopoldo Marechal salía de los laberintos. En su laburo anterior, el MVP era el primer diseño de un producto; en el actual, el equipo diseña una foto final (que no está escrita en piedra, pero que es, como dice Daniel Mordecki, “el faro hacia el que se dirige todo el proyecto”), y a esa foto le quitan los features que, muy a conciencia, al contrastarlos con los dolores y objetivos principales de los usuarios, resultan prescindibles.
Estos factores son apenas un par de entre tantos. Lo importante, hasta aquí, es tener presente que hablar de MVP es como hablar de libertad: que la idea suene linda no implica que en los hechos estemos hablando de lo mismo.
—¡Quedamos en que ibas a limpiar y solamente sacaste algunas cosas del medio!
—Hice el mínimo esfuerzo viable para que hagas lo que necesitás hacer.
Puede que hacer MVPs sea sinónimo de malas experiencias para las personas usuarias
Lo lindo del MVP es que sintoniza con la manera en la que los seres humanos creamos desde que fabricamos nuestras primeras herramientas para comunicarnos, construir, cultivar, cazar y defendernos de depredadores. La cultura es iterativa, por supuesto con ritmos más o menos dinámicos en sus distintas esferas.
Cuando era niño, tenía en casa un librito que contaba la evolución de ciertos inventos. Recuerdo en especial los dibujitos que ilustraban la del martillo, que eran algo así:
En algunas pocas situaciones una piedra puede resultar un perfecto martillo. Pero si alguna vez martillaste clavos o estacas con una roca, sabés que hacerlo en un mundo con martillos es un bajón: la piedra no te entra bien en la mano, hacés más fuerza, se hace polvo a cada estocada, te podés lastimar un dedo.
Una piedra puede cumplir el objetivo de un martillo, pero qué duda cabe de que no será una experiencia lo feliz que sería con la herramienta que diseñamos para suplir esa que la naturaleza nos dejó en el piso.
El valor del MVP es menos su novedad que su carácter de paradigma para el diseño de productos digitales: a groso modo, si antes creábamos productos digitales partiéndolos en fases, tardándonos mucho tiempo y dinero hasta terminarlos y manteniéndolos mientras trabajábamos en el siguiente producto; ahora, y en provecho de las ventajas que nos da Internet, generamos versiones económicas en poco tiempo que podemos probar y mejorar de modo continuo. Con ambos enfoques podés fallar, pero con el segundo fallás barato.
Si tenés más de 30, quizás hayas identificado este cambio de mindset en algunos de tus sitios web favoritos: antes de la banda ancha, cambiaban completamente de un momento a otro, y ahora lo van haciendo poco a poco, lo que resulta más rentable para quienes los sustentan y hasta algo más amigable para el modo en que vivimos esta realidad hipercambiante. Siempre que pienso en estas cosas vuelve a mí el concepto de “ciudad pánico”, del teórico cultural Paul Virilo.
Ese pasaje de modelos es lo que representa el diagrama que dibujó hace menos de diez años Henrik Kniberg, que hoy diseña y desarrolla para la serie de videojuegos Minecraft y que trabajó para Spotify y Lego. Verán que evoca un poco a las ilustraciones de mi librito de inventos:
Aunque se viralizó y todavía es citado para representar lo que es un MVP, este diagrama recibió unos cuantos challenges, muchos sobre la certeza de que las necesidades que satisface una patineta como MVP están lejos de ser las que satisface un automóvil como producto final, incluso aunque ambas tecnologías te lleven de A a B más rápido que a pie.
El propio Henrik escribió una columna para decir que lo estaban malinterpretando. Esa columna tiene un pasaje esclarecedor con respecto al diseño de experiencia de usuario: “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, pero nuestro principal objetivo en este momento es simplemente aprender”.
Vale aclarar que con “clientes” se refiere a “gerentes de productos, dueños de productos y usuarios pioneros en la adopción”. Aún así, ahí tenemos una primera pista: cuando hacemos MVPs, dice Henrik, no estamos tratando de hacer felices a los clientes. ¿Esto está bien? No me lo pregunto solo en relación a las implicancias éticas de hacer MVPs, sobre lo que reflexionaré en el tercer apartado de este texto; me lo pregunto en relación al objetivo principal que él enuncia y que sintoniza con la centralidad de las personas usuarias en el oficio del diseño UX: si queremos iterar con inteligencia, ¿de qué calidad es lo que aprendemos de personas usuarias que pidieron un auto y recibieron una patineta?
En el artículo que cité más arriba, Mordecki responde: “Una patineta no es un auto bebé, ni un auto es una patineta con esteroides. Son dos productos distintos. Y lo fundamental: nada podemos aprender de cómo diseñar un auto a partir de una patineta”. Al googleo, proliferan las relecturas del diagrama de Henrik, pero reproduzco la del uruguayo porque empatizo con su acidez:
¿Ven porqué es clave que estemos alineados sobre lo que es un MVP? Sin ese acuerdo básico, podríamos tener a un tercio del equipo esperando una rueda, a otro tercio una patineta y al restante el chasis de un automóvil, dependiendo de la bibliografía a la que suscriba cada fracción. ¡Imaginen cuán ágiles pueden ser las reuniones en las que vamos mostrando avances de diseño a stakeholders que están pusheando con distintas expectativas!
Si el objetivo de un MVP es aprender a costa de la satisfacción de las personas usuarias, el mínimo producto viable se parece más a la “antítesis del buen UX”, como zanja Kara Pernice, vicepresidenta senior de Nielsen Norman Group, en este breve video:
Los problemas del MVP que Pernice detalla me resonaron: codear y lanzar la presunta solución en lugar concebirla como una hipótesis y testear antes su usabilidad con un prototipo; lograr un producto cohesivo cuando se parte de un MVP “desde abajo”, sin haber imaginado el producto final; y las fricciones que pueden surgir al pretender iterar el código, con el contrargumento del esfuerzo ya dedicado y del que se vislumbra a futuro, algo que se convierte en una limitante adicional y evitable para diseñar mejores experiencias, y que incluso deviene en negociaciones que pueden consumir demasiado tiempo y esfuerzo, y que llegan a darse vuelta solo cuando el fracaso es rotundo y la decisión derrama desde los altos mandos.
Pensá en una de tus cosas favoritas: puede ser un gusto de helado, una serie, una bebida, un libro, un viaje, una salida, lo que sea. Ahora imaginá que le sacás todo lo que puedas sacarle sin que pierda su esencia. ¿Lo tenés? Genial. Ahora reducí a la mitad lo que te quedó. ¡Muy bien! Lo que estás viendo es un MVP. ¿Sigue siendo una de tus cosas favoritas?
Puede que hacer MVPs tenga un trasfondo ético
Cada vez más, todo lo que hacemos tiene su contracara digital. Cada vez más, los hábitos que eran parte de tu cotidianidad física, las cosas que hacías todos los días en el mundo real, se pueden resolver a través de una pantalla: comprar lo que sea, gestionar tu dinero, sacar un turno con el médico, hacer esa misma consulta con el médico, cursar una carrera, hablar con personas del otro lado del planeta y encontrarte con gente que querés. A esta altura me parece obvio desarrollar para quienes imagino que leerán este artículo que esos cambios acarrean tanto efectos positivos como negativos, y que es importante identificar, entender y proponer soluciones inclusivas para los segundos.
La pandemia mundial por el coronavirus y las consecuentes medidas adoptadas por los Estados de todo el globo evidenciaron más que en otros contextos la potencia de las soluciones digitales. Por caso, la videollamada, que era una herramienta que se usaba con modestia, pasó a ocupar un lugar central para quienes tenemos la fortuna de realizar trabajos desde casa. También hubo tecnologías más transversales a la comunidad, en este contexto que hay quienes vaticinan menos extraordinario que lo que deseamos: en Buenos Aires y muchas otras provincias, la inscripción para la vacuna y la asignación de turnos se realizó a través de aplicaciones y sitios web, con el objetivo de reducir la concurrencia a lugares físicos en momentos de distanciamiento.
Okey, ¿pero qué tiene que ver esto con MVPs? Todo. Por ejemplo, el enfoque del producto mínimo viable suele redundar en una erosión de lo que en diseño de producto llamamos “casos”. Los casos son descripciones de las actividades que deberá realizar alguien muy específico, una persona usuaria con determinadas necesidades, para llevar a cabo algún proceso. Un MVP no suele estar dirigido a todos, sino solo a la mayoría. Un menú que debería tener diez opciones, en un MVP productivo tiene solo dos, y así la experiencia de las personas de esa minoría, que no encuentran la opción que necesitan, se puede transformar en un verdadero suplicio si, como durante estos últimos años, su salud depende de ello.
Si un MVP reduce pantallas y features que podrían ayudarme a entender las implicancias de invertir en un fondo de inversión, quizás termine perdiendo mis únicos ahorros sin conocer que eso era siquiera posible. Un producto financiero pobre online también podría provocar que una persona empleadora no cuente con el dinero con el que esperaba para pagarles a quienes trabajan en su compañía, y esas son familias que no recibirán a tiempo el dinero que usan para vivir. El MVP implementado de un apartado de deudas podría no incluir algunos tipos de deuda: entro a la app, veo que no debo nada, y sin saberlo mis números rojos por un producto no incluido crecen en alguna otra parte del homebanking. Es más probable que con menos pantallas y funciones contemos solo una parte de la historia que si contamos con un producto más integral.
Estas situaciones suenan melodramáticas, pero estoy seguro de que podríamos encontrar más de un episodio real con los mismos ribetes y que atentan contra los derechos de las personas consumidoras. No son exactamente dark patterns, asociados a prácticas desleales más a conciencia, pero son primos cercanos, porque también las organizaciones definen cómo nacen, viven y conviven sus MVPs, acaso camuflados en el gran producto.
Una pregunta que me suelo hacer es si lanzar un MVP no es como cobrarte un iPhone y entregarte a cambio una paloma mensajera con la manzanita estampada en el lomo. Gato por liebre… ¡pero, ey, cumplen el mismo objetivo!
Y aún a pesar de este enfoque ético, me gusta insistir con que diseñar productos con las personas usuarias en el centro no es por amor al arte, un sesgo que todavía persiste sobre todo en empresas con fines comerciales, pero también en organizaciones sin fines de lucro y en el propio Estado. Como dijo alguna vez Steve Jobs, el diseño no es solo cómo luce o se siente un producto, sino cómo funciona. Y si funciona bien, será tanto una solución para las personas que volverán a usarlo y hasta lo recomendarán. Por eso, el abuso de MVPs termina afectando el posicionamiento de la marca e incluso la rentabilidad del negocio. ¿Quién de ustedes no recomendó alguna vez una aplicación que les resultó fácil y útil? ¿Quién de ustedes no habló mal de algún sitio web difícil como el de AFIP? Sabiduría popular mata snobeada: lo barato sale caro.
Tenemos la responsabilidad de diseñar no solo productos que les hagan la vida más fácil a las personas sino además de reducir los daños que esos productos puedan provocar. ¿Podemos hacerlo con un conjunto de MVPs nadando a mar abierto?
Palabras finales: puede que hacer UX cuando hacemos MVPs dependa de cómo los entendamos
El MVP no es necesariamente el malo de la película. El MVP es lo que hacés con él. Es una herramienta y un marco de trabajo que nos permite hacer foco y ser eficientes. Pero, para eso, necesitamos alinear al equipo en una definición de MVP, tan minuciosa y centrada en las personas usuarias como sea posible.
¿Es un prototipo o una primera versión productiva? ¿Es una patineta o un chasis? ¿Cómo evitamos que “es para el MVP” suene a “sabemos que es una porquería pero ahora no nos importa”? ¿Cómo nos aseguramos de que el MVP sea una versión eficaz para su propósito y no una manifestación de nuestros egos? ¿Cómo vamos a aprender del MVP? ¿Durante cuánto tiempo y con qué criterios? Si la hipótesis que el MVP representa es correcta, ¿cuál es el siguiente paso? ¿Otro MVP, el de las funciones que le sumemos al primero? ¿Tiene sentido diseñar el mínimo sin diseñar el máximo? ¿Cuántos MVP deberíamos tener corriendo en simultáneo? ¿Necesitamos mapear la convivencia de MVPs productivos? No escatimemos en preguntas. Preguntar es la manera más directa de aprender, solos y en equipo.
Lo que haremos será nuestro propio MVP de una definición final de MVP con la que todo el mundo quede más cerca de ser feliz.
Para terminar de responder si hacemos UX cuando hacemos MVPs, cierro con dos ideas de autores que cité aquí que me gustaron:
Pernice: “Tratá de redefinir qué significa ‘mínimo viable’. Considerá sugerir que el producto sea investigado y hecho para ser lo más realista, útil, usable y atractivo antes de lanzarlo a usuarios que pagan por ese producto”.
Mordecki: “El MVP es una herramienta de diseño, anclada fuertemente en la tarea de definir el producto final antes de comenzar a construirlo. Nada tiene que ver con tirar una construcción rápida, barata y mediocre al mercado, a ver si tenemos suerte y la calabaza se transforma en carroza. Malas noticias: eso sucede solamente en los cuentos de hadas”.
¡Muchas gracias por leerme! 💖
Si te gustó esta historia y querés que otras personas la encuentren, por favor recomendala apretando muchas veces el ícono 👏.
Otra historia que escribí:
