Mini-proyecto: audita el trimestre de Mercado y reescribe sus apuestas

Descripción

Es momento de juntar las seis lecciones del módulo en un solo ejercicio completo. Ya sabes distinguir un output de un outcome (lecciones 2 y 3), le pusiste número al build trap (lección 4), aceptaste que la pregunta es tuya como ingeniero (lección 5), aprendiste a reconocer un buen outcome (lección 6), y aprendiste a exigir un mecanismo antes de construir (lección 7). En este mini-proyecto vas a aplicar todo eso, en orden, sobre el caso completo que acompañó el módulo entero: el trimestre de Mercado.

El proyecto tiene tres partes, y las tres se comprueban ejecutando código, no describiendo con palabras. Primero, auditas el trimestre tal como se envió —reutilizando el modelo auditQuarter de la lección 4— y confirmas el veredicto del build trap con el detalle completo. Segundo, eliges tres de los diez ítems que fueron output puro y los reescribes como apuestas con una cadena causal completa —feature, mecanismo, cambio de comportamiento, métrica—, usando el checker hasCausalChain de la lección 7. Tercero, proyectas qué pasaría con la auditoría del trimestre si esas tres apuestas reescritas efectivamente cumplen su métrica, para ver cuánto mejora el panorama —y cuánto trabajo queda todavía por hacer, sin exagerar el resultado—.

Conexión con el módulo. Este proyecto no introduce ningún concepto nuevo: es la síntesis de las seis lecciones anteriores, aplicadas de punta a punta sobre el mismo caso. Y prepara el terreno para lo que sigue: reescribir una apuesta con una cadena causal completa es exactamente el primer paso de lo que el módulo 2 va a formalizar a fondo (la cadena de valor completa, de la tarea técnica al valor de negocio), y ordenar cuáles de estas apuestas reescritas entran primero al roadmap es, más adelante, el trabajo de los módulos 3 (priorización) y 7 (el roadmap final). Lo que armas hoy es la base sobre la que se para el resto de la guía.

Una analogía: el entrenador y la bitácora del trimestre

En la lección 4 comparaste el build trap con correr en una caminadora: mucho esfuerzo, cero distancia. Ahora imagina que ese corredor contrata a un entrenador para revisar los últimos tres meses. El entrenador no empieza felicitando el esfuerzo ni regañando por la falta de resultados — empieza por abrir la bitácora completa: cada sesión de entrenamiento, cuánto tiempo duró, qué ejercicio fue. Después la cruza contra los datos reales del cuerpo: peso, resistencia, fuerza, medidas. Algunas sesiones —las que trabajaron el ejercicio correcto, con la intensidad correcta, con un plan claro de qué músculo debían fortalecer— sí se reflejan en el cambio real. Otras, aunque agotadoras, no dejaron ninguna huella medible: se hicieron, sudaron, pero no formaban parte de un plan con una razón clara.

El entrenador no tira la bitácora entera ni le dice al corredor que deje de entrenar. Hace exactamente lo que vas a hacer en este proyecto: identifica cuáles sesiones sí funcionaron y por qué, elige un puñado de las que no funcionaron, y las rediseña — mismo tiempo, mismo esfuerzo disponible, pero ahora con un objetivo muscular específico y una razón clara de por qué ese ejercicio debería lograrlo—. Y antes de prometer nada, hace una proyección honesta: "si estos tres ejercicios rediseñados funcionan como esperamos, el próximo trimestre se ve así de mejor" — sin fingir que el problema entero desaparece de un día para otro. Esa es, con toda precisión, la estructura de este proyecto.

La solución de referencia, verificada

Vamos a construir la auditoría completa y verificarla paso a paso. (Los ejercicios del final te piden extenderla y razonar sobre casos nuevos.)

Parte 1 — El trimestre tal como se envió

Arrancamos donde terminó la lección 4: los 12 envíos de Mercado, cada uno con su bandera metricMoved, y el modelo auditQuarter que ya construiste.

function auditQuarter(shipments) {
  const total = shipments.length;
  const withOutcome = shipments.filter((s) => s.metricMoved);
  const pureOutput = shipments.filter((s) => s.isOutput && !s.metricMoved);
  return {
    total,
    outcomeCount: withOutcome.length,
    pureOutputCount: pureOutput.length,
    pureOutputNames: pureOutput.map((s) => s.name),
  };
}

function trapShare(r) {
  return Math.round((r.pureOutputCount / r.total) * 100);
}

const mercadoQ3 = [
  { name: 'Checkout page redesign (visual refresh)', isOutput: true, metricMoved: null },
  { name: 'Product recommendations carousel', isOutput: true, metricMoved: null },
  { name: 'Seller analytics dashboard', isOutput: true, metricMoved: null },
  { name: 'Product reviews and ratings', isOutput: true, metricMoved: null },
  { name: 'Search filters by price range', isOutput: true, metricMoved: null },
  { name: 'One-click reorder button', isOutput: true, metricMoved: null },
  { name: 'Wishlist and favorites', isOutput: true, metricMoved: null },
  { name: 'Dark mode', isOutput: true, metricMoved: null },
  { name: 'Social share buttons', isOutput: true, metricMoved: null },
  { name: 'Saved payment methods', isOutput: true, metricMoved: 'GMV' },
  { name: 'Real-time inventory sync for sellers', isOutput: true, metricMoved: null },
  { name: 'Simplified 3-step checkout', isOutput: true, metricMoved: 'GMV' },
];

const before = auditQuarter(mercadoQ3);
console.log('=== Auditoria: trimestre tal como se envio ===');
console.log(before.total + ' envios, ' + before.outcomeCount + ' movieron una metrica, ' +
  before.pureOutputCount + ' fueron output puro (' + trapShare(before) + '% output puro)');

Esta parte no trae ninguna sorpresa —es, literal, el resultado de la lección 4—, pero es el punto de partida obligatorio de cualquier auditoría real: antes de proponer una sola mejora, hay que tener el diagnóstico completo y verificado, no una impresión general de "no nos fue tan bien".

Parte 2 — Tres apuestas, reescritas con su cadena causal

De los diez ítems de output puro, elegimos tres candidatos con mayor potencial —aquellos donde es más fácil imaginar un mecanismo plausible hacia el GMV o la conversión— y les completamos los cuatro eslabones de la lección 7:

function hasCausalChain(bet) {
  const links = ['feature', 'mechanism', 'behaviorChange', 'metric'];
  const missing = links.filter((l) => !bet[l]);
  return { complete: missing.length === 0, missing };
}

const rewrites = [
  {
    original: 'Product recommendations carousel',
    feature: 'Product recommendations carousel',
    mechanism: 'el carrusel muestra productos complementarios dentro del mismo carrito',
    behaviorChange: 'mas usuarios agregan un segundo producto antes de pagar',
    metric: 'GMV',
  },
  {
    original: 'Seller analytics dashboard',
    feature: 'Seller analytics dashboard',
    mechanism: 'los vendedores ven que productos rotan y ajustan precio o stock a tiempo',
    behaviorChange: 'menos productos se quedan sin stock o con sobreprecio',
    metric: 'GMV',
  },
  {
    original: 'Search filters by price range',
    feature: 'Search filters by price range',
    mechanism: 'los usuarios encuentran mas rapido algo dentro de su presupuesto',
    behaviorChange: 'menos abandono en la busqueda, mas usuarios llegan al carrito',
    metric: 'checkout conversion',
  },
];

console.log('\n=== Apuestas reescritas de output a outcome ===');
rewrites.forEach((bet) => {
  const r = hasCausalChain(bet);
  console.log('"' + bet.original + '" -> cadena completa: ' + (r.complete ? 'si' : 'no'));
});

Fíjate en algo importante sobre cómo se eligieron estos tres, y no otros siete: no fue al azar. Product recommendations carousel ataca directamente el ticket promedio (el mecanismo de "agregar un segundo producto" es el mismo que hace efectivas las recomendaciones en cualquier tienda física, la de "¿algo más?" en la caja). Seller analytics dashboard tiene un mecanismo defendible si se conecta con una acción concreta del vendedor (ajustar stock o precio), no solo con "ver datos". Y Search filters by price range ataca un momento de fricción conocido en la búsqueda. Los otros siete ítems de output puro —Dark mode, Wishlist and favorites, Social share buttons, entre otros— quedaron fuera de esta ronda de reescritura precisamente porque, con honestidad, es más difícil imaginarles un mecanismo plausible hacia el GMV; eso no los vuelve inútiles como features, pero sí los deja fuera de esta apuesta específica de "reescribir para el próximo trimestre".

Parte 3 — La proyección: si las tres apuestas cumplen

Ahora, la pregunta final: si estas tres apuestas reescritas se construyen y de verdad cumplen su métrica el próximo trimestre, ¿cómo se ve la auditoría completa?

const mercadoQ4 = mercadoQ3.map((s) => {
  const rewrite = rewrites.find((r) => r.original === s.name);
  return rewrite ? { ...s, metricMoved: rewrite.metric } : s;
});

const after = auditQuarter(mercadoQ4);
console.log('\n=== Auditoria: proyeccion si las 3 apuestas cumplen ===');
console.log(after.total + ' envios, ' + after.outcomeCount + ' movieron una metrica, ' +
  after.pureOutputCount + ' fueron output puro (' + trapShare(after) + '% output puro)');
console.log('\nOutput puro que queda: ' + after.pureOutputNames.join(', '));

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

=== Auditoria: trimestre tal como se envio ===
12 envios, 2 movieron una metrica, 10 fueron output puro (83% output puro)

=== Apuestas reescritas de output a outcome ===
"Product recommendations carousel" -> cadena completa: si
"Seller analytics dashboard" -> cadena completa: si
"Search filters by price range" -> cadena completa: si

=== Auditoria: proyeccion si las 3 apuestas cumplen ===
12 envios, 5 movieron una metrica, 7 fueron output puro (58% output puro)

Output puro que queda: Checkout page redesign (visual refresh), Product reviews and ratings, One-click reorder button, Wishlist and favorites, Dark mode, Social share buttons, Real-time inventory sync for sellers

Lee las tres auditorías en conjunto, porque juntas cuentan la historia completa del proyecto. El trimestre tal como se envió confirma, otra vez, el 83% de build trap de la lección 4 — el punto de partida honesto. Las tres apuestas reescritas pasan las cuatro pruebas de hasCausalChain: no son solo ideas mejor redactadas, son apuestas que se pueden auditar después, con un mecanismo verificable. Y la proyección muestra el efecto concreto de ese trabajo: si las tres cumplen, el output puro baja de 83% a 58% — una mejora real y medible, lograda sin agregar ni un ítem nuevo al backlog, solo pensando mejor los que ya estaban ahí.

Y fíjate en lo que la proyección no dice, porque es tan importante como lo que sí dice: 58% sigue siendo, con el mismo umbral de la lección 4, un build trap — la mayoría del trimestre seguiría siendo output puro, incluso en el escenario optimista donde las tres reescrituras funcionan exactamente como se espera. Quedan siete ítems (Checkout page redesign, Product reviews and ratings, One-click reorder button, Wishlist and favorites, Dark mode, Social share buttons, Real-time inventory sync for sellers) sin una cadena causal declarada. Esta proyección no es una promesa de que el problema se resuelve solo con este ejercicio — es la prueba honesta de que es posible mejorar el número con el mismo esfuerzo, pensando el mecanismo antes de construir, y de que todavía queda trabajo real por delante. Ese trabajo —decidir cuáles de los siete restantes vale la pena reescribir, en qué orden, y qué tan grandes hacerlos— es, exactamente, lo que entra en los módulos 3 al 7 de esta guía.

Errores comunes

Reescribir la apuesta para que "suene bien", sin un mecanismo real detrás. Qué pasa: al hacer el ejercicio de reescritura, se completa el campo mechanism con una frase genérica ("va a mejorar la experiencia") solo para que hasCausalChain marque complete: true, sin que exista una razón causal de verdad. Por qué pasa: el checker solo verifica que el campo exista, no que el contenido sea razonable — es una limitación real del modelo, a propósito simple. Cómo detectarlo: si le preguntas a quien escribió el mecanismo "¿por qué esto específicamente, y no cualquier otra frase?", no tiene una respuesta concreta basada en cómo se comportan los usuarios. Cómo corregirlo: el checker es una ayuda, no un reemplazo del criterio. Antes de dar por completa una cadena causal, pregúntate si el mecanismo escrito de verdad explica el por qué, con la misma seriedad que le pondrías a explicárselo a un compañero escéptico.

Reescribir los diez ítems de output puro de una sola vez, sin priorizar. Qué pasa: motivado por el ejercicio, alguien intenta encontrarle un mecanismo plausible a los diez ítems, incluyendo los que genuinamente no tienen una conexión clara con el GMV (como Dark mode), forzando mecanismos poco creíbles con tal de completar el checklist. Por qué pasa: se siente incompleto dejar ítems sin reescribir. Cómo detectarlo: el mecanismo de alguno de los diez suena forzado o especulativo comparado con los de Saved payment methods o los tres elegidos en este proyecto. Cómo corregirlo: no todos los outputs merecen convertirse en apuestas de outcome — algunos, honestamente, no tienen una conexión creíble con la métrica que importa, y está bien dejarlos así, o replantearlos por completo. Priorizar cuáles apuestas vale la pena reescribir con criterio explícito es, precisamente, el trabajo del módulo 3.

Confundir la proyección optimista con un resultado garantizado. Qué pasa: se presenta la proyección de "58% output puro" como si fuera un hecho asegurado del próximo trimestre, en vez de un escenario condicional a que las tres apuestas efectivamente funcionen. Por qué pasa: una proyección con números concretos se siente más sólida de lo que es, sobre todo cuando el número mejora respecto al diagnóstico anterior. Cómo detectarlo: la proyección se cita en una reunión sin la palabra "si" — "el próximo trimestre bajamos a 58% de build trap" en vez de "si las tres apuestas cumplen, bajaríamos a 58%". Cómo corregirlo: una cadena causal completa hace que una apuesta sea auditable, no que sea garantizada. Las tres reescrituras siguen siendo hipótesis hasta que se construyen, se lanzan, y se mide de verdad si el metricMoved se cumplió — exactamente el mismo proceso de la lección 3, repetido, con suerte, con mejor resultado.

Ejercicios

Ejercicio 1 — Reescribe un cuarto ítem. De los siete que quedaron como output puro en la proyección, elige uno (Checkout page redesign, Product reviews and ratings, One-click reorder button, Wishlist and favorites, Dark mode, Social share buttons, o Real-time inventory sync for sellers) y escribe su cadena causal completa, en el mismo formato que las tres del ejemplo. Si eliges uno donde honestamente no encuentras un mecanismo creíble, di explícitamente cuál es y por qué —esa conclusión también es un resultado válido del ejercicio—.

const oneClickReorder = {
  feature: 'One-click reorder button',
  mechanism: 'elimina el esfuerzo de rebuscar y agregar de nuevo un producto ya comprado',
  behaviorChange: 'mas usuarios recurrentes vuelven a comprar el mismo producto, mas seguido',
  metric: 'GMV',
};

Ejercicio 2 — Calcula un tercer escenario. En vez de que las tres apuestas reescritas cumplan, imagina que solo una de las tres (Search filters by price range) cumple su métrica, y las otras dos no. Sin correr el código primero, calcula el nuevo outcomeCount, pureOutputCount y el porcentaje de output puro. Después, verifica corriéndolo.

Ejercicio 3 — El argumento de cierre. Imagina que tienes que defender, en una reunión con el equipo de Mercado, por qué vale la pena invertir tiempo en escribir mecanismos antes de construir, en vez de simplemente construir más rápido (la objeción típica: "esto nos hace más lentos"). Usa los números concretos de este proyecto para armar el argumento en 3-4 frases.

Resumen y siguiente paso

En este mini-proyecto auditaste el trimestre completo de Mercado, juntando las seis lecciones del módulo en un solo flujo de trabajo verificado: confirmaste el 83% de build trap tal como se envió (lección 4), reescribiste tres de los diez ítems de output puro con una cadena causal completa —feature, mecanismo, cambio de comportamiento, métrica— usando el checker de la lección 7, y proyectaste el efecto honesto de ese trabajo: de 83% a 58% de output puro, una mejora real lograda sin construir nada nuevo, solo pensando mejor lo que ya estaba en el backlog. Y viste, con la misma honestidad que exige todo el módulo, que 58% sigue siendo insuficiente — quedan siete ítems sin mecanismo, y una cadena causal completa es una apuesta auditable, no una garantía.

Con esto cierras el módulo 1. Tienes ahora el vocabulario y el reflejo central de toda esta guía: la diferencia entre lo que se envía y lo que se logra, cómo reconocer un buen outcome, y cómo exigir un mecanismo antes de construir. Ese reflejo —hacerte la pregunta "¿y esto qué debería mover, y por qué?"— es la vara con la que vas a medir todo lo que sigue.

Hacia dónde sigues. El módulo 2 toma exactamente el trabajo que empezaste en la Parte 2 de este proyecto —declarar un mecanismo— y lo formaliza a fondo: la cadena de valor del producto, el camino completo desde una tarea técnica hasta el valor para el usuario y, después, el valor para el negocio. Vas a aprender a trazar ese camino con el mismo rigor con el que un electricista sigue un cable, para que ninguna apuesta futura de Mercado vuelva a saltar del interruptor a la esperanza. Y más adelante: priorizar ese backlog reescrito con criterio explícito (módulo 3), dimensionar cada apuesta antes de construirla (módulo 4), recortarla al experimento más pequeño que la prueba (módulo 5), tratarla como una apuesta bajo incertidumbre (módulo 6), y ordenarla en un roadmap que puedas defender (módulo 7) — hasta el capstone del módulo 8, donde vuelves a este mismo backlog de Mercado por última vez, con todas las herramientas juntas.

Recursos

• Melissa Perri, "The Build Trap" — melissaperri.com/blog/2014/08/05/the-build-trap. Revísalo de nuevo como cierre del módulo: la fuente original del diagnóstico que este proyecto acaba de aplicar en código. En inglés.
• Josh Seiden, "Outcomes Over Output" — outcomesoveroutput.com. La definición que sostiene todo el proyecto: un outcome es un cambio de comportamiento humano que impulsa un resultado de negocio. En inglés.
• John Cutler, "12 Signs You're Working in a Feature Factory" — medium.com/@johnpcutler/12-signs-youre-working-in-a-feature-factory. Una buena lista para autoevaluar, con tu propio equipo, si el patrón que auditaste en Mercado también aplica donde trabajas. En inglés.
• Marty Cagan (Silicon Valley Product Group), "Outcomes Are Hard" — svpg.com/outcomes-are-hard. Como puente hacia el módulo 2: sobre las competencias nuevas que exige, de todo el equipo, entregar outcomes en vez de output de forma sostenida. En inglés.