Minimum lovable product: dónde invertir el amor

Un minimum lovable product no es un MVP más pulido. Es un MVP con el amor concentrado en un solo lugar. Cómo un founder no técnico decide adónde va ese amor, y cuándo “lovable” se convierte en una excusa cara para sobredimensionar el producto.

Un founder con el que trabajamos el año pasado llegó al kickoff de un build con una lista de 41 cosas que la primera versión “tenía que sentirse genial”. Animaciones suaves en cada pantalla. Un tour de onboarding a medida. Modo claro y oscuro. Había leído tres artículos sobre cómo construir un minimum lovable product durante el fin de semana y llegó convencido de que “lovable” significaba “pulido en todo”. Ese instinto, más que cualquier error técnico, es lo que hace estallar los primeros builds.

Un minimum lovable product (MLP) es la versión más pequeña de un producto que la gente realmente disfruta usar, no solo tolera. Hace una cosa tan bien que el usuario perdona todo lo que sigue tosco a su alrededor. La palabra que confunde al founder es “lovable”. La lee como una perilla de pulido para girar al máximo. No lo es. El amor es un presupuesto, y toda la habilidad está en decidir dónde gastarlo.

Así que le construimos algo distinto de su lista. Una pantalla, el flujo de reservas que sus clientes tocarían todos los días, quedó genuinamente buena: rápida, obvia, difícil de equivocar. Las otras cuarenta cosas quedaron honestas y simples. Lanzó en siete semanas en lugar de cinco meses. Sus primeros diez clientes nunca mencionaron el modo oscuro. Mencionaron el flujo de reservas, sin que se lo preguntaran, en tres de las cinco primeras llamadas de venta.

Qué es, de verdad, un minimum lovable product

El término viene de Laurence McCahill, de The Happy Startup School, que en 2014 lo propuso como respuesta a un problema real: el minimum viable product original se había agriado hasta volverse una licencia para entregar algo medio roto y llamarlo lean. Su arreglo fue cambiar la pregunta. En lugar de “qué es lo mínimo que podemos construir y aun así lanzar”, pregunta “qué es lo mínimo que podemos construir y que alguien va a amar”.

Es una buena corrección. Pero en algún punto entre 2014 y ahora, “lovable” se aplanó a “más features, mejor diseño, experiencia más completa”. Esa lectura es cómo un founder no técnico termina con una lista de 41 ítems “tiene que sentirse genial” y un build de cinco meses para un producto que nadie ha pagado todavía.

La lectura correcta es más estrecha y más útil. Un minimum lovable product concentra su calidad. Elige el único momento en que el usuario decide si la cosa vale su tiempo y hace que ese único momento sea inconfundiblemente bueno. En todo lo demás, se queda deliberada y visiblemente mínimo. El producto no está pulido por igual. Está desequilibrado a propósito.

Minimum viable product vs minimum lovable product

El debate MVP vs MLP se plantea como pulido versus no pulido, y ese planteo está equivocado. Ambos son mínimos. La diferencia es dónde vive el mínimo.

Un minimum viable product pregunta qué tan pequeño puede ser el alcance y aun así enseñarte algo verdadero sobre la demanda. Su riesgo es ser tan delgado que no valida nada. Ya escribimos sobre por qué la mayoría de los MVP son demasiado pequeños para validar algo real; ese artículo es sobre el tamaño de la cosa.

Un minimum lovable product toma el alcance como más o menos dado y hace otra pregunta: de las cosas que vamos a construir, ¿cuál carga el veredicto? Su riesgo corre en la dirección opuesta. Donde un MVP falla por ser demasiado delgado, un MLP falla por repartir su calidad tan parejo que nada destaca y el presupuesto se acaba antes del lanzamiento. Uno es una decisión de alcance. El otro es una decisión de concentración. Tomas la decisión de MVP primero, después la de MLP dentro de ella.

En claro: la pregunta del MVP es cuánto construimos. La pregunta del MLP es adónde va la calidad. Tratarlas como la misma conversación es cómo los founders terminan o lanzando basura o lanzando tarde.

Cuándo “lovable” se vuelve una excusa para sobredimensionar

Aquí está el modo de falla que ninguno de los primeros resultados de búsqueda te advierte, porque están escritos en su mayoría para product managers de empresas con capital, no para un founder gastando su propio runway.

“Lovable” es la palabra más cara de una reunión de kickoff. No tiene bordes. Cualquier feature puede argumentarse hacia el balde “lovable”, porque toda feature podría, en principio, ser más encantadora. Un dev que quiere construir la cosa sofisticada y un founder que quiere un producto premium estarán de acuerdo entre sí hasta reventar el presupuesto. Hemos visto primeros builds duplicar su costo no porque el alcance creciera, sino porque la palabra “lovable” se aplicó por igual y nadie frenó.

La señal es cuando los pedidos de pulido se pegan a pantallas que el usuario casi no ve. Transiciones animadas en la pantalla de configuración del admin. Un estado vacío bellamente diseñado para un reporte que los primeros clientes no correrán en meses. Eso es craft apuntado al blanco equivocado. Buen diseño es buen negocio, pero diseño gastado donde nadie está mirando es solo costo con ropa elegante.

La disciplina de un MLP de verdad es decir “no, esa parte se queda simple” en voz alta, a propósito, y poder explicar por qué. Si tu estudio nunca te dice que una parte del producto está tosca a propósito, no estás construyendo un MLP. Estás construyendo un producto adorable máximo con presupuesto mínimo, y la cuenta no cierra.

El framework del presupuesto de amor: decidir adónde va el amor

Trata la lovability como un presupuesto fijo que estás asignando, no como un nivel de calidad que estás ajustando. Antes de que arranque el build, pasa las pantallas y flujos candidatos por cuatro preguntas. Las que puntúan más alto se llevan el amor. Todo lo demás puede ser honesto y simple.

1. ¿El usuario lo toca el día uno, o todos los días? El flujo que el cliente toca en su primera sesión, y el que repite a diario, son donde se forman los veredictos. Una pantalla de reservas usada veinte veces por semana se gana el amor. Una exportación masiva usada una vez por trimestre, no.

2. ¿Es el momento en que decide que valemos la pena? Todo producto tiene un lugar donde el usuario te califica en silencio. En una fintech, la primera transacción acreditándose. En un marketplace, el primer match que se siente correcto. Encuentra ese momento y gasta de más ahí, aunque sea una sola pantalla.

3. ¿La tosquedad aquí se lee como roto, o solo como básico? Algunas asperezas se leen como “temprano y enfocado”. Otras se leen como “esta gente no sabe hacer software”. Una pantalla de configuración simple está bien. Un checkout que se siente chueco es fatal, porque el dinero pone nerviosa a la gente y lo chueco se lee como riesgo. Gasta amor donde la tosquedad se leería mal, como incompetencia.

4. ¿Es donde somos diferentes, o donde somos iguales a todos? Vuelca amor en la parte que es tu razón real de existir. Las partes que son básicas, el login, un dashboard simple, pueden verse iguales a las de todos sin costarte nada.

La mayoría de los productos tiene uno, quizá dos flujos que ganan en las cuatro preguntas. Ese es tu presupuesto de amor. Concentra ahí. El trabajo real del framework es darte, founder no técnico, el lenguaje para defender el “déjalo simple” contra una sala llena de gente que sinceramente quiere dejar todo más lindo.

Cómo se ve esto en un build de verdad

El MLP del founder de reservas tenía exactamente una superficie adorable: el flujo de reservas. Gastamos tiempo real de diseño e ingeniería en él. Respuesta por debajo del segundo, sin callejones sin salida, una confirmación que transmitía solidez. Todo detrás de él, la configuración de cuenta, los reportes, las pantallas de gestión de equipo, se construyó para funcionar y nada más. Gris donde gris alcanzaba.

Sus competidores tenían productos más completos. Más configuraciones, más pulido repartido en más pantallas. También tardaban más en lanzar cualquier cosa y se sentían, para un usuario nuevo, como un montón de “está bien” en vez de una cosa que era genial. Seis meses después del lanzamiento, tenía presupuesto y feedback de clientes para hacer también adorables las pantallas de reportes, esta vez sabiendo exactamente qué reportes la gente de verdad corría. Ese es el orden correcto: gánate la próxima superficie, no la preconstruyas.

Un chequeo útil antes de empezar: las decisiones sobre pulido se toman cuando apruebas los diseños, no cuando el código sale. Si no sabes la diferencia entre un wireframe, un mockup y un prototipo, darás feedback cosmético sobre lo estructural y feedback estructural sobre lo cosmético, y tu presupuesto de amor se fugará en el ciclo de revisión antes de escribir una línea de código.

Cómo hacer el brief de un minimum lovable product para un estudio

Si le estás pagando a alguien para construir esto, el brief es donde el presupuesto de amor se define o se pierde. Tres cosas para poner por escrito.

Nombra la única superficie adorable explícitamente. No “que se sienta premium”. Escribe: “El flujo de reservas es la única experiencia que tiene que ser genuinamente buena. Gasten aquí.” Un buen socio cuestionará o confirmará tu elección. Un proveedor caja negra solo dirá que sí y te cobrará por pulido en todo. Los socios de tech no deberían ser cajas negras; el ida y vuelta sobre adónde va la calidad es exactamente la conversación que vale la pena tener.

Nombra lo que se queda simple. Esta es la parte que los founders se saltan, y es la parte que protege el presupuesto. “Configuración, reportes y gestión de equipo deben funcionar correctamente y verse estándar. No gasten tiempo de diseño en hacerlos especiales en la v1.” Poner la tosquedad por escrito la vuelve una decisión en vez de un accidente.

Átalo al dinero. El presupuesto de amor sale del mismo bolsillo que todo lo demás, así que sabe cuál es ese bolsillo. Nuestros textos sobre cuánto cuesta desarrollar una app y sobre la decisión de construir o comprar que está por encima de todo esto cubren los números. La versión corta: cada pantalla que vuelves adorable es una pantalla por la que pagas premium. Una superficie premium entra en casi cualquier presupuesto. Diez es cómo un primer build se convierte, en silencio, en una segunda ronda.

Preguntas frecuentes

¿Cuál es la diferencia entre minimum viable product y minimum lovable product?
Un MVP es sobre alcance: el build más pequeño que aún prueba demanda real. Un MLP es sobre concentración: tomar ese alcance y hacer una experiencia central genuinamente buena, dejando el resto deliberadamente simple. Decides el alcance del MVP primero, después decides, dentro de él, adónde va la lovability. Son secuenciales, no competidores.

¿Qué es un minimum lovable solution?
La misma idea, aplicada a herramientas internas u operativas en lugar de un producto de cara al cliente. La superficie “adorable” es donde tu equipo pasa más tiempo. Un dashboard de operación diaria merece cuidado real; una pantalla de config usada una vez al mes, no. Concentra la calidad donde van las horas.

¿Qué es un minimum acceptable product?
Un minimum acceptable product es el piso: funciona y no te avergüenza, pero ninguna parte está hecha para gustar. Es un objetivo aceptable para una herramienta interna desechable. Es un objetivo débil para cualquier cosa que un cliente elige usar, porque “aceptable” rara vez genera boca a boca. Un MLP cuesta un poco más que un minimum acceptable product y concentra ese costo extra en un solo lugar.

¿Qué es un minimum lovable product en Amazon?
Suele referirse a la práctica de “working backwards” de Amazon, escribir el press release y el FAQ antes de construir. Es un método para forzar claridad sobre qué van a amar los usuarios antes de empezar, compatible con todo lo anterior. Herramienta distinta, mismo instinto: decide qué tiene que ser amado antes de gastar.

¿Dónde debe invertir el amor primero un founder no técnico?
En el único flujo que los clientes más tocan y por el que te juzgan, normalmente la primera acción real que hacen en el producto. Haz que esa cosa sea inconfundiblemente buena. Deja el resto honesto y simple hasta que los clientes te digan qué mejorar después.

Un minimum lovable product no es el máximo que puedes pagar por pulir. Es la única cosa que te niegas a entregar tosca, rodeada de todo lo que tuviste el valor de dejar simple. Elige bien esa cosa, y tus primeros diez clientes te dirán si elegiste correcto.