MVP o prototipo: la distinción que me costó cuatro meses

Todo el mundo en producto dice MVP. Casi nadie quiere decir lo mismo, y la confusión sale cara de una forma muy concreta: acabas con algo demasiado grande para tirarlo y demasiado tosco para quedártelo.

Lo sé porque construí exactamente esa cosa. Me costó cuatro meses.

Qué entendí mal

Mi primera idea de un MVP era la obvia: un producto pequeño pero completo. Menos funciones que el de verdad, pero real: registro, onboarding, ajustes, todo. Algo que pudieras poner delante de la gente sin pedir perdón.

Así que eso construimos. Cuatro meses, tres personas, casi un verano entero.

Se lanzó. Se registraron unas sesenta personas. Once volvieron una segunda vez. Y lo que aprendimos el día del lanzamiento —que el problema que habíamos elegido era real pero ni de lejos lo bastante molesto como para que alguien cambiara lo que ya estaba haciendo— lo podríamos haber aprendido en la segunda semana con una landing y nueve conversaciones.

Los cuatro meses no nos compraron una respuesta mejor. Nos compraron la misma respuesta, más tarde, y además un código que luego nos sentimos obligados a mantener por lo que nos había costado.

MVP o prototipo: la distinción de verdad

Esta es la versión que me habría gustado que alguien me diera.

Los dos son pequeños. La diferencia es qué pasa después, y esa es la parte que decide cuánto te cuesta.

Lo que hace la mayoría de los equipos, y lo que hice yo, es decir MVP, construir un prototipo y luego tratarlo como un MVP por el esfuerzo que ya lleva dentro. Eso es lo peor de los dos: demasiado tosco para conservarlo, demasiado caro para tirarlo.

El orden que sí funciona

Primero la pregunta, y después lo más barato que la responda.

El problema es real? Nueve conversaciones. No «usarías esto?», sino qué hicieron la última vez que pasó el problema. Si la respuesta es «nada», es una preferencia y no un problema. Esta es la versión más pequeña de investigación que existe y cuesta una semana.

Alguien se va a mover por ello? Una landing que describa el producto, con una acción clara. No necesitas el producto. Necesitas saber si la descripción sola basta para que alguien te dé un correo, que es un listón mucho más bajo que pagar y mucho más alto que asentir en una reunión.

Funciona cuando lo tienen? Ahora construye. Y ahora, y solo ahora, aplica la palabra MVP, porque ahora estás construyendo algo que piensas conservar.

Cada paso es lo bastante barato como para que equivocarse se sobreviva. Mis cuatro meses no lo eran.

Lo que sigo haciendo mal

Me gustaría terminar diciendo que ya lo tengo resuelto. No lo tengo.

El fallo en el que sigo cayendo ya no es construir de más: es llamar prototipo a algo para sentirme autorizado a construirlo, y luego no tirarlo. La disciplina no está en cómo lo llamas. Está en tirarlo de verdad cuando ya ha respondido a su pregunta, que es emocionalmente mucho más difícil de lo que suena cuando le has echado un fin de semana y funciona.

He mejorado en esto sobre todo escribiendo, antes de empezar, la pregunta concreta a la que esa cosa existe para responder. Cuando llega la respuesta, el prototipo ya no tiene ningún propósito, y eso se ve mucho mejor sobre el papel que en caliente.

Si estás a punto de construir uno

Y si te llevas una sola línea de aquí: un MVP no es un producto pequeño, es un experimento que resulta estar hecho de producto. Si no sabes decir qué tendría que pasar para que el experimento fallara, no estás haciendo ninguno.

Preguntas que me hacen sobre esto

Cuál es la diferencia entre un MVP y un prototipo?

Un prototipo responde a una pregunta y luego se tira. Un MVP es lo más pequeño que estarías dispuesto a conservar y a cobrar. Los dos son pequeños; la diferencia es qué pasa después. La mayoría de los equipos dicen MVP, construyen un prototipo y luego se sienten obligados a mantenerlo, que es la versión cara de las dos cosas.

Un MVP tiene que ser software funcionando?

No. La idea es aprender si el problema es real y si alguien se va a mover por él, y el software suele ser la forma más lenta de averiguarlo. Una landing, una hoja de cálculo que rellenas a mano o nueve conversaciones responden a la misma pregunta en una fracción del tiempo.

Cuándo es un MVP demasiado pequeño?

Es demasiado pequeño cuando ya no puede responder a la pregunta para la que lo construiste. Esa es la única prueba que importa. Una versión sin onboarding, sin ajustes y sin la mitad de las funciones está perfecta si la pregunta es si la gente quiere lo central siquiera.

Cómo sabes si tu MVP ha funcionado?

Alguien lo usó una segunda vez, por su cuenta, sin ti delante. Los registros, los cumplidos y el entusiasmo en una demo son reacciones a ti, no al producto. El uso repetido es lo único de todo eso que sobrevive a que salgas de la sala.