Módulo 5: Mvp And Scoping

Mini-proyecto: diseña el MVP que prueba tres apuestas de Mercado, no el que las construye enteras

Siguiente →

Descripción

Es momento de juntar las seis lecciones del módulo en un solo ejercicio completo, aplicado a tres apuestas reales del backlog de Mercado: Product recommendations carousel, Product reviews and ratings, y Seller analytics dashboard —las mismas tres que reescribiste con su cadena causal completa en el proyecto del módulo 1—. Ya sabes qué hace que un plan sea un MVP real y no una v1 recortada (lección 2), qué se puede cortar gratis y qué no (lección 3), cómo comparar el costo y el momento de la evidencia de dos planes (lección 4), por qué la forma del experimento importa tanto como su costo (lección 5), cómo recortar un backlog de features a su núcleo mínimo (lección 6), y las cinco formas típicas en que un plan falla el nombre de "MVP" (lección 7). En este mini-proyecto vas a aplicar todo eso, en orden, sobre las tres apuestas juntas.

El proyecto tiene tres partes, y las tres se comprueban ejecutando código, no describiendo con palabras. Primero, comparas las tres apuestas —construir cada una entera contra su MVP correspondiente— reutilizando compareApproaches, y agregas los resultados en una sola tabla de esfuerzo total. Segundo, recortas el backlog completo de features candidatas de una de las tres apuestas (Product reviews and ratings) a su subconjunto mínimo, reutilizando selectMinimalScope. Tercero, comparas el esfuerzo total y el momento de la evidencia de dos caminos posibles para el trimestre: construir las tres apuestas enteras, o construir los tres MVP primero.

Conexión con el módulo. Este proyecto no introduce ningún concepto nuevo: es la síntesis de las seis lecciones anteriores, aplicada de punta a punta sobre tres apuestas completas a la vez, en vez de una sola. Y prepara el terreno para lo que sigue: identificar, dentro de cada una de estas apuestas, cuál es exactamente la suposición más riesgosa —y no solo una suposición razonable— es, precisamente, el trabajo que el módulo 6 va a formalizar a fondo. Y ordenar en qué secuencia construir estos tres MVP, una vez que tengas evidencia de los tres, es el trabajo de los módulos 3 (ya hecho, con RICE) y 7 (el roadmap final, con costo de demora).

Una analogía: el chef que prueba tres recetas nuevas antes del banquete

Vuelve al chef de la presentación del módulo, que prueba una cucharada de una receta nueva antes de cocinar para 50. Ahora imagina que el chef tiene, para el mismo banquete, tres recetas nuevas candidatas al menú —no solo una—, y un presupuesto de ingredientes limitado para las pruebas de esta semana. No prueba las tres cocinando la olla entera de cada una —eso agotaría el presupuesto de pruebas sin dejarle nada para las otras dos—. Prueba una cucharada de cada una, con exactamente las mismas proporciones que usaría en la versión completa, y compara: ¿cuáles cucharadas confirman que la receta vale la pena escalar, y cuáles no? Con esa evidencia —barata, rápida, de las tres a la vez— decide en qué recetas vale la pena invertir el presupuesto completo de ingredientes para el sábado.

Eso es exactamente lo que este proyecto hace con tres apuestas del backlog de Mercado a la vez: en vez de comprometer un trimestre entero construyendo las tres enteras, se prueban las tres cucharadas —los tres MVP— primero, y con esa evidencia se decide después cuáles escalar.

La solución de referencia, verificada

Vamos a construir las tres partes del proyecto y verificarlas paso a paso. (Los ejercicios del final te piden extenderlas y razonar sobre casos nuevos.)

Parte 1 — Las tres apuestas, comparadas con compareApproaches

Arrancamos con las funciones que ya construiste en las lecciones 1 y 4, y con las tres apuestas del backlog —cada una con su suposición riesgosa, su plan completo, y su MVP—:

function compareApproaches(bet) {
  const { name, riskiestAssumption, buildEverything, mvp } = bet;
  const effortRatio = Math.round((mvp.effort / buildEverything.effort) * 100);
  const sameEvidence = buildEverything.provesAssumption === mvp.provesAssumption;
  return {
    bet: name,
    riskiestAssumption,
    buildEverything: { effort: buildEverything.effort, evidenceAt: buildEverything.evidenceAt },
    mvp: { effort: mvp.effort, evidenceAt: mvp.evidenceAt },
    effortRatio,
    sameEvidence,
  };
}

function summarizeBets(bets) {
  const results = bets.map(compareApproaches);
  const totalBuildEverythingEffort = results.reduce((sum, r) => sum + r.buildEverything.effort, 0);
  const totalMvpEffort = results.reduce((sum, r) => sum + r.mvp.effort, 0);
  const totalSaved = totalBuildEverythingEffort - totalMvpEffort;
  const totalSavedPercent = Math.round((totalSaved / totalBuildEverythingEffort) * 100);
  return { results, totalBuildEverythingEffort, totalMvpEffort, totalSaved, totalSavedPercent };
}

// Las tres apuestas del backlog de Mercado que este proyecto recorta.
const recommendationsBet = {
  name: 'Product recommendations carousel',
  riskiestAssumption: 'mostrar productos complementarios en el carrito hace que mas compradores agreguen un segundo producto antes de pagar',
  buildEverything: { plan: 'motor de recomendaciones con filtrado colaborativo y microservicio propio', effort: 40, evidenceAt: 'dia 40', provesAssumption: true },
  mvp: { plan: 'tabla fija "comprados juntos" para las 20 categorias con mas volumen', effort: 4, evidenceAt: 'dia 4', provesAssumption: true },
};

const reviewsBet = {
  name: 'Product reviews and ratings',
  riskiestAssumption: 'ver una calificacion visible en la pagina del producto aumenta la probabilidad de que un comprador complete la compra',
  buildEverything: { plan: 'sistema completo de reseñas: texto, fotos, moderacion, respuesta del vendedor y voto de utilidad, en todo el catalogo', effort: 20, evidenceAt: 'dia 20', provesAssumption: true },
  mvp: { plan: 'star rating promedio + conteo, sembrado a mano con compradores beta, solo en las 20 categorias con mas trafico', effort: 3, evidenceAt: 'dia 3', provesAssumption: true },
};

const sellerToolsBet = {
  name: 'Seller analytics dashboard',
  riskiestAssumption: 'si los vendedores ven que productos rotan lento o se quedan sin stock, ajustan precio o stock a tiempo, y eso reduce las ventas perdidas',
  buildEverything: { plan: 'dashboard completo con graficos en tiempo real, alertas automaticas y exportacion, para los 3000+ vendedores', effort: 25, evidenceAt: 'dia 25', provesAssumption: true },
  mvp: { plan: 'reporte semanal por email a 15 vendedores piloto con sus 5 productos de peor rotacion, generado a mano con una query', effort: 3, evidenceAt: 'dia 3', provesAssumption: true },
};

console.log('=== Parte 1: compareApproaches sobre las 3 apuestas ===\n');
const summary = summarizeBets([recommendationsBet, reviewsBet, sellerToolsBet]);
summary.results.forEach((r) => {
  console.log(r.bet + ':');
  console.log('  buildEverything: ' + r.buildEverything.effort + ' person-days, evidencia ' + r.buildEverything.evidenceAt);
  console.log('  mvp: ' + r.mvp.effort + ' person-days, evidencia ' + r.mvp.evidenceAt);
  console.log('  effortRatio: ' + r.effortRatio + '%, misma evidencia clave: ' + r.sameEvidence + '\n');
});
console.log('Totales: construir todo = ' + summary.totalBuildEverythingEffort + ' person-days | los 3 MVP = ' +
  summary.totalMvpEffort + ' person-days (' + summary.totalSavedPercent + '% del total) | ahorro: ' + summary.totalSaved + ' person-days');

Esta parte no trae ninguna sorpresa por apuesta individual —cada una repite el patrón que ya viste en las lecciones 1 y 4—, pero summarizeBets agrega algo nuevo: junta las tres en una sola vista de esfuerzo total, exactamente lo que un equipo real necesita para planear el trimestre, no apuesta por apuesta sino como conjunto.

Parte 2 — Recortar el backlog de features de Product reviews and ratings

De las tres apuestas, tomamos una —reseñas— y le aplicamos el algoritmo completo de la lección 6 a su backlog propuesto de seis features:

function selectMinimalScope(features) {
  const selected = features.filter((f) => f.provesTheBet);
  const cut = features.filter((f) => !f.provesTheBet);
  const totalCost = features.reduce((sum, f) => sum + f.cost, 0);
  const selectedCost = selected.reduce((sum, f) => sum + f.cost, 0);
  const savedCost = totalCost - selectedCost;
  const savedPercent = Math.round((savedCost / totalCost) * 100);
  return { selected: selected.map((f) => f.name), cut: cut.map((f) => f.name), totalCost, selectedCost, savedCost, savedPercent };
}

console.log('\n=== Parte 2: selectMinimalScope sobre las features de "Product reviews and ratings" ===\n');
const reviewsFeatures = [
  { name: 'Star rating promedio + conteo en la pagina del producto', cost: 3, provesTheBet: true },
  { name: 'Campo de texto para escribir la reseña', cost: 5, provesTheBet: false },
  { name: 'Moderacion y filtro anti-spam de reseñas', cost: 4, provesTheBet: false },
  { name: 'Respuesta del vendedor a la reseña', cost: 3, provesTheBet: false },
  { name: 'Voto de "te sirvio esta reseña"', cost: 2, provesTheBet: false },
  { name: 'Subir fotos dentro de la reseña', cost: 3, provesTheBet: false },
];
const scope = selectMinimalScope(reviewsFeatures);
console.log('seleccionadas: ' + scope.selected.join(', '));
console.log('cortadas: ' + scope.cut.join(', '));
console.log('costo total: ' + scope.totalCost + ' | costo del MVP: ' + scope.selectedCost + ' | ahorro: ' + scope.savedCost + ' (' + scope.savedPercent + '%)');

Fíjate en algo que conecta las dos partes: el mvp.effort: 3 de reviewsBet en la Parte 1 y el selectedCost: 3 de esta Parte 2 son el mismo número, calculados de dos formas distintas. En la Parte 1, 3 era un dato de entrada que ya venías dando por cierto. En la Parte 2, ese 3 sale de sumar, feature por feature, solo las que prueban la apuesta —es la verificación de que el número que usaste en la Parte 1 no era una cifra inventada, sino la suma exacta del único ítem del backlog que efectivamente prueba la suposición central.

Parte 3 — Esfuerzo total vs. evidencia obtenida

Con las dos partes anteriores calculadas, cerramos con la comparación que un equipo real necesita para decidir el trimestre:

console.log('\n=== Parte 3: esfuerzo total vs evidencia obtenida ===\n');
console.log('Construir las 3 apuestas completas: ' + summary.totalBuildEverythingEffort + ' person-days, primera evidencia entre el dia 20 y el dia 40.');
console.log('Construir los 3 MVP: ' + summary.totalMvpEffort + ' person-days (' + summary.totalSavedPercent + '% del esfuerzo), primera evidencia entre el dia 3 y el dia 4.');

Qué esperar. Al correr el archivo completo (las tres partes juntas) con Node, la salida es exactamente esta:

=== Parte 1: compareApproaches sobre las 3 apuestas ===

Product recommendations carousel:
  buildEverything: 40 person-days, evidencia dia 40
  mvp: 4 person-days, evidencia dia 4
  effortRatio: 10%, misma evidencia clave: true

Product reviews and ratings:
  buildEverything: 20 person-days, evidencia dia 20
  mvp: 3 person-days, evidencia dia 3
  effortRatio: 15%, misma evidencia clave: true

Seller analytics dashboard:
  buildEverything: 25 person-days, evidencia dia 25
  mvp: 3 person-days, evidencia dia 3
  effortRatio: 12%, misma evidencia clave: true

Totales: construir todo = 85 person-days | los 3 MVP = 10 person-days (88% del total) | ahorro: 75 person-days

=== Parte 2: selectMinimalScope sobre las features de "Product reviews and ratings" ===

seleccionadas: Star rating promedio + conteo en la pagina del producto
cortadas: Campo de texto para escribir la reseña, Moderacion y filtro anti-spam de reseñas, Respuesta del vendedor a la reseña, Voto de "te sirvio esta reseña", Subir fotos dentro de la reseña
costo total: 20 | costo del MVP: 3 | ahorro: 17 (85%)

=== Parte 3: esfuerzo total vs evidencia obtenida ===

Construir las 3 apuestas completas: 85 person-days, primera evidencia entre el dia 20 y el dia 40.
Construir los 3 MVP: 10 person-days (88% del esfuerzo), primera evidencia entre el dia 3 y el dia 4.

Lee las tres partes en conjunto, porque juntas cuentan la historia completa del proyecto. La Parte 1 confirma que el patrón del 10-15% de esfuerzo no es exclusivo de una sola apuesta: se repite, con pequeñas variaciones, en las tres —recomendaciones, reseñas y herramientas de vendedor—. La Parte 2 verifica, con el algoritmo completo de recorte, que el número de esfuerzo que usaste en la Parte 1 para el MVP de reseñas no era arbitrario: sale de sumar exactamente la única feature del backlog propuesto que prueba la suposición central, cortando el resto sin perder nada de aprendizaje. Y la Parte 3 traduce todo esto a la decisión real que enfrenta el equipo cada trimestre: 85 person-days y hasta 40 días de espera para construir las tres apuestas enteras, contra 10 person-days y un máximo de 4 días de espera para tener evidencia real sobre las tres.

Y fíjate en lo que este resultado no dice, porque es tan importante como lo que sí dice: 10 person-days de MVP no reemplazan los 85 de construir todo —si las tres suposiciones se confirman, ese trabajo completo sigue siendo necesario después—. Lo que este proyecto demuestra es que el equipo no tiene que elegir a ciegas, con solo el ranking de RICE (módulo 3) y el tamaño dimensionado (módulo 4), cuál de las tres apuestas construir entera primero. Puede, con el 12% del presupuesto total del trimestre, obtener evidencia real de las tres antes de comprometer el resto — y decidir con datos, no con la estimación de confidence que declaró antes de empezar. Ese es exactamente el puente hacia el módulo 6: una vez que tienes esta evidencia, la conversación deja de ser "¿cuál suponemos que funciona mejor?" y pasa a ser "¿cuál demostró que funciona?".

Errores comunes

Aplicar selectMinimalScope a una apuesta sin haber verificado primero, con compareApproaches, que su MVP realmente cuesta una fracción razonable del total. Qué pasa: el equipo recorta el backlog de features de una apuesta hasta el mínimo, pero nunca compara ese mínimo contra el costo de construir la apuesta entera —se queda solo con la lista de features cortadas, sin el número de effortRatio que le da sentido al recorte—. Por qué pasa: las dos partes del proyecto usan datos distintos (un backlog de features contra un plan de dos alternativas) y es fácil tratarlas como ejercicios separados en vez de dos vistas de la misma decisión. Cómo detectarlo: el equipo puede decir "cortamos cinco de seis features" pero no puede decir "eso significa que el MVP cuesta X% de construir todo". Cómo corregirlo: como en la Parte 2 de este proyecto, verifica siempre que el selectedCost de selectMinimalScope coincida con el mvp.effort que usarías en compareApproaches — son la misma cifra, vista desde dos ángulos.

Presentar el ahorro total (88%) como si aplicara igual a las tres apuestas. Qué pasa: alguien cita "el MVP cuesta 88% menos" como si fuera un número único, uniforme, aplicable a cualquier apuesta futura del backlog. Por qué pasa: un solo número agregado es más fácil de repetir que tres números distintos (10%, 15%, 12%). Cómo detectarlo: se usa la cifra del 88% para justificar el costo esperado de un MVP futuro sin haber calculado ese MVP específico. Cómo corregirlo: el 88% es el promedio agregado de estas tres apuestas, con estos datos estimados — cada apuesta nueva necesita su propio compareApproaches, con su propio plan completo y su propio MVP diseñado a propósito. La cifra agregada sirve para comunicar el patrón general al resto de la organización, no para saltarse el trabajo de diseñar el siguiente MVP.

Olvidar que "evidencia obtenida" en la Parte 3 sigue siendo un modelo pedagógico, no un resultado medido. Qué pasa: se presenta "10 person-days, evidencia en 4 días" como si ya fuera un hecho comprobado del próximo trimestre, en vez de la proyección de un plan que todavía no se ejecutó. Por qué pasa: los números concretos de este proyecto, calculados con precisión por el código, se sienten más sólidos que una simple intención. Cómo detectarlo: se cita el resultado en una reunión sin aclarar que son estimaciones de esfuerzo, no mediciones reales todavía. Cómo corregirlo: como se declaró desde el diseño del módulo, effort, evidenceAt y provesTheBet son estimaciones del equipo — el valor de este proyecto es que fuerza a declararlas explícitamente y a comparar con criterio, no que las convierte en verdades medidas. Medir si la evidencia real, una vez construidos los MVP, confirma o refuta cada suposición es trabajo de product-metrics-and-experimentation-guide.

Ejercicios

Ejercicio 1 — Agrega una cuarta apuesta. El equipo de Mercado también quiere evaluar Búsqueda mejorada (del ejercicio de la lección 4: buildEverything.effort: 35, mvp.effort: 5, ambos con provesAssumption: true). Agrégala al arreglo de summarizeBets junto a las otras tres y recalcula los totales.

Ver solución

Con las cuatro apuestas, totalBuildEverythingEffort = 40 + 20 + 25 + 35 = 120, totalMvpEffort = 4 + 3 + 3 + 5 = 15, totalSaved = 105, y totalSavedPercent = round((105 / 120) * 100) = 88 — el mismo porcentaje agregado que con tres apuestas, porque las cuatro comparten un effortRatio individual similar (entre 10% y 15%). Esto confirma, con una cuarta apuesta independiente, que el patrón no depende de cuáles tres apuestas específicas elijas: se sostiene mientras cada MVP se diseñe siguiendo el mismo criterio de las lecciones 2 a 6, no por casualidad de estos números particulares.

Ejercicio 2 — ¿Qué pasa si una apuesta no tiene un MVP barato? Imagina una quinta apuesta hipotética, Cambio de moneda multi-país, donde no existe ninguna forma barata de probar la suposición sin construir buena parte de la infraestructura de conversión de moneda real (buildEverything.effort: 30, mvp.effort: 22, ambos provesAssumption: true). Calcula su effortRatio y explica en 2-3 frases qué significa un effortRatio alto (por ejemplo, por encima del 60%) para la decisión del equipo, distinto a lo que viste en las otras cuatro apuestas.

Ver solución

effortRatio = round((22 / 30) * 100) = 73. Un effortRatio así de alto es una señal legítima y honesta, no un error del modelo: significa que, para esta apuesta específica, no existe un experimento mucho más barato que construir casi toda la infraestructura —algunas apuestas, como cambios profundos de infraestructura (moneda, seguridad, cumplimiento regulatorio), genuinamente no se prestan a un MVP delgado, porque el riesgo central está en la infraestructura misma, no en el comportamiento del usuario—. En ese caso, la decisión del equipo cambia: en vez de "construyamos el MVP barato primero", la pregunta correcta pasa a ser si vale la pena invertir el 73% del esfuerzo completo solo para reducir la incertidumbre, comparado con otras apuestas del backlog que sí tienen un MVP mucho más barato — exactamente el tipo de comparación que retoma el módulo 7 (costo de demora y el roadmap).

Ejercicio 3 — El argumento de cierre. Imagina que tienes que defender, ante el equipo de liderazgo de Mercado, por qué vale la pena invertir dos semanas del trimestre en construir los tres MVP antes de decidir cuál apuesta escalar primero, en vez de ir directo a construir la apuesta mejor puntuada por RICE (módulo 3) a tamaño completo. Usa los números concretos de este proyecto para armar el argumento en 3-4 frases.

Ver solución

Un argumento posible: "RICE nos dice cuál apuesta creemos que vale más, con la información que tenemos hoy —pero 'creemos' sigue siendo una estimación de confidence, no un hecho—. Por 10 de los 85 person-days que costaría construir las tres apuestas enteras —el 12% del presupuesto—, podemos tener evidencia real sobre las tres en menos de una semana, en vez de apostar el trimestre completo a la que puntuó más alto en la reunión. Si la evidencia confirma el ranking de RICE, construimos con mucha más confianza que antes. Y si la evidencia lo contradice —si la apuesta 'segura' resulta floja y una que puntuó más bajo resulta prometedora—, nos ahorramos exactamente el tipo de error costoso que el build trap del módulo 1 describe: construir mucho, con calidad, en la dirección equivocada." El argumento funciona porque no pide más tiempo total —pide invertir una fracción pequeña primero, para gastar el resto del presupuesto con evidencia real en vez de con una corazonada calculada.

Resumen y siguiente paso

En este mini-proyecto diseñaste el MVP de tres apuestas completas del backlog de Mercado, juntando las seis lecciones del módulo en un solo flujo de trabajo verificado: comparaste el esfuerzo y la evidencia de construir cada apuesta entera contra su MVP (lecciones 1 y 4), recortaste el backlog de features de reseñas a su núcleo mínimo con el mismo criterio de la lección 6, y agregaste los resultados en la comparación que un equipo real necesita para planear un trimestre: 85 person-days y hasta 40 días de espera para construir todo, contra 10 person-days y un máximo de 4 días de espera para tener evidencia real de las tres. Y viste, con la misma honestidad que exige todo el módulo, que ese ahorro no reemplaza el trabajo completo si las suposiciones se confirman —lo pospone hasta tener evidencia real que lo justifique—.

Con esto cierras el módulo 5. Tienes ahora el instrumento central de toda esta guía para la pregunta "¿qué construyo primero, y qué tan grande?": nunca construir la apuesta entera de una sola vez, sino diseñar, para cada una, el experimento más barato que prueba —de verdad, con las mismas condiciones de un MVP real— si vale la pena construirla completa.

Hacia dónde sigues. El módulo 6 toma exactamente las suposiciones riesgosas que nombraste en las tres apuestas de este proyecto y las trata como lo que son: apuestas bajo incertidumbre. Vas a aprender a separar hechos de supuestos, a identificar cuál suposición, si es falsa, hunde toda la apuesta, y a conectar el confidence de RICE (módulo 3) con evidencia real en vez de con una corazonada. Y más adelante: decir que no con argumentos y ordenar el roadmap por costo de demora (módulo 7), hasta el capstone del módulo 8, donde vuelves al backlog completo de Mercado por última vez, con todas las herramientas de la guía juntas.

Recursos

  • Eric Ries, The Lean Startup — theleanstartup.com. Revísalo de nuevo como cierre del módulo: el "motor de arranque validado" (validated learning loop) es, en esencia, este proyecto repetido trimestre tras trimestre. 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, releído ahora con tres apuestas en mente en vez de una: cada apuesta de Mercado tiene su propio camino de monopatín a auto. En inglés.
  • Marty Cagan (Silicon Valley Product Group), blog de Silicon Valley Product Group — svpg.com/articles. Sobre por qué los mejores equipos de producto prueban varias apuestas baratas en paralelo antes de comprometerse a escalar una sola. En inglés.
  • Basecamp, "Shape Up" — basecamp.com/shapeup. Como puente hacia el módulo 7: sobre cómo decidir, con el scope ya recortado, en qué orden entran las apuestas a un ciclo de trabajo real. En inglés.
← AnteriorAnti-patrones de MVP: cinco formas de decirle "MVP" a algo que no lo esSiguiente →Presentación del módulo: toda apuesta descansa en una suposición que la puede hundir