El costo de ejecutar impecable la estrategia equivocada

Descripción

Ya tienes las dos piezas: sabes distinguir táctica de estrategia (lección 2), y sabes reconocer una estrategia real frente a una bad strategy (lección 3). Esta lección las junta en una sola pregunta, la más incómoda del módulo: ¿cuánto vale, en resultado real, la ejecución perfecta — si la estrategia de fondo era la equivocada?

La respuesta intuitiva de mucha gente es "algo debe valer" — que una ejecución brillante, aunque la dirección esté mal, al menos amortigua el golpe. La respuesta que esta lección va a demostrar, con un modelo ejecutado, es más dura: el resultado depende de ambos ejes a la vez, y una estrategia equivocada le pone un techo casi al piso al mejor resultado posible, sin importar cuán perfecta sea la ejecución por debajo de ese techo. Una estrategia correcta, incluso con una ejecución apenas decente, puede superar por mucho a la ejecución perfecta de la estrategia equivocada. Esta no es una opinión motivacional — es, literalmente, lo que vas a ver salir de un cálculo.

Conexión con el módulo. Esta es la lección donde las lecciones 2 y 3 se cruzan sobre números. Vas a construir outcomeOf, el segundo modelo ejecutado del módulo, y correrlo sobre tres escenarios de Mercado que retoman, directamente, las frases del offsite que ya clasificaste en la lección 3. El mismo modelo va a reaparecer, con nuevos escenarios, en el proyecto de la lección 8.

Una analogía: dos corredores, dos carreras distintas

Imagina dos corredores entrenando para una maratón. El primero se prepara para la carrera que en realidad se corre el domingo — un circuito urbano llano, de 42 kilómetros. Entrena con disciplina razonable: corre casi todos los días, aunque a veces se salta una sesión, y su ritmo no es espectacular. El segundo entrena, con una disciplina y una técnica extraordinarias —nutrición perfecta, cada sesión cronometrada al segundo, la mejor preparación física que se puede comprar— pero para una carrera distinta: un ultramaratón de montaña de 100 kilómetros que él cree, por error, que es la que se corre el domingo.

El domingo llega, y la carrera real es la urbana de 42 kilómetros. El primer corredor la termina, con un tiempo mediocre pero termina, exactamente la carrera que había que correr. El segundo —con toda su preparación superior— llega confundido a la línea de salida equivocada, con un cuerpo entrenado para resistir cien kilómetros de montaña en un circuito que no existe ese día. Su preparación fue objetivamente mejor. Su resultado en la carrera real es, sin embargo, peor: ni siquiera corre la carrera que importaba. La calidad del entrenamiento —la ejecución— no compró nada, porque se aplicó a la carrera equivocada. Eso es, exactamente, lo que outcomeOf va a poner en números.

Ejemplo trabajado: outcomeOf sobre tres apuestas de Mercado

Vamos a construir un modelo de puntaje simple. La idea central: la estrategia pone un techo al resultado posible — un techo altísimo si la estrategia es correcta, un techo muy bajo si es incorrecta. La ejecución decide qué tan cerca del techo llegas, pero nunca puede cruzarlo. Los pesos son ilustrativos, elegidos para que el patrón se vea con claridad — no son una fórmula real de negocio, y lo declaramos así a propósito.

// outcomeOf({ strategyQuality, executionQuality }): modelo pedagogico de puntaje.
// La estrategia pone un TECHO al resultado posible; la ejecucion decide que tan
// cerca llegas de ese techo. Una estrategia 'wrong' tiene un techo casi al piso --
// ninguna ejecucion, por perfecta que sea, lo cruza. Pesos ilustrativos, no una
// formula real de negocio.
function outcomeOf({ strategyQuality, executionQuality }) {
  const strategyCeiling = { right: 100, wrong: 10 };
  const executionFactor = { poor: 0.3, medium: 0.6, great: 1.0 };
  const score = Math.round(strategyCeiling[strategyQuality] * executionFactor[executionQuality]);
  let verdict;
  if (score >= 70) verdict = 'great';
  else if (score >= 40) verdict = 'moderate';
  else if (score >= 15) verdict = 'poor';
  else verdict = 'failing';
  return { score, verdict };
}

const scenarios = [
  {
    label: 'A. Mercado construye un buscador generico tipo gigante, ejecutado a la perfeccion',
    strategyQuality: 'wrong',
    executionQuality: 'great',
  },
  {
    label: 'B. Mercado invierte en curaduria + vendedores locales, ejecucion apenas decente',
    strategyQuality: 'right',
    executionQuality: 'medium',
  },
  {
    label: 'C. Mercado invierte en curaduria + vendedores locales, pero la ejecucion es mala',
    strategyQuality: 'right',
    executionQuality: 'poor',
  },
];

console.log('=== outcomeOf: la ejecucion no rescata la estrategia equivocada ===\n');
const results = scenarios.map((s) => {
  const r = outcomeOf(s);
  console.log(s.label);
  console.log('  strategy=' + s.strategyQuality + ', execution=' + s.executionQuality +
    ' => score=' + r.score + ', verdict=' + r.verdict + '\n');
  return { ...s, ...r };
});

const A = results[0];
const B = results[1];
console.log('Comparacion clave: B (' + B.score + ', estrategia correcta, ejecucion apenas decente) ' +
  (B.score > A.score ? 'SUPERA a' : 'NO supera a') +
  ' A (' + A.score + ', estrategia equivocada, ejecucion perfecta).');

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

=== outcomeOf: la ejecucion no rescata la estrategia equivocada ===

A. Mercado construye un buscador generico tipo gigante, ejecutado a la perfeccion
  strategy=wrong, execution=great => score=10, verdict=failing

B. Mercado invierte en curaduria + vendedores locales, ejecucion apenas decente
  strategy=right, execution=medium => score=60, verdict=moderate

C. Mercado invierte en curaduria + vendedores locales, pero la ejecucion es mala
  strategy=right, execution=poor => score=30, verdict=poor

Comparacion clave: B (60, estrategia correcta, ejecucion apenas decente) SUPERA a A (10, estrategia equivocada, ejecucion perfecta).

Lee los tres escenarios con cuidado, porque cada uno prueba algo distinto. El escenario A es Ana escalando Cerro Torre con una técnica de nueve: la mejor ejecución posible (great), aplicada a la estrategia equivocada (competir de frente contra el gigante genérico en su propio terreno, algo que la lección 5 y el módulo 5 completo van a mostrar por qué es casi imposible de ganar). El resultado: score = 10, verdict = 'failing'. No es un resultado mediocre — es un fracaso, a pesar de una ejecución perfecta. El escenario B es la estrategia correcta (curaduría + vendedores locales, la que pasó la prueba de isRealStrategy en la lección 3) con una ejecución apenas decente, con errores, sin ser perfecta. El resultado: score = 60, verdict = 'moderate' — nada espectacular, pero seis veces mejor que el escenario A. El escenario C confirma que la estrategia correcta tampoco es una garantía por sí sola: con una ejecución mala, incluso la estrategia correcta cae a score = 30. Estrategia correcta no significa que la ejecución deje de importar — significa que el techo al que puede aspirar esa ejecución es mucho más alto.

La línea de comparación final lo dice sin rodeos: B supera a A por 50 puntos, a pesar de que la ejecución de B es apenas "decente" y la de A es "perfecta". Ese es el argumento completo de esta lección, convertido en un número que puedes recalcular tú mismo cambiando los datos de entrada.

Por qué la estrategia funciona como un techo, no como un promedio

Vale la pena detenerse en la forma matemática del modelo, porque no es arbitraria: score = strategyCeiling × executionFactor es una multiplicación, no una suma. Si el modelo promediara los dos ejes en vez de multiplicarlos, una ejecución perfecta (100 en una escala de 0 a 100) podría compensar buena parte de una mala estrategia (10 en esa misma escala): el promedio de 100 y 10 es 55, un resultado nada terrible. Pero eso no es lo que pasa en el mundo real, y por eso el modelo multiplica: una estrategia equivocada no resta puntos, los multiplica por casi cero. No importa qué tan alto sea el executionFactor —hasta 1.0, el máximo posible—, 10 × 1.0 sigue siendo apenas 10. La estrategia no es un ingrediente más que se promedia con los demás: es el techo estructural que determina si los demás ingredientes tienen dónde aterrizar.

Esto también explica por qué el escenario C (right + poor = 30) todavía le gana, aunque por poco, a cualquier ejecución posible del escenario wrong: el techo de 100 con la peor ejecución (0.3) sigue dando 30, mientras que el techo de 10 con la mejor ejecución (1.0) da apenas 10. La estrategia correcta, incluso mal ejecutada, casi siempre va a superar a la estrategia equivocada, sin importar qué tan bien se ejecute — porque el rango de resultados posibles de una estrategia correcta empieza mucho más arriba del techo completo de una estrategia equivocada. Esta propiedad —que el peor caso de una buena estrategia puede superar al mejor caso de una mala— es la razón concreta, no retórica, de por qué esta guía completa insiste en resolver la pregunta de la estrategia antes de invertir en la ejecución.

Errores comunes

Ejecutar impecable sin preguntar si es la montaña correcta. Qué pasa: un equipo pone toda su energía en la calidad de la ejecución —código, velocidad, pulido— y da por sentado que la elección de fondo ya estaba resuelta o que no vale la pena cuestionarla a mitad de camino. Por qué pasa: cuestionar la estrategia a mitad de un proyecto se siente como admitir que se perdió tiempo, y es más cómodo seguir empujando en la misma dirección. Cómo detectarlo: el escenario A de arriba, literal — ejecución de 9 o 10 sobre 10, y un resultado de negocio que no se mueve. Cómo corregirlo: antes de invertir en mejorar la ejecución de algo, haz la pregunta que cuesta menos y ahorra más: ¿estamos seguros de que esta es la estrategia correcta? Esa pregunta, hecha a tiempo, vale más que cualquier optimización de ejecución que venga después.

Creer que "más esfuerzo de ejecución" arregla un mal resultado. Qué pasa: al ver que un resultado no llega, la respuesta instintiva es apretar el acelerador de la ejecución — más horas, más gente, más velocidad — sin revisar nunca si el problema estaba en la estrategia, no en la ejecución. Por qué pasa: la ejecución es la palanca que el equipo controla de forma más directa e inmediata; la estrategia requiere un tipo de conversación distinta, más incómoda, con gente que quizás no está en la sala del día a día. Cómo detectarlo: usando el modelo, si estás en un escenario wrong, notarás que mover executionQuality de medium a great cambia el score de 6 a 10 — una mejora real, pero minúscula comparada con lo que se gana moviendo strategyQuality de wrong a right. Cómo corregirlo: antes de invertir más esfuerzo en ejecutar mejor, corre el cálculo (aunque sea mentalmente): ¿cuánto se gana mejorando la ejecución dentro de esta estrategia, contra cuánto se ganaría con la estrategia correcta y la misma ejecución de hoy? Casi siempre, la segunda pregunta tiene una respuesta mucho más grande.

Usar el modelo para justificar ejecución mediocre ("igual la estrategia es lo que importa"). Qué pasa: alguien lee esta lección y concluye que, si la estrategia es correcta, la calidad de la ejecución deja de importar — total, "el techo es alto". Por qué pasa: es una lectura parcial y cómoda del argumento, que ignora la mitad del modelo. Cómo detectarlo: el escenario C de arriba lo desmiente directamente — estrategia correcta con ejecución mala (score = 30) queda muy por debajo de estrategia correcta con ejecución apenas decente (score = 60), y todavía más lejos de estrategia correcta con ejecución perfecta (score = 100, calculable con los mismos datos). Cómo corregirlo: el modelo no dice "la ejecución no importa" — dice que la estrategia le pone un límite a cuánto puede lograr la ejecución, hacia arriba o hacia abajo. La estrategia correcta sin ejecución sigue siendo, con este modelo, apenas un poor. Ambas cosas hacen falta; lo que este modelo aísla es cuál de las dos, cuando falla, es más cara de arreglar después.

Ejercicios

Ejercicio 1 — Calcula el techo completo. Sin correr el código todavía, calcula outcomeOf({ strategyQuality: 'right', executionQuality: 'great' }) — el mejor caso posible del modelo. ¿Qué score y qué verdict esperas? Verifica corriéndolo.

Ver solución

strategyCeiling.right = 100, executionFactor.great = 1.0, entonces score = Math.round(100 * 1.0) = 100. Con score >= 70, el verdict es 'great'. Es, literalmente, el mejor resultado que el modelo puede producir — la estrategia correcta ejecutada a la perfección. Vale la pena notar la distancia completa entre este caso y el escenario A de la lección: 100 contra 10, una diferencia de 10 veces, y la única variable que cambió entre ambos fue strategyQuality, no executionQuality (que en los dos casos fue great). Esa comparación, más que ninguna otra, es la prueba numérica completa de esta lección: a ejecución igual, la estrategia es la que decide si el resultado es un éxito rotundo o un fracaso.

Ejercicio 2 — Encuentra el punto de cruce. ¿Existe alguna combinación de executionQuality para la estrategia wrong que supere al escenario C (right + poor, score 30)? Revisa los tres valores posibles de executionFactor y decide sin correr el código primero.

Ver solución

No. Con strategyCeiling.wrong = 10, el score máximo posible bajo wrong es 10 × 1.0 = 10 (con la mejor ejecución posible, great). Ese 10 sigue estando muy por debajo del 30 del escenario C, que ya era el peor caso de la estrategia correcta. En otras palabras: con estos pesos, ninguna ejecución, ni siquiera la perfecta, hace que la estrategia equivocada supere al peor caso posible de la estrategia correcta. Esa es una propiedad deliberada del modelo pedagógico, elegida para que el argumento de la lección quede imposible de esquivar con un caso borde — en el mundo real, con datos reales, la distancia probablemente sería menos extrema, pero la dirección del argumento (la estrategia pone un techo que la ejecución no cruza) se mantiene.

Ejercicio 3 — Argumenta con tus propios números. Imagina que un compañero te dice: "prefiero apostar todo a una ejecución perfecta; la estrategia ya la decidieron arriba, yo solo controlo cómo construyo". Usando los resultados de outcomeOf de esta lección, arma un argumento de 3-4 frases para convencerlo de que vale la pena, aun así, cuestionar la estrategia cuando algo no cuadra.

Ver solución

Un argumento posible: "Entiendo que tú controlas más directamente la ejecución que la estrategia, pero mira los números: con la estrategia equivocada, la mejor ejecución posible que podemos lograr —un 10 sobre 10, perfecta— nos da un score de apenas 10. Con la estrategia correcta, incluso una ejecución mediocre nos da 60, seis veces más. No te estoy pidiendo que dejes de ejecutar bien —seguimos necesitando eso—; te estoy pidiendo que, si algo en la estrategia no te cuadra, lo digas, porque el espacio de mejora ahí es mucho mayor que cualquier cosa que puedas ganar puliendo más la ejecución de una apuesta que ya está mal apuntada." El argumento funciona porque no le pide a tu compañero que abandone su rol de ejecutor —sigue siendo central—, sino que reconozca, con el número en la mano, dónde está la palanca más grande disponible.

Resumen y siguiente paso

En esta lección construiste outcomeOf y confirmaste, con números y no con intuición, la tesis central del módulo: la ejecución no rescata una estrategia equivocada. Viste que el modelo multiplica, en vez de promediar, porque en el mundo real una mala estrategia no resta puntos — les pone un techo casi al piso, sin importar cuánto brille la ejecución por debajo de ese techo. Y viste, con el escenario B, algo contraintuitivo pero real: la estrategia correcta, incluso mal ejecutada, casi siempre supera a la ejecución perfecta de la estrategia equivocada.

Antes de avanzar deberías poder: explicar por qué el modelo multiplica los dos ejes en vez de sumarlos o promediarlos; calcular de memoria el score de cualquier combinación de strategyQuality y executionQuality; y usar el resultado del escenario B como argumento concreto frente a la objeción "prefiero apostar todo a la ejecución".

La lección 5 da un paso atrás y ordena todo el vocabulario que llevas acumulado —táctica, estrategia, y dos términos nuevos, visión y ejecución— en cuatro capas claras, con un mapa de a qué guía o módulo pertenece cada una. Es la lección que te va a dejar, de una vez, sin confundir nunca más "esto es una pregunta de estrategia" con "esto es una pregunta de visión" o "esto es táctica de product-thinking".

Recursos

• Richard Rumelt, Good Strategy Bad Strategy: The Difference and Why It Matters — penguinrandomhouse.com/books/208668. El libro completo desarrolla, con estudios de caso reales, por qué una ejecución brillante nunca sustituye a un buen diagnóstico. En inglés.
• Marty Cagan (Silicon Valley Product Group), "Product Strategy" — svpg.com/product-strategy-overview. Cagan argumenta, desde el lado de producto de software, por qué la falta de estrategia —no la falta de esfuerzo de ejecución— es la causa más común de que los equipos no logren resultados. En inglés.