Módulo 7: Strategy To Roadmap
Presentación del módulo: de la estrategia al roadmap
Por qué este módulo existe aquí
Ya hiciste todo el trabajo de arriba. El módulo 2 te dio la visión de Mercado. El módulo 3 eligió el segmento —compradores que exploran, no los que buscan un SKU exacto— y el posicionamiento frente a las alternativas. El módulo 4 encontró la diferenciación real, no la paridad. El módulo 5 mapeó el panorama competitivo completo y hacia dónde se mueve. El módulo 6 identificó qué hace defendible esa posición —los moats: la red de vendedores y los datos de compra de Mercado, no una feature copiable en un fin de semana—. Tienes, en este punto, una estrategia completa: dónde juega Mercado y cómo gana.
Y sin embargo, ninguna de esas cinco piezas construyó una sola línea de producto. Una estrategia que vive solo en un documento —por muy bien razonada que esté— no cambia nada de lo que un equipo de ingeniería hace el lunes por la mañana. Este módulo cierra esa brecha: cómo la estrategia baja al roadmap, convirtiéndose en el criterio que decide, antes que cualquier otra cosa, qué apuestas siquiera entran a la conversación de qué construir primero.
Aquí es donde esta guía se cruza, de frente, con product-thinking-for-engineers-guide. En el módulo 3 de esa guía, el equipo de Mercado tomó su backlog del trimestre —fasterCheckout, recommendations, sellerTools, reviews, improvedSearch— y lo priorizó con la fórmula RICE. El resultado fue nítido: fasterCheckout ganó por un margen enorme, con un riceScore de 6400, casi tres veces el segundo lugar. Ese análisis es correcto en sus propios términos —RICE mide bien el valor esperado por unidad de costo—, y sin embargo deja una pregunta completa sin responder, porque nunca estuvo diseñado para responderla: ¿esa apuesta pertenece al juego que Mercado eligió jugar? RICE no lo sabe. RICE no puede saberlo — no tiene ningún input que hable de segmento, posicionamiento, diferenciación o moats. Ese es exactamente el trabajo de este módulo.
Conexión con el módulo 6. El módulo 6 te dejó con la pregunta de qué tan defendible es la posición de Mercado si alguien la ataca. Este módulo empieza un paso antes: qué tan defendible es la posición desde adentro — si el propio equipo de Mercado, sin que nadie los ataque, construye apuestas que no refuerzan ni el segmento, ni el posicionamiento, ni los moats que tanto costó construir, la estrategia se diluye sola, sin necesidad de un solo competidor.
Una analogía cotidiana: el control de seguridad, antes del tablero de vuelos
En cualquier aeropuerto grande, antes de que un pasajero pueda siquiera mirar el tablero de vuelos y decidir por cuál puerta apurarse, tiene que pasar por control de seguridad. El control de seguridad no le pregunta a nadie "¿qué tan urgente es tu vuelo?" ni "¿qué tan cara fue tu maleta?" — pregunta una sola cosa: ¿tienes un pase de abordar válido para un vuelo que sale de aquí? Si la respuesta es no, no importa cuán organizado vengas, cuán rápido camines, ni cuán elegante sea tu equipaje: no pasas. Y si la respuesta es sí, entonces —y solo entonces— tu nombre entra al tablero, donde un criterio completamente distinto —el orden de salida, la puerta, la hora— decide qué tan arriba apareces.
Son dos filtros distintos, en dos momentos distintos, y mezclarlos es el error que arruina el sistema completo. Si dejaras que "cuán organizado viene el pasajero" decidiera quién entra al aeropuerto —sin preguntar primero si tiene un pase válido— tendrías una terminal llena de gente eficiente que no puede volar a ningún lado. El filtro estratégico de este módulo es exactamente el control de seguridad: decide quién pertenece al juego, antes de que a nadie le importe qué tan bien puntúa en RICE. El tablero de vuelos —la secuencia final, el orden de construcción— es, literalmente, el trabajo que product-thinking-for-engineers-guide ya te enseñó a hacer. Este módulo no reemplaza el tablero. Construye el control de seguridad que tiene que pasar antes.
Ejemplo trabajado: tres apuestas, un vistazo rápido al filtro
Antes de construir el modelo completo (lección 3 en adelante), vale la pena ver el patrón una vez, con solo tres apuestas del backlog de Mercado. Vamos a etiquetar cada apuesta con la dimensión estratégica que dice servir —servesDimensions—, y a declarar la estrategia de Mercado tal como quedó definida en los módulos anteriores: gana en descubrimiento curado y confianza en el vendedor (winOn), y decidió explícitamente no competir en precio (avoid) — la misma decisión que citaste, palabra por palabra, desde el módulo 2: "Elegimos enfocarnos en compradores que exploran, no en los que buscan un SKU exacto, y ganamos invirtiendo en descubrimiento curado en vez de en el precio más bajo."
// riceScore reutilizado, sin cambios, de product-thinking-for-engineers-guide (modulo 3)
function riceScore({ reach, impact, confidence, effort }) {
return (reach * impact * confidence) / effort;
}
// Modelo pedagogico: una apuesta "pertenece a la estrategia" si al menos una
// de las dimensiones que sirve esta en strategy.winOn (lo que la estrategia
// eligio para GANAR) Y ninguna esta en strategy.avoid (lo que eligio
// explicitamente NO pelear). Servir una dimension neutral no alcanza.
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,
servesDimensions: bet.servesDimensions,
reinforces,
conflicts,
inStrategy: reinforces.length > 0 && conflicts.length === 0,
riceScore: Number(riceScore(bet.rice).toFixed(2)),
};
});
}
const mercadoStrategy = { winOn: ['curatedDiscovery', 'sellerTrust'], avoid: ['price'] };
const teaser = [
{ feature: 'fasterCheckout', servesDimensions: ['convenience'], rice: { reach: 8000, impact: 2, confidence: 0.8, effort: 2 } },
{ feature: 'recommendations', servesDimensions: ['curatedDiscovery'], rice: { reach: 5000, impact: 1, confidence: 0.5, effort: 3 } },
{ feature: 'lowestPriceMatch', servesDimensions: ['price'], rice: { reach: 9500, impact: 3, confidence: 0.8, effort: 3 } },
];
console.log('=== strategicFilter: tres apuestas del backlog de Mercado, ordenadas por RICE ===\n');
const result = strategicFilter(teaser, mercadoStrategy).sort((a, b) => b.riceScore - a.riceScore);
console.table(result);
console.log('El mayor riceScore del trio (' + result[0].feature + ', ' + result[0].riceScore + ') tiene inStrategy: ' + result[0].inStrategy + '.');
Qué esperar. Al correr el archivo con Node, la salida es exactamente esta:
=== strategicFilter: tres apuestas del backlog de Mercado, ordenadas por RICE ===
┌─────────┬────────────────────┬────────────────────────┬────────────────────────┬─────────────┬────────────┬───────────┐
│ (index) │ feature │ servesDimensions │ reinforces │ conflicts │ inStrategy │ riceScore │
├─────────┼────────────────────┼────────────────────────┼────────────────────────┼─────────────┼────────────┼───────────┤
│ 0 │ 'lowestPriceMatch' │ [ 'price' ] │ [] │ [ 'price' ] │ false │ 7600 │
│ 1 │ 'fasterCheckout' │ [ 'convenience' ] │ [] │ [] │ false │ 6400 │
│ 2 │ 'recommendations' │ [ 'curatedDiscovery' ] │ [ 'curatedDiscovery' ] │ [] │ true │ 833.33 │
└─────────┴────────────────────┴────────────────────────┴────────────────────────┴─────────────┴────────────┴───────────┘
El mayor riceScore del trio (lowestPriceMatch, 7600) tiene inStrategy: false.
Ahí está el módulo entero, adelantado en una sola tabla. lowestPriceMatch —igualar el precio más bajo del mercado— tiene el riceScore más alto de las tres apuestas, casi el doble que la segunda. Y sin embargo inStrategy es false: no porque el número esté mal calculado, ni porque la apuesta sea mala en abstracto, sino porque compite exactamente en la dimensión que Mercado decidió no pelear. fasterCheckout —la apuesta que ganó por goleada en product-thinking-for-engineers-guide— tampoco pasa: no compite en precio, pero tampoco refuerza ninguna de las dos dimensiones donde Mercado eligió ganar. Solo recommendations, con el riceScore más bajo del trío, pertenece de verdad a la estrategia. Si solo miraras RICE, construirías las dos apuestas equivocadas primero. Ese es, en una frase, el problema que resuelve este módulo.
El mapa del módulo
Guarda esta ruta. El módulo entero avanza de cómo se traduce la estrategia en apuestas concretas a el filtro que decide quién compite por prioridad, pasando por la trampa más cara de ignorarlo, la coherencia entre las apuestas que sí pasan, y cómo decir que no con una razón real:
Idea Lección Concepto clave
───────────────────────────────────────────── ──────── ─────────────────────────────────────
De la estrategia a las apuestas L2 traducir "dónde jugamos y cómo
ganamos" en candidatos concretos
El filtro estratégico L3 strategicFilter completo: pertenecer
a la estrategia, ANTES de mirar RICE
RICE alto, fuera de estrategia L4 la trampa: el numerador grande no
compra pertenencia al juego
Coherencia estratégica L5 las apuestas que pasan se refuerzan
entre sí, no se dispersan
Decir que NO a nivel estratégico L6 la razón explícita, no el silencio
ni "no hay tiempo este trimestre"
El puente estrategia-roadmap L7 filtro primero, RICE después --
conecta con product-thinking
───────────────────────────────────────────── ──────── ─────────────────────────────────────
Proyecto: el filtro estratégico sobre L8 el backlog completo de Mercado,
el backlog de Mercado filtrado y luego secuenciado
La frontera: qué NO entra en este módulo
Este módulo responde una pregunta específica: ¿qué apuestas pertenecen a la estrategia de Mercado, y en qué orden se construyen las que sí? No responde varias preguntas vecinas, que pertenecen a otros módulos de esta guía o a otras guías del ecosistema:
- "¿Cuál construimos primero, entre las que ya pasaron el filtro?" — ese es el trabajo de RICE y WSJF, y ya lo hiciste a fondo en
product-thinking-for-engineers-guide(módulos 3 y 7). Este módulo no vuelve a enseñar la fórmula ni sus cuatro inputs — los reutiliza, sin cambios, y solo después de que el filtro ya decidió quién es elegible. - "¿Qué tan grande es la oportunidad de una apuesta específica?" — el sizing sigue siendo terreno de
product-thinking-for-engineers-guide(módulo 4). Este módulo no dimensiona nada; decide pertenencia. - "¿La estrategia misma está bien definida?" — eso ya lo construiste en los módulos 2 a 6: visión, segmento, posicionamiento, diferenciación, competencia y moats. Este módulo toma esa estrategia como dada y la usa como criterio; no la vuelve a auditar.
- "¿Cómo validamos con usuarios reales que una apuesta va a funcionar?" — discovery, terreno de
product-discovery-and-prototyping-guide. El filtro estratégico decide si una apuesta pertenece al juego; no mide si va a tener éxito una vez construida. - "¿Cómo medimos si la apuesta, ya construida, funcionó?" — métricas y experimentación, terreno de
product-metrics-and-experimentation-guide. Aquí el filtro corre antes de construir nada.
Recursos
- Roger Martin, "Decoding the Strategy Choice Cascade" — rogermartin.medium.com/decoding-the-strategy-choice-cascade-475d40555eb1. Las cinco elecciones en cascada de Playing to Win terminan, deliberadamente, en las capacidades y los sistemas de gestión concretos — la misma bajada de "dónde jugar y cómo ganar" a una acción concreta que este módulo completa para Mercado. En inglés.
- Melissa Perri, Escaping the Build Trap: How Effective Product Management Creates Real Value (O'Reilly, 2018) — oreilly.com/library/view/escaping-the-build/9781491973767. El argumento de fondo de todo este módulo: un equipo puede estar completamente ocupado, entregando features de alto RICE, y seguir cayendo en el build trap si esas features no están conectadas a ninguna estrategia real. 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 en decisiones difíciles de priorización — exactamente el puente que este módulo construye entre los módulos 2-6 y el roadmap. En inglés.
- Itamar Gilad, "Why You Should Stop Using Product Roadmaps and Try GIST Planning" — itamargilad.medium.com/why-i-stopped-using-product-roadmaps-and-switched-to-gist-planning-3b7f54e271d1. Gilad argumenta que un roadmap de features sueltas, sin un hilo que las conecte con las metas (Goals) que se supone que persiguen, es la razón por la que la mayoría de los roadmaps envejecen mal — el problema exacto que el filtro estratégico de este módulo previene. En inglés.