Presentación del módulo: el capstone — la estrategia de producto de Mercado

Por qué este módulo existe aquí

Llegaste al final de siete módulos que, cada uno, construyó una pieza. El módulo 2 te dio la visión de Mercado — a dónde va, y qué descarta explícitamente. El módulo 3 eligió el segmento — compradores que exploran, no los que buscan un SKU exacto — y el posicionamiento frente a las alternativas, verificado con positionFit. El módulo 4 encontró la diferenciación real, separada de la paridad, con differentiationMap. El módulo 5 mapeó el panorama competitivo completo — directos, indirectos, y el sustituto más grande de todos — y lo proyectó tres años hacia adelante. El módulo 6 auditó qué de todo eso es, de verdad, un moat, con moatScore, y encontró el hallazgo más incómodo de la guía: la diferenciación que el módulo 4 celebró todavía no está protegida. El módulo 7 construyó el filtro estratégico, strategicFilter, que decide qué apuestas del backlog pertenecen al juego antes de que a nadie le importe su riceScore.

Siete piezas, siete módulos, cada uno correcto por sí solo. Y sin embargo, hasta este punto, nunca las viste funcionar juntas, en una sola corrida, sobre el mismo caso. Este módulo cierra esa brecha: vas a construir el one-pager de estrategia de Mercado — un solo documento, verificado con código de principio a fin — y vas a correr, por primera vez, el pipeline completo: positionFit → differentiationMap → moatScore → strategicFilter, encadenados, cada uno alimentando al siguiente, sobre los mismos datasets reales que usaste en los módulos 3, 4, 6 y 7. No hay conceptos nuevos en este módulo — hay, por primera vez, una sola ejecución que los atraviesa todos.

Conexión con el módulo 7. El módulo 7 te dejó con un roadmap correcto: reviews > sellerTools > recommendations, filtrado sobre una estrategia que declaraste a mano (winOn: ['curatedDiscovery', 'sellerTrust'], avoid: ['price']). Este módulo no repite ese resultado — lo deriva. En vez de escribir winOn y avoid como una afirmación de fe, el pipeline de este módulo los calcula a partir de lo que differentiationMap y la visión ya demostraron, y luego cruza el resultado del filtro contra la auditoría de moats del módulo 6. El número final es el mismo. La diferencia es que, esta vez, puedes trazar cada pieza de esa estrategia hasta el modelo exacto que la produjo — y vas a descubrir algo que ningún módulo anterior, por sí solo, podía mostrarte.

Una analogía cotidiana: el informe final del arquitecto, no siete memos sueltos

Un arquitecto que diseña un edificio no le entrega al cliente siete memos por separado — uno sobre el terreno, otro sobre los materiales, otro sobre la estructura, otro sobre el presupuesto. Durante el proyecto, sí, cada especialista trabajó su pieza por separado: el ingeniero de suelos midió la resistencia del terreno, el estructural calculó las cargas, el de costos corrió el presupuesto. Pero el día de la entrega, el arquitecto presenta un solo documento: los planos finales, donde cada decisión de diseño está trazada hasta el informe técnico que la justifica — esta columna es así de gruesa porque el ingeniero de suelos encontró tal resistencia, este material se eligió porque el presupuesto lo permitía sin sacrificar la estructura. Un plano final que solo mostrara el resultado, sin la cadena de porqués, no serviría para defender ninguna decisión ante un cliente escéptico ni ante un inspector que pregunta "¿y esto por qué es así?".

Este módulo es exactamente ese informe final. No vas a auditar el terreno otra vez (eso ya lo hizo el módulo 2, la visión), ni a recalcular la estructura desde cero (eso ya lo hizo el módulo 6, los moats) — vas a ensamblar el documento que conecta cada pieza con la siguiente, para que cualquier persona que lo lea pueda preguntar "¿por qué el roadmap final es este?" y encontrar la respuesta completa, capa por capa, sin ningún salto de fe.

Ejemplo trabajado: la misma apuesta, dos preguntas distintas

Antes de construir el one-pager completo (lecciones 2 en adelante), vale la pena ver, en un solo experimento pequeño, por qué este módulo importa y no es solo "juntar lo que ya hiciste". Toma recommendations — la apuesta que sirve curatedDiscovery en el backlog de Mercado — y hazle dos preguntas, cada una con el modelo que le corresponde:

// Teaser: dos preguntas distintas sobre la MISMA apuesta, respondidas por
// dos modelos distintos de esta guía -- strategicFilter (M7) y moatScore (M6).
function moatScore(advantage) {
  const { name, type } = advantage;
  let durability;
  switch (type) {
    case 'feature': {
      const { timeToCopyWeekends } = advantage;
      durability = Math.max(0, Math.min(3, timeToCopyWeekends));
      break;
    }
    default:
      durability = 0;
  }
  const verdict = durability >= 7 ? 'moat' : durability >= 4 ? 'weak-moat' : 'not-a-moat';
  return { name, durability, verdict };
}

function riceScore({ reach, impact, confidence, effort }) {
  return (reach * impact * confidence) / effort;
}
function strategicFilter(backlog, strategy) {
  return backlog.map((bet) => {
    const reinforces = bet.servesDimensions.filter((d) => strategy.winOn.includes(d));
    const conflicts = bet.servesDimensions.filter((d) => strategy.avoid.includes(d));
    return { feature: bet.feature, inStrategy: reinforces.length > 0 && conflicts.length === 0, riceScore: Number(riceScore(bet.rice).toFixed(2)) };
  });
}

const mercadoStrategy = { winOn: ['curatedDiscovery', 'sellerTrust'], avoid: ['price'] };
const bet = { feature: 'recommendations', servesDimensions: ['curatedDiscovery'], rice: { reach: 5000, impact: 1, confidence: 0.5, effort: 3 } };

const filterResult = strategicFilter([bet], mercadoStrategy)[0];
const moatResult = moatScore({ name: 'curatedDiscovery', type: 'feature', timeToCopyWeekends: 3 });

console.log('=== La misma apuesta, dos preguntas distintas ===\n');
console.log(`strategicFilter('${filterResult.feature}') -> inStrategy: ${filterResult.inStrategy}  (¿pertenece al juego?)`);
console.log(`moatScore('curatedDiscovery')     -> verdict: ${moatResult.verdict}  (¿es defendible?)`);

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

=== La misma apuesta, dos preguntas distintas ===

strategicFilter('recommendations') -> inStrategy: true  (¿pertenece al juego?)
moatScore('curatedDiscovery')     -> verdict: not-a-moat  (¿es defendible?)

Ahí está, en dos líneas, la razón de ser de este módulo. recommendations sí pertenece a la estrategia de Mercado — refuerza curatedDiscovery, la dimensión exacta donde el módulo 4 confirmó diferenciación real. Y al mismo tiempo, lo que esa apuesta profundiza —curatedDiscovery, evaluado como el algoritmo puro— no es todavía un moat: cualquier competidor con un buen equipo podría copiarlo en unas semanas. Ninguno de los dos módulos anteriores, por sí solo, podía mostrarte esto: el módulo 7 te habría dicho "constrúyela, pertenece al juego" y se habría detenido ahí; el módulo 6 te habría dicho "esto no es defendible" sin decirte si de todas formas vale la pena construirlo. Solo cuando corres los dos modelos sobre la misma apuesta, en el mismo lugar, aparece la pregunta completa: ¿construimos recommendations? Sí. ¿Es suficiente construirla y quedarnos tranquilos? No. Esa es exactamente la clase de hallazgo que el pipeline completo de este módulo va a producir, ahora sobre el backlog entero, no solo sobre una apuesta.

El mapa del módulo

Guarda esta ruta. Cada lección llena una capa del one-pager, en el mismo orden en que las construiste a lo largo de la guía, y la lección 8 las encadena todas en un solo pipeline:

Idea                                          Lección   Capa del one-pager
─────────────────────────────────────────────  ────────  ─────────────────────────────────────
El one-pager de estrategia                      L2        la estructura completa + la visión y
                                                            la misión (módulo 2), sin cambios

Dónde jugar                                     L3        segmento + positioning statement,
                                                            verificado con positionFit (módulo 3)

Cómo ganar                                      L4        diferenciación real (differentiationMap,
                                                            módulo 4) + el panorama competitivo
                                                            (competitiveMap, módulo 5)

La capa de moats                                L5        la auditoría completa de defensibilidad
                                                            (moatScore, módulo 6)

El filtro estratégico aplicado                  L6        strategicFilter sobre el backlog
                                                            completo de Mercado (módulo 7)

Presentando la estrategia                       L7        el one-pager completo, ensamblado y
                                                            formateado para un stakeholder real
─────────────────────────────────────────────  ────────  ─────────────────────────────────────
Proyecto: define la estrategia de               L8        el pipeline completo, encadenado:
Mercado de principio a fin                                 positionFit → differentiationMap →
                                                            moatScore → strategicFilter

La frontera: qué NO entra en este módulo

Este módulo responde una pregunta específica: ¿cómo se ve la estrategia completa de Mercado, de principio a fin, y qué apuestas del backlog sobreviven cuando se le exige que pase por las cuatro pruebas a la vez? No responde varias preguntas vecinas:

• "¿Cómo defino una visión, un segmento o una diferenciación desde cero?" — eso ya lo hiciste, a fondo, en los módulos 2, 3 y 4. Este módulo toma esas definiciones como dadas y las reutiliza; no vuelve a enseñar cómo construirlas.
• "¿Cómo se ve un mapa competitivo completo, con proyección a futuro?" — módulo 5. Aquí se usa su conclusión (el espacio despejado, con fecha de vencimiento) como contexto de la capa "cómo ganar", no se reconstruye el mapa completo otra vez.
• "¿Cómo se prioriza dentro de las apuestas que ya pasaron el filtro?" — RICE y WSJF siguen siendo terreno de product-thinking-for-engineers-guide. Este módulo, como el 7, se detiene en la puerta: decide quién compite por prioridad, no en qué orden exacto construye cada equipo con su capacidad real.
• "¿Cómo construyo, técnicamente, cualquiera de las apuestas que sobreviven al filtro?" — arquitectura y construcción real son el ecosistema Fullstack. Esta guía completa —y este módulo, su cierre— define qué construir y por qué; no enseña a construirlo.
• "¿Cómo valido con usuarios reales que el segmento y el job están bien elegidos?" — discovery, terreno de product-discovery-and-prototyping-guide. El one-pager de este módulo asume que el segmento del módulo 3 es correcto; no lo vuelve a probar con usuarios.

Recursos

• Roger Martin, "Decoding the Strategy Choice Cascade" — rogermartin.medium.com/decoding-the-strategy-choice-cascade-475d40555eb1. El marco completo de Playing to Win — cinco elecciones en cascada, cada una condicionada por la anterior — es, literalmente, la estructura que este módulo convierte en código ejecutable para Mercado. En inglés.
• Melissa Perri, Escaping the Build Trap — oreilly.com/library/view/escaping-the-build/9781491973767. El argumento completo de por qué un equipo puede estar ocupadísimo, entregando features de alto RICE, y seguir sin tener una estrategia real — el problema exacto que este capstone resuelve con un documento verificable. En inglés.
• Marty Cagan (Silicon Valley Product Group), "Product Strategy" — svpg.com/product-strategy-overview. Cagan describe la estrategia de producto como la disciplina de convertir información dispersa en decisiones difíciles y defendibles — exactamente lo que el one-pager de este módulo hace, capa por capa. En inglés.
• Hamilton Helmer, 7 Powers — 7powers.com. El vocabulario técnico detrás de la capa de moats de este one-pager (módulo 6), para releer ahora que vas a verlo funcionar dentro del pipeline completo, no aislado. En inglés.