Presentando la estrategia

Descripción

Las cinco capas anteriores del one-pager están completas y verificadas: visión, dónde jugar, cómo ganar, moats, y el filtro estratégico aplicado al backlog. Pero un documento con cinco capas de código y tablas no es todavía algo que puedas leer en voz alta frente al equipo fundador de Mercado en cinco minutos. Esta lección construye el último paso antes del proyecto final: un renderizador que toma los resultados ya verificados de las lecciones 2 a 6 y los formatea en un documento de una sola pieza, legible por cualquier persona que nunca vio ninguno de los siete módulos anteriores de esta guía.

Conexión con el módulo. Esta lección no ejecuta ningún modelo nuevo de evaluación — toma los resultados ya calculados por positionFit, differentiationMap, competitiveMap, moatScore y strategicFilter en las lecciones anteriores, y los convierte en texto presentable. Es la diferencia entre tener la evidencia y saber presentarla — la misma distinción que separa un análisis correcto de una decisión que el equipo fundador realmente puede tomar con confianza.

Una analogía cotidiana: el resumen ejecutivo, no la carpeta de anexos completa

Ningún consultor le entrega a un cliente ejecutivo, como primera página de su informe, doscientas páginas de anexos técnicos. Le entrega un resumen ejecutivo: una sola página que dice, sin rodeos, cuál es la conclusión, cuál es la evidencia clave que la respalda, y qué se recomienda hacer — con los doscientos anexos disponibles, pero solo para quien quiera profundizar. El resumen ejecutivo no es una versión "más simple" del análisis — es una versión destilada, donde cada frase se puede trazar hasta un anexo específico, pero nadie tiene que leer los doscientos para entender la conclusión.

El renderizador de esta lección es exactamente ese resumen ejecutivo. Las cinco capas verificadas de las lecciones 2 a 6 son los "anexos" —completos, con sus tablas, sus modelos, sus números exactos—; el documento que produce renderOnePager es la página que cualquier stakeholder necesita leer primero, con cada línea trazable hasta la capa que la produjo, pero sin exigirle a nadie que revise seis lecciones completas antes de entender hacia dónde va Mercado.

Ejemplo trabajado: el one-pager completo, en un solo bloque de texto

// El one-pager completo de Mercado, ensamblado con los resultados ya
// verificados de las lecciones 2 a 6. renderOnePager() no recalcula nada --
// solo formatea lo que ya corrió, para que se pueda pegar en un documento
// o leer en voz alta en cinco minutos frente al equipo fundador.
function renderOnePager(p) {
  const lines = [];
  lines.push(`ESTRATEGIA DE PRODUCTO -- ${p.product.toUpperCase()}`);
  lines.push('='.repeat(40));
  lines.push('');
  lines.push(`VISIÓN: ${p.vision}`);
  lines.push(`MISIÓN: ${p.mission}`);
  lines.push('');
  lines.push(`DÓNDE JUGAMOS: ${p.whereToPlay} (margen +${p.whereToPlayMargin} sobre el mejor rival)`);
  lines.push(`CÓMO GANAMOS: ${p.howToWin.join(' + ')}`);
  lines.push(`ESPACIO COMPETITIVO: ${p.competitiveSpace}`);
  lines.push(`MOATS REALES: ${p.realMoats.join(', ')} (${p.realMoatCount}/${p.moatCandidateCount})`);
  lines.push(`FILTRO ESTRATÉGICO -- roadmap: ${p.roadmap.join(' > ')}`);
  lines.push(`RECHAZADO, A PESAR DE BUEN RICE: ${p.rejected.join(', ')}`);
  return lines.join('\n');
}

const onePager = {
  product: 'Mercado',
  vision: 'El mundo donde cualquier persona descubre en Mercado lo que no sabía que quería.',
  mission: 'Existimos para conectar hoy a compradores curiosos con vendedores locales de confianza.',
  whereToPlay: 'compradores que exploran (explorers), no los que buscan un SKU exacto',
  whereToPlayMargin: 1.65,
  howToWin: ['curatedDiscovery', 'localSellerTrust'],
  competitiveSpace: 'despejado hoy (openSpace: true), se cierra en 3 años si nadie lo defiende',
  realMoats: ['sellerNetwork', 'purchaseData', 'logisticsNetwork', 'sellerToolsWorkflow'],
  realMoatCount: 4,
  moatCandidateCount: 8,
  roadmap: ['reviews', 'sellerTools', 'recommendations'],
  rejected: ['lowestPriceMatch (riceScore 7600)', 'fasterCheckout (riceScore 6400)'],
};

console.log(renderOnePager(onePager));

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

ESTRATEGIA DE PRODUCTO -- MERCADO
========================================

VISIÓN: El mundo donde cualquier persona descubre en Mercado lo que no sabía que quería.
MISIÓN: Existimos para conectar hoy a compradores curiosos con vendedores locales de confianza.

DÓNDE JUGAMOS: compradores que exploran (explorers), no los que buscan un SKU exacto (margen +1.65 sobre el mejor rival)
CÓMO GANAMOS: curatedDiscovery + localSellerTrust
ESPACIO COMPETITIVO: despejado hoy (openSpace: true), se cierra en 3 años si nadie lo defiende
MOATS REALES: sellerNetwork, purchaseData, logisticsNetwork, sellerToolsWorkflow (4/8)
FILTRO ESTRATÉGICO -- roadmap: reviews > sellerTools > recommendations
RECHAZADO, A PESAR DE BUEN RICE: lowestPriceMatch (riceScore 7600), fasterCheckout (riceScore 6400)

Nueve líneas resumen siete módulos completos de esta guía, y cada una de esas nueve líneas es trazable: la línea VISIÓN viene, sin ningún cambio, del módulo 2; DÓNDE JUGAMOS viene del productWeightedScore y el bestRival que calculó positionFit en la lección 3; CÓMO GANAMOS viene de los realDiffs de differentiationMap en la lección 4; ESPACIO COMPETITIVO viene del openSpace de competitiveMap, también lección 4; MOATS REALES viene del conteo de verdict === 'moat' de la auditoría completa en la lección 5; y las dos últimas líneas vienen directamente del roadmap y los rejected de strategicFilter en la lección 6. Nada en este documento se inventó al momento de redactarlo — todo se copió de un resultado que ya corriste y verificaste antes.

Profundización: por qué renderOnePager no debería recalcular nada

Fíjate en un detalle deliberado del diseño de renderOnePager: la función recibe un objeto onePager ya lleno con valores concretos (whereToPlayMargin: 1.65, realMoatCount: 4) — no recibe los datos crudos de Mercado ni vuelve a correr positionFit o moatScore internamente. Esta separación no es un detalle de implementación menor: es la misma disciplina de "una sola fuente de verdad" que viste en el módulo 2 (nunca redactes la visión de memoria, cítala siempre del documento único) aplicada ahora al nivel del renderizador. Si renderOnePager recalculara los modelos por su cuenta, existiría el riesgo de que la versión "de presentación" y la versión "verificada" divergieran silenciosamente —por ejemplo, si alguien actualiza los datos de positionFit en la lección 3 pero olvida actualizar el objeto que alimenta al renderizador—. Mantener el renderizador puramente como una función de formato, sin lógica de negocio propia, es lo que garantiza que el documento final diga exactamente lo que las capas verificadas dicen, ni más ni menos.

Errores comunes

Redactar el one-pager de presentación a mano, en vez de generarlo desde los resultados verificados. Qué pasa: alguien, apurado antes de una reunión, escribe directamente el texto de presentación —"ganamos con un margen sólido", "tenemos varios moats reales"— sin conectar esas frases con ningún número específico de las lecciones anteriores. Por qué pasa: escribir prosa persuasiva a mano es más rápido, en el momento, que construir el objeto de datos completo y formatearlo con código. Cómo detectarlo: si el one-pager de presentación no tiene un número exacto por cada afirmación (el margen exacto, el conteo exacto de moats, el riceScore exacto de lo rechazado), alguien lo escribió de memoria, no lo generó desde datos verificados. Cómo corregirlo: exige siempre que cada línea del documento final sea trazable hasta un valor numérico específico de una lección anterior, como en el ejemplo de esta lección.

Presentar el one-pager sin la línea de "rechazado, a pesar de buen RICE". Qué pasa: el documento final resalta el roadmap aprobado (reviews > sellerTools > recommendations) pero omite mencionar qué se rechazó y por qué, especialmente las dos apuestas con mayor riceScore de todo el backlog. Por qué pasa: mostrar solo lo positivo se siente más limpio y más orientado a la acción — el mismo error que el módulo 7 ya advirtió a nivel de proyecto, ahora repetido al nivel de la presentación final. Cómo detectarlo: si un stakeholder que conoce el backlog completo tendría que preguntar "¿y fasterCheckout?" después de ver tu one-pager, la línea de rechazados está incompleta o ausente. Cómo corregirlo: la línea RECHAZADO, A PESAR DE BUEN RICE no es opcional — es, con frecuencia, la línea que más convence a un escéptico de que el filtro es real y no una formalidad.

Tratar el one-pager renderizado como el final del trabajo, sin conectar con qué construir. Qué pasa: el documento se presenta, se aplaude, se archiva — y nadie traduce sus nueve líneas en una decisión de ingeniería concreta sobre qué construir primero ni sobre qué apuesta necesita, además de pertenecer a la estrategia, reforzar un moat todavía frágil. Por qué pasa: un documento bien formateado y completo se siente como un punto final, cuando en realidad todavía falta la lectura más importante — cruzar el roadmap contra la auditoría de moats. Cómo detectarlo: si nadie en la reunión donde se presenta este one-pager pregunta "¿y cuál de estas tres construye algo defendible, no solo algo que pertenece al juego?", la lectura más valiosa del documento todavía no ocurrió. Cómo corregirlo: sigue a la lección 8 — el proyecto final no se detiene en presentar el resultado, cruza el roadmap contra los moats y encuentra la respuesta a esa pregunta exacta.

Ejercicios

Ejercicio 1 — Agrega una línea de riesgo al one-pager. Extiende onePager con una nueva clave topRisk: 'curatedDiscovery no es moat todavía (durability 3)', y agrega la línea correspondiente a renderOnePager. Escribe el nuevo bloque de código y predice en qué posición del documento debería aparecer esa línea.

lines.push(`RIESGO PRINCIPAL: ${p.topRisk}`);

Ejercicio 2 — Detecta una inconsistencia deliberada. Si alguien cambiara onePager.whereToPlayMargin a 2.5 sin haber vuelto a correr positionFit, ¿cómo lo detectarías, dado que renderOnePager no recalcula nada por su cuenta?

Ejercicio 3 — Presenta el one-pager completo en cinco minutos. Usando el texto exacto de la salida de esta lección, escribe el guion de una presentación oral de cinco minutos frente al equipo fundador de Mercado, sin leer las nueve líneas textualmente — conviértelas en una narrativa hablada natural.

Resumen y siguiente paso

En esta lección ensamblaste el one-pager completo de Mercado en un solo documento de presentación: nueve líneas, cada una trazable hasta el resultado verificado de una capa anterior, listas para leerse en voz alta frente a cualquier stakeholder sin necesitar seis lecciones de contexto previo.

Antes de avanzar deberías poder: explicar por qué renderOnePager no recalcula ningún modelo, y ubicar de qué lección viene cada una de las nueve líneas del documento.

La lección 8, el proyecto final de esta guía, va más allá de presentar el resultado: encadena positionFit, differentiationMap, moatScore y strategicFilter en un solo pipeline ejecutado de principio a fin, deriva winOn y avoid directamente del código en vez de declararlos a mano, y cruza el roadmap final contra la auditoría de moats — el último hallazgo de toda la guía, y el cierre del arco completo de product-strategy-for-engineers-guide.

Recursos

• Marty Cagan (SVPG), "Product Strategy" — svpg.com/product-strategy-overview. Cagan insiste en que una buena estrategia de producto debe poder comunicarse con claridad a cualquier stakeholder — el estándar exacto que el renderizador de esta lección persigue. En inglés.
• Roger Martin, "Playing to Win" (sitio del libro) — rogerlmartin.com/lets-read/playing-to-win. El formato de "cascada de elecciones" de Martin es, en esencia, un one-pager de estrategia — la misma disciplina de condensar decisiones complejas en un documento legible. En inglés.
• Gibson Biddle, "Intro to Product Strategy" — gibsonbiddle.medium.com/intro-to-product-strategy-60bdf72b17e3. Ejemplos reales de cómo comunicar una estrategia de producto completa en un documento corto, la misma disciplina que esta lección aplicó al caso de Mercado. En inglés.