El one-pager de estrategia

Descripción

Una estrategia que vive dispersa en siete documentos —una nota sobre la visión, un slide sobre el segmento, un doc de diferenciación, un mapa competitivo en otra carpeta, una auditoría de moats en un tercer sistema, un backlog filtrado en una hoja de cálculo— no es una estrategia utilizable. Es material para una estrategia. Esta lección construye el one-pager: un solo documento, con una estructura fija de capas, donde cada capa tiene un dueño claro (un módulo específico de esta guía) y un lugar exacto. No introduce ningún concepto nuevo — introduce el esqueleto que las lecciones 3 a 7 van a llenar, una capa a la vez, y que la lección 8 va a ejecutar como un solo pipeline.

Conexión con el módulo. Esta es la lección fundacional del capstone: define la forma del documento final antes de empezar a llenarlo. Reutiliza, sin cambios, la visión y la misión de Mercado que construiste en el módulo 2 — la primera capa del one-pager es, literalmente, ese resultado, copiado verbatim, no reescrito.

Una analogía cotidiana: el tablero de instrumentos de la cabina, no siete relojes sueltos

Un piloto no vuela un avión leyendo siete instrumentos colocados al azar por la cabina, cada uno en un rincón distinto, sin ningún orden entre ellos. Vuela con un tablero de instrumentos: una disposición fija, estandarizada en toda la industria, donde el altímetro siempre está en el mismo lugar relativo al horizonte artificial, y el indicador de velocidad siempre está donde el piloto espera encontrarlo, sin tener que buscarlo. La disposición del tablero no es decorativa — es lo que le permite a un piloto, en una emergencia, encontrar el dato correcto en menos de un segundo, sin tener que pensar "¿dónde estaba el indicador de combustible en este avión?".

El one-pager de estrategia es ese tablero, aplicado a las decisiones de producto. Cuando alguien en Mercado pregunta "¿por qué no construimos lowestPriceMatch, si tiene tan buen RICE?", la respuesta no debería requerir una investigación de media hora por siete documentos distintos — debería estar en un lugar fijo del one-pager, exactamente donde cualquier persona del equipo espera encontrarla. Esta lección construye ese tablero, capa por capa, antes de que las lecciones siguientes empiecen a llenar cada instrumento.

Las capas del one-pager, y quién las llena

El one-pager de este módulo tiene seis capas. Cada una corresponde a un módulo anterior de la guía —o, en el caso de la última, a este mismo módulo— y ninguna se salta a la siguiente sin haber quedado completa:

Capa                    Lección de este módulo    Módulo de origen    Modelo ejecutado
───────────────────    ───────────────────────    ─────────────────   ─────────────────
foundation               L2 (esta lección)          M2 (visión)         --  (dato, no modelo)
whereToPlay               L3                         M3 (target)         positionFit
howToWin                  L4                         M4 + M5             differentiationMap +
                                                                          competitiveMap
moats                     L5                         M6                  moatScore
strategicFilter            L6                         M7                  strategicFilter
(pipeline completo)       L8                         M3+M4+M6+M7          las 4 encadenadas

Fíjate en algo importante: la capa foundation —la visión y la misión— es la única que no corre ningún modelo ejecutable. Es, deliberadamente, el único punto de partida cualitativo de todo el one-pager: una declaración de dirección que el equipo eligió, no algo que un algoritmo calculó. Todo lo que viene después —dónde jugar, cómo ganar, los moats, el filtro— sí se verifica con código, precisamente porque parte de una elección fundacional que en algún momento tuvo que decidirse sin un modelo que la validara. Esa es, en una frase, la diferencia entre elegir una dirección y verificar que las decisiones posteriores son coherentes con ella.

Ejemplo trabajado: el esqueleto del one-pager, con la primera capa llena

Construimos el objeto onePager con sus seis capas, marcamos cuáles están llenas y cuáles pendientes con una función pequeña de estado, y llenamos la única capa que este módulo no necesita ningún modelo para completar: la visión y la misión, copiadas verbatim del módulo 2.

// El one-pager de estrategia de Mercado: seis capas, una por lección de este módulo.
// Esta lección llena la primera -- la visión y la misión, sin cambios desde el módulo 2.
const vision = {
  statement: 'El mundo donde cualquier persona descubre en Mercado lo que no sabía que quería.',
  horizon: '10+ años, sin fecha límite',
  includes: ['curatedDiscovery', 'localSellerTrust', 'serendipity'],
  excludes: ['exactSkuSearchEngine', 'lowestPriceRace', 'genericMegastore'],
};
const mission = {
  statement: 'Existimos para conectar hoy a compradores curiosos con vendedores locales de confianza.',
  horizon: 'hoy, con lo que ya existe',
};

const onePager = {
  foundation: { vision, mission },
  whereToPlay: null,
  howToWin: null,
  moats: null,
  strategicFilter: null,
};

function onePagerStatus(pager) {
  return Object.entries(pager).map(([layer, value]) => ({
    layer,
    status: value === null ? 'pendiente' : 'completo',
  }));
}

console.log('=== El one-pager de estrategia de Mercado, capa por capa ===\n');
console.table(onePagerStatus(onePager));
console.log(`Visión:  "${vision.statement}"`);
console.log(`Misión:  "${mission.statement}"`);
console.log(`Excludes: ${vision.excludes.join(', ')}`);

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

=== El one-pager de estrategia de Mercado, capa por capa ===

┌─────────┬───────────────────┬─────────────┐
│ (index) │       layer       │   status    │
├─────────┼───────────────────┼─────────────┤
│    0    │   'foundation'    │ 'completo'  │
│    1    │   'whereToPlay'   │ 'pendiente' │
│    2    │    'howToWin'     │ 'pendiente' │
│    3    │      'moats'      │ 'pendiente' │
│    4    │ 'strategicFilter' │ 'pendiente' │
└─────────┴───────────────────┴─────────────┘
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."
Excludes: exactSkuSearchEngine, lowestPriceRace, genericMegastore

Una capa de cinco está completa, y las otras cuatro están, deliberadamente, marcadas pendiente — no vacías por descuido, sino a la espera de su lección correspondiente. Este es el patrón que vas a repetir, con datos distintos, en cada una de las próximas cinco lecciones: nunca declares que una capa está lista sin haberla verificado con el modelo que le corresponde. Una visión bonita, sin excludes explícitos, no cuenta como foundation completa — y por eso vision.excludes aparece impreso explícitamente al final de este ejemplo, no solo el statement inspirador.

Profundización: por qué el orden de las capas no es arbitrario

Podrías preguntarte por qué whereToPlay va antes que howToWin, y por qué moats va después de ambas, en vez de, por ejemplo, empezar por los moats —la pregunta de defensibilidad, que suena más "estratégica" a primera vista. El orden importa porque cada capa depende de la anterior, de la misma forma que la cascada de Roger Martin en Playing to Win encadena sus cinco elecciones:

• No puedes definir cómo ganas (howToWin, diferenciación) sin haber elegido antes dónde juegas (whereToPlay, segmento) — la diferenciación siempre es diferenciación para alguien específico, nunca en abstracto. Por eso el módulo 4 llegó después del módulo 3, y por eso esta lección va antes que la siguiente.
• No puedes auditar moats con criterio sin saber primero qué diferenciación estás intentando defender — un moat que no protege nada de tu propuesta de valor real es una fortaleza alrededor de un campo vacío. Por eso moats va después de howToWin, nunca antes.
• No puedes aplicar el filtro estratégico al backlog sin que winOn y avoid ya existan — y esos dos valores vienen, precisamente, de whereToPlay y howToWin. Por eso strategicFilter es la última capa antes del pipeline completo.

Esta dependencia estricta es la razón por la que el one-pager tiene capas, no una lista plana de seis datos sin relación. Cada capa es un insumo de la siguiente, y saltarse una —por ejemplo, auditar moats sin haber definido antes la diferenciación real— produce un documento que parece completo pero no puede explicar sus propias conclusiones.

Errores comunes

Empezar el one-pager por la capa que más entusiasma, no por la que corresponde primero. Qué pasa: alguien en el equipo, emocionado por los moats —suena a la parte "más estratégica"—, empieza a llenar esa capa antes de haber definido con precisión el segmento y la diferenciación que se supone que esos moats protegen. Por qué pasa: dónde jugar y cómo ganar se sienten como trabajo preparatorio, mientras que moats y filtro estratégico se sienten como el resultado final — y es tentador saltar directo al resultado. Cómo detectarlo: si alguien puede nombrar un moat de Mercado sin poder decir, en la misma frase, qué diferenciación específica ese moat protege, el orden se saltó. Cómo corregirlo: respeta la secuencia de este módulo, lección por lección — cada capa exige que la anterior exista primero, sin excepción.

Tratar foundation como si no necesitara verificación por ser "solo" la visión. Qué pasa: el equipo copia la visión y la misión al one-pager sin revisar si tienen excludes explícitos, dando por sentado que, como ya se escribieron en el módulo 2, están automáticamente listas. Por qué pasa: la capa foundation es la única sin modelo ejecutable, y eso se confunde con "sin ningún estándar de calidad" — cuando en realidad el módulo 2 exige exactamente el mismo rigor (includes y excludes explícitos) que las capas con modelos. Cómo detectarlo: si tu onePager.foundation no tiene excludes tan concretos como includes, no está completa, aunque onePagerStatus la marque 'completo' solo por no ser null — el chequeo de esta lección verifica presencia, no calidad. Cómo corregirlo: antes de marcar foundation como lista, aplica el mismo criterio del módulo 2: ¿los excludes nombran negocios legítimos y rentables a los que Mercado dice que no, o son solo obviedades?

Confundir "el one-pager tiene seis capas" con "el one-pager debe caber en una sola pantalla sin scroll". Qué pasa: alguien intenta comprimir las seis capas —incluyendo tablas completas de positionFit y differentiationMap— en un documento visualmente diminuto, sacrificando el detalle que hace que cada capa sea verificable. Por qué pasa: el nombre "one-pager" se interpreta literalmente como una restricción de espacio físico, en vez de como una restricción de estructura: un solo documento con una estructura fija, no necesariamente una sola pantalla sin desplazamiento. Cómo detectarlo: si tu one-pager omite el detalle ejecutado (las tablas, los números, el fitsSegment: true) para que quepa en menos espacio, dejó de ser verificable y volvió a ser solo prosa bonita. Cómo corregirlo: prioriza que cada capa sea trazable hasta su modelo y su dato — "una sola fuente de verdad", no "una sola pantalla". El proyecto final (lección 8) muestra cómo mantener ambas cosas: compacto en la narrativa, completo en la verificación.

Ejercicios

Ejercicio 1 — Predice el estado antes de correr. Sin ejecutar código, si agregas una séptima clave al objeto onePager llamada pitch: null, ¿qué fila nueva aparecería en la tabla de onePagerStatus, y con qué status?

Ejercicio 2 — Verifica la calidad de foundation, no solo su presencia. Escribe, en pseudocódigo o JavaScript real, una función foundationIsComplete(foundation) que retorne true solo si foundation.vision.excludes tiene al menos tantos elementos como foundation.vision.includes (el estándar de rigor del módulo 2, no solo "existe").

function foundationIsComplete(foundation) {
  const { includes, excludes } = foundation.vision;
  return Array.isArray(excludes) && excludes.length >= includes.length;
}

Ejercicio 3 — Explica el orden de las capas a un compañero impaciente. Un compañero de ingeniería, que quiere "saltarse directo a los moats porque es la parte interesante", te pregunta por qué no puede simplemente escribir esa capa primero. Usando el vocabulario de la sección "Profundización" (dependencia entre capas, la cascada de Roger Martin), escribe en 2-3 frases tu respuesta.

Resumen y siguiente paso

En esta lección construiste el esqueleto completo del one-pager de estrategia de Mercado: seis capas, cada una con un módulo de origen y un modelo ejecutable (excepto foundation, la única cualitativa por diseño), y llenaste la primera con la visión y la misión, copiadas verbatim del módulo 2. Confirmaste, con onePagerStatus, que las cinco capas restantes están correctamente marcadas como pendientes — no vacías por descuido, sino a la espera de su turno.

Antes de avanzar deberías poder: nombrar las seis capas en orden, explicar por qué cada una depende de la anterior, y distinguir entre "una capa existe" (lo que verifica onePagerStatus) y "una capa cumple el estándar de su módulo de origen" (lo que verificaste en el Ejercicio 2).

La lección 3 llena la segunda capa: dónde juega Mercado, con positionFit corriendo sobre el segmento y las alternativas exactas del módulo 3 — el primer modelo ejecutable de este one-pager.

Recursos

• Roger Martin, "Decoding the Strategy Choice Cascade" — rogermartin.medium.com/decoding-the-strategy-choice-cascade-475d40555eb1. La cascada de cinco elecciones en cadena que justifica, aquí, por qué el one-pager tiene capas con dependencia estricta y no una lista plana de datos sueltos. En inglés.
• Marty Cagan (SVPG), "Product Vision vs. Mission" — svpg.com/product-vision-vs-mission. Para releer la distinción exacta entre vision y mission que la capa foundation de este one-pager reproduce sin cambios. En inglés.
• Gibson Biddle, "Intro to Product Strategy" — gibsonbiddle.medium.com/intro-to-product-strategy-60bdf72b17e3. Un ejemplo real de cómo un equipo de producto condensa una estrategia completa en un documento corto y verificable — el mismo espíritu del one-pager que empezaste a construir en esta lección. En inglés.