Lo que un MVP realmente es (y lo que no)

Descripción

En la presentación viste el resultado de un MVP bien diseñado —una tabla fija de recomendaciones que cuesta el 10% del motor completo y prueba la misma suposición—, pero no viste todavía la definición precisa de qué lo convierte en un MVP real y no en, simplemente, "algo pequeño y barato". Esta lección cierra ese hueco: un MVP no se define por su tamaño ni por su costo. Se define por tres condiciones a la vez, y si le falta una sola, no importa cuán pequeño sea, no es un MVP —es otra cosa, con otro nombre—.

Las tres condiciones son: (1) declara explícitamente qué suposición está probando —no "vamos a ver qué pasa", sino una frase concreta que puede resultar falsa—; (2) mide comportamiento real de personas reales, no una opinión declarada sobre lo que dirían que harían; y (3) cuesta una fracción pequeña de construir la apuesta completa. Un candidato que cumple las tres es un MVP. Un candidato que cumple solo una o dos, sin importar cuán de moda esté la palabra "MVP" en la reunión donde se propuso, no lo es.

Conexión con el módulo. La presentación te mostró la aritmética de compareApproaches —esfuerzo y momento de la evidencia—; esta lección te da el criterio para decidir, antes de calcular esa aritmética, si el plan que estás llamando "mvp" en realidad lo es. Sin esta lección, es fácil poner cualquier cosa barata en el lado mvp de la comparación y celebrar el effortRatio bajo, sin haber verificado que esa cosa barata de verdad prueba algo.

Una analogía: la cucharada de la receta, no un plato distinto

Ya usaste esta imagen en la presentación: probar una cucharada de la receta nueva, con las mismas proporciones, antes de cocinar para 50. Vale la pena mirarla con más cuidado, porque de ahí sale exactamente la definición de esta lección.

Imagina tres formas distintas de "probar" la receta antes del sábado:

1. Le preguntas a tu pareja si cree que la receta va a gustar, sin cocinar nada. Es barato, es rápido, pero no probaste la receta —probaste una opinión sobre una receta que nadie probó todavía—.
2. Cocinas dos porciones de un plato distinto y más fácil —arroz blanco, porque tenías los ingredientes a mano— y decides que, si sale bien, la receta original también va a salir bien. Cocinaste algo real, pero no la receta que te interesa: no aprendiste nada sobre la sal, el ácido o el tiempo de cocción de la receta nueva.
3. Cocinas dos porciones de la receta nueva, exactamente con las mismas proporciones, y las pruebas tú mismo antes de servirlas el sábado.

Solo la tercera es una cucharada real. La primera es una encuesta de opinión disfrazada de prueba. La segunda es una prueba real, pero de la receta equivocada. El MVP correcto es siempre la tercera: algo real, de la apuesta que de verdad te interesa, a la escala mínima que la hace barata.

Ejemplo trabajado: isRealMVP, tres candidatos para el checkout de Mercado

El equipo de Mercado tiene tres propuestas distintas, cada una llamada "MVP" por quien la propuso, para probar si simplificar el checkout a 3 pasos mueve la conversión antes de reconstruir todo el flujo (fullEffort: 30 person-days para el checkout rediseñado completo). Vamos a construir un verificador que aplica las tres condiciones a cada una:

// isRealMVP verifica tres condiciones a la vez: que declare una suposicion explicita,
// que mida comportamiento real (no solo opinion), y que sea barato comparado con
// construir todo. Las tres a la vez, no una sola -- ese es el punto de la leccion.
function isRealMVP(candidate, fullEffort) {
  const effortShare = Math.round((candidate.effort / fullEffort) * 100);
  const cheapEnough = effortShare <= 50;
  const passes = candidate.statesAssumption && candidate.measuresRealBehavior && cheapEnough;
  const reasons = [];
  if (!candidate.statesAssumption) reasons.push('no declara una suposicion explicita');
  if (!candidate.measuresRealBehavior) reasons.push('mide opinion, no comportamiento real');
  if (!cheapEnough) reasons.push('cuesta casi lo mismo que construir todo (' + effortShare + '% del effort completo)');
  return {
    name: candidate.name,
    effortShare,
    isRealMVP: passes,
    verdict: passes ? 'es un MVP real' : 'NO es un MVP real: ' + reasons.join('; '),
  };
}

const fullEffort = 30; // construir el checkout nuevo completo, con rediseño visual

const candidates = [
  {
    name: 'Checkout completo, solo sin modo oscuro ni animaciones',
    effort: 27,
    statesAssumption: false,
    measuresRealBehavior: true,
  },
  {
    name: 'Encuesta a compradores: ¿simplificarian el checkout a 3 pasos?',
    effort: 1,
    statesAssumption: true,
    measuresRealBehavior: false,
  },
  {
    name: 'Simplified 3-step checkout, activo para el 10% del trafico real, sin guardar tarjeta',
    effort: 6,
    statesAssumption: true,
    measuresRealBehavior: true,
  },
];

console.log('=== isRealMVP: tres candidatos para el checkout de Mercado ===\n');
candidates.forEach((c) => {
  const r = isRealMVP(c, fullEffort);
  console.log('"' + r.name + '"');
  console.log('  effortShare: ' + r.effortShare + '%');
  console.log('  ' + r.verdict + '\n');
});

Qué esperar. Al correr el archivo con Node, la salida es exactamente esta:

=== isRealMVP: tres candidatos para el checkout de Mercado ===

"Checkout completo, solo sin modo oscuro ni animaciones"
  effortShare: 90%
  NO es un MVP real: no declara una suposicion explicita; cuesta casi lo mismo que construir todo (90% del effort completo)

"Encuesta a compradores: ¿simplificarian el checkout a 3 pasos?"
  effortShare: 3%
  NO es un MVP real: mide opinion, no comportamiento real

"Simplified 3-step checkout, activo para el 10% del trafico real, sin guardar tarjeta"
  effortShare: 20%
  es un MVP real

Los tres resultados enseñan algo distinto. El primer candidato es el error más común de todos: alguien le quitó dos detalles cosméticos al checkout completo y lo llamó "MVP", pero sigue costando el 90% del esfuerzo total y, más grave todavía, nadie declaró qué suposición se supone que prueba —es, literalmente, la v1 con menos features, sin ninguna hipótesis detrás—. El segundo candidato es barato (effortShare: 3%) y sí declara una suposición, pero falla en el segundo criterio: preguntarle a la gente si cree que simplificar ayudaría no es lo mismo que observar si, puestos frente al checkout de 3 pasos de verdad, completan más compras. Es la primera trampa de la analogía de la cucharada: una opinión sobre la receta, no la receta.

El tercer candidato es el único que pasa las tres pruebas: declara la suposición ("un checkout de 3 pasos aumenta la conversión"), mide comportamiento real (compradores reales, con dinero real, en el 10% del tráfico), y cuesta una quinta parte de construir todo. Fíjate en algo importante: no es el más barato de los tres —la encuesta cuesta menos—. Barato no es el criterio; barato y además real y además con una hipótesis explícita, sí lo es. Las tres condiciones son necesarias juntas; ninguna alcanza por sí sola.

Por qué la condición del comportamiento real importa tanto

Vale la pena detenerse en la trampa de la encuesta, porque es sutil y aparece todo el tiempo en equipos que sí tienen buenas intenciones. Eric Ries la resume con una frase que vale la pena memorizar: la gente es mala prediciendo su propio comportamiento futuro, especialmente cuando la pregunta es hipotética y sin costo real de responder. Un comprador puede decir honestamente "sí, preferiría un checkout más simple" y, puesto frente a él de verdad, comportarse exactamente igual que siempre —o al revés—. La única forma de saberlo es observar lo que la gente hace, no lo que dice que haría. Por eso measuresRealBehavior es una condición separada de statesAssumption: puedes tener una hipótesis excelente y aun así diseñar un experimento que solo mide opiniones sobre ella.

Errores comunes

El "MVP" que en realidad es la v1 con features recortadas y sin hipótesis. Qué pasa: como viste con el primer candidato, alguien toma el plan completo, le quita un par de detalles no esenciales (el modo oscuro, las animaciones), y lo presenta como "el MVP" —cuando en realidad es casi el mismo esfuerzo, sin ninguna suposición declarada—. Por qué pasa: recortar features visibles se siente como "hacer menos", aunque el costo real y la falta de una pregunta que responder no hayan cambiado. Cómo detectarlo: pregunta "¿qué suposición específica prueba este plan que el plan completo no probaría igual?" —si la respuesta es "ninguna, es literalmente lo mismo pero más simple", no es un MVP—. Cómo corregirlo: exige las tres condiciones de isRealMVP antes de aceptar el nombre. Si el effortShare es mayor al 50% o no hay una suposición explícita, llámalo por lo que es: una v1 recortada, no un MVP.

Confundir preguntar con probar. Qué pasa: el equipo diseña una encuesta, un grupo focal, o una entrevista, y la trata como si fuera el experimento que valida la apuesta —como en el segundo candidato—. Por qué pasa: hablar con usuarios se siente riguroso y centrado en el usuario, y de hecho lo es —pero responde una pregunta distinta ("¿qué opinan?") a la que necesitas responder ("¿qué harían?")—. Cómo detectarlo: el plan del "MVP" no incluye a nadie usando, comprando o interactuando con nada real; solo incluye a alguien respondiendo preguntas. Cómo corregirlo: las opiniones son un insumo valioso —de hecho, entender por qué la gente hace lo que hace es exactamente el trabajo de product-discovery-and-prototyping-guide—, pero no reemplazan un MVP. Un MVP siempre incluye una acción real, aunque sea diminuta: un clic, una compra, un registro.

Pensar que cualquier cosa barata cuenta, sin verificar que prueba la MISMA suposición que te importa. Qué pasa: el equipo construye algo muy pequeño y rápido, lo celebra por su bajo costo, pero al mirarlo con cuidado resulta que prueba una pregunta distinta a la que originalmente les preocupaba —el plato de arroz blanco de la analogía, no la cucharada de la receta nueva—. Cómo detectarlo: pregunta "si esto sale bien, ¿qué exactamente puedo concluir sobre la suposición original?" —si la respuesta requiere un salto lógico grande ("bueno, si les gustó A, probablemente les guste B también"), no es la misma suposición—. Cómo corregirlo: antes de aprobar cualquier plan como MVP, escribe la suposición riesgosa en una frase, y verifica que el experimento propuesto, si sale mal, la refuta directamente —no algo parecido, la suposición misma—.

Ejercicios

Ejercicio 1 — Clasifica un cuarto candidato. El equipo de Mercado propone, para la apuesta de recommendations (fullEffort: 40): un botón "Ver recomendados para ti" en el carrito, sin backend real detrás —no hay motor de recomendaciones, ni siquiera una tabla fija—, que solo cuenta cuántos compradores hacen clic, para medir si existe interés antes de construir nada (effort: 1, statesAssumption: true, measuresRealBehavior: true). Antes de correr el código, decide si isRealMVP lo clasificaría como MVP real. Después, verifica.

{
  name: 'Boton "Ver recomendados para ti" en el carrito, sin backend: solo cuenta clics para medir interes',
  effortShare: 3,
  isRealMVP: true,
  verdict: 'es un MVP real'
}

Ejercicio 2 — Defiende con la analogía. Un compañero insiste en que la encuesta del ejemplo trabajado ("¿simplificarían el checkout a 3 pasos?") sí es un MVP válido, porque "es lo más barato de los tres y además le preguntamos directo a los usuarios, ¿qué más rigor quieres?". Usando la analogía de la cucharada, explica en 3-4 frases por qué el bajo costo y hablar con usuarios no bastan.

Ejercicio 3 — Diseña tu propio candidato. Para la apuesta de Search filters by price range (mejorar la búsqueda con filtros de precio, del backlog del módulo 1), propón un candidato a MVP que cumpla las tres condiciones de isRealMVP. Describe: qué suposición declara, cómo mide comportamiento real (no opinión), y por qué es barato comparado con construir el sistema de filtros completo.

Resumen y siguiente paso

En esta lección aprendiste la definición precisa de un MVP: no es "la v1 con menos features", es un plan que cumple tres condiciones a la vez — declara una suposición explícita, mide comportamiento real (no opinión), y cuesta una fracción pequeña de construir la apuesta completa. Viste, con isRealMVP corriendo sobre tres candidatos del checkout de Mercado, cómo un plan puede fallar por cualquiera de las tres razones —sin hipótesis, midiendo opinión en vez de comportamiento, o simplemente costando casi lo mismo que construir todo— y cómo solo el que cumple las tres es un MVP real.

Antes de avanzar deberías poder: nombrar las tres condiciones de un MVP real; explicar, con la analogía de la cucharada, por qué una encuesta no es un MVP; y clasificar un plan propuesto usando la lógica de isRealMVP.

La lección 3 toma una pieza específica de esta definición y la profundiza: cuando recortas un plan para hacerlo más barato, hay dos cosas distintas que puedes estar recortando —el scope (cuánto construyes) y el aprendizaje (qué puedes concluir)—, y solo la primera es segura de recortar sin costo.

Recursos

• Eric Ries, The Lean Startup — theleanstartup.com. El origen de las tres condiciones de esta lección: un MVP existe para maximizar el aprendizaje validado por unidad de esfuerzo, no para minimizar features. En inglés.
• Henrik Kniberg, "Making Sense of MVP" — blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp. El dibujo del monopatín-a-auto es, precisamente, el argumento visual contra "la v1 con menos features" (que sería una rueda, o un cuarto de auto). En inglés.
• Marty Cagan (Silicon Valley Product Group), "MVP" — svpg.com/articles. Sobre el MVP como la forma más rápida de probar una hipótesis de valor o de viabilidad, con el mínimo de esfuerzo de ingeniería. En inglés.