The cost of flawlessly executing the wrong strategy

Description

You already have both pieces: you can tell tactics from strategy (lesson 2), and you can recognize a real strategy versus a bad strategy (lesson 3). This lesson brings them together into a single question, the most uncomfortable one in the module: how much is perfect execution worth, in real outcome — if the underlying strategy was the wrong one?

Most people's intuitive answer is "it must be worth something" — that brilliant execution, even in the wrong direction, at least softens the blow. The answer this lesson is going to demonstrate, with an executed model, is harsher: the outcome depends on both axes at once, and a wrong strategy puts a ceiling nearly on the floor over the best possible outcome, no matter how perfect the execution is below that ceiling. A correct strategy, even with barely decent execution, can far outperform the perfect execution of the wrong strategy. This isn't a motivational opinion — it's, literally, what you're about to see come out of a calculation.

Connection to the module. This is the lesson where lessons 2 and 3 intersect over numbers. You're going to build outcomeOf, the module's second executed model, and run it against three Mercado scenarios that pick up directly from the offsite sentences you already classified in lesson 3. The same model will reappear, with new scenarios, in the lesson 8 project.

An analogy: two runners, two different races

Imagine two runners training for a marathon. The first prepares for the race that actually runs on Sunday — a flat 42-kilometer urban circuit. He trains with reasonable discipline: runs almost every day, though he sometimes skips a session, and his pace isn't spectacular. The second trains with extraordinary discipline and technique — perfect nutrition, every session timed to the second, the best physical preparation money can buy — but for a different race: a 100-kilometer mountain ultramarathon that he mistakenly believes is the one running on Sunday.

Sunday arrives, and the real race is the 42-kilometer urban one. The first runner finishes it, with a mediocre time but he finishes, exactly the race that needed running. The second — with all his superior preparation — shows up confused at the wrong starting line, with a body trained to endure a hundred kilometers of mountain terrain on a circuit that doesn't exist that day. His preparation was objectively better. His result in the actual race is, however, worse: he doesn't even run the race that mattered. The quality of the training — the execution — bought nothing, because it was applied to the wrong race. That is, exactly, what outcomeOf is about to put into numbers.

Worked example: outcomeOf on three Mercado bets

Let's build a simple scoring model. The central idea: strategy sets a ceiling on the possible outcome — a very high ceiling if the strategy is correct, a very low ceiling if it's not. Execution decides how close you get to the ceiling, but it can never cross it. The weights are illustrative, chosen so the pattern shows clearly — they aren't a real business formula, and we're stating that on purpose.

// outcomeOf({ strategyQuality, executionQuality }): pedagogical scoring model.
// Strategy sets a CEILING on the possible outcome; execution decides how close
// you get to that ceiling. A 'wrong' strategy has a ceiling near the floor --
// no execution, however perfect, crosses it. Illustrative weights, not a real
// business formula.
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 builds a generic giant-style search engine, executed flawlessly',
    strategyQuality: 'wrong',
    executionQuality: 'great',
  },
  {
    label: 'B. Mercado invests in curation + local sellers, execution barely decent',
    strategyQuality: 'right',
    executionQuality: 'medium',
  },
  {
    label: 'C. Mercado invests in curation + local sellers, but execution is poor',
    strategyQuality: 'right',
    executionQuality: 'poor',
  },
];

console.log('=== outcomeOf: execution does not rescue the wrong strategy ===\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('Key comparison: B (' + B.score + ', right strategy, barely decent execution) ' +
  (B.score > A.score ? 'BEATS' : 'does NOT beat') +
  ' A (' + A.score + ', wrong strategy, perfect execution).');

What to expect. Running the file with Node, the output is exactly this:

=== outcomeOf: execution does not rescue the wrong strategy ===

A. Mercado builds a generic giant-style search engine, executed flawlessly
  strategy=wrong, execution=great => score=10, verdict=failing

B. Mercado invests in curation + local sellers, execution barely decent
  strategy=right, execution=medium => score=60, verdict=moderate

C. Mercado invests in curation + local sellers, but execution is poor
  strategy=right, execution=poor => score=30, verdict=poor

Key comparison: B (60, right strategy, barely decent execution) BEATS A (10, wrong strategy, perfect execution).

Read the three scenarios carefully, because each one proves something different. Scenario A is Ana climbing Cerro Torre with a nine-out-of-ten technique: the best possible execution (great), applied to the wrong strategy (competing head-on against the generic giant on its own turf, something lesson 5 and the whole of module 5 are going to show is nearly impossible to win). The result: score = 10, verdict = 'failing'. That's not a mediocre outcome — it's a failure, despite flawless execution. Scenario B is the right strategy (curation + local sellers, the one that passed the isRealStrategy test in lesson 3) with barely decent execution, with mistakes, far from perfect. The result: score = 60, verdict = 'moderate' — nothing spectacular, but six times better than scenario A. Scenario C confirms that the right strategy isn't a guarantee on its own either: with poor execution, even the right strategy drops to score = 30. A correct strategy doesn't mean execution stops mattering — it means the ceiling that execution can aspire to is far higher.

The final comparison line says it bluntly: B beats A by 50 points, even though B's execution is only "decent" and A's is "perfect." That's this lesson's entire argument, turned into a number you can recalculate yourself by changing the input data.

Why strategy works as a ceiling, not as an average

It's worth pausing on the model's mathematical shape, because it isn't arbitrary: score = strategyCeiling × executionFactor is a multiplication, not a sum. If the model averaged the two axes instead of multiplying them, a perfect execution (100 on a 0–100 scale) could offset a good chunk of a bad strategy (10 on that same scale): the average of 100 and 10 is 55, not a terrible result at all. But that's not what happens in the real world, and that's why the model multiplies: a wrong strategy doesn't subtract points, it multiplies them by nearly zero. No matter how high executionFactor is — up to 1.0, the maximum possible — 10 × 1.0 is still just 10. Strategy isn't one more ingredient averaged with the rest: it's the structural ceiling that determines whether the rest of the ingredients have anywhere to land.

This also explains why scenario C (right + poor = 30) still beats, if barely, any possible execution of the wrong scenario: the ceiling of 100 with the worst execution (0.3) still yields 30, while the ceiling of 10 with the best execution (1.0) yields only 10. The right strategy, even poorly executed, will almost always beat the wrong strategy, no matter how well it's executed — because the range of possible outcomes for a correct strategy starts well above the entire ceiling of a wrong strategy. This property — that the worst case of a good strategy can beat the best case of a bad one — is the concrete, not rhetorical, reason this entire guide insists on resolving the strategy question before investing in execution.

Common mistakes

Executing flawlessly without asking if it's the right mountain. What happens: a team pours all its energy into the quality of execution — code, speed, polish — and assumes the underlying choice was already settled or that it's not worth questioning halfway through. Why it happens: questioning the strategy midway through a project feels like admitting time was wasted, and it's more comfortable to keep pushing in the same direction. How to spot it: scenario A above, literally — execution of 9 or 10 out of 10, and a business outcome that doesn't move. How to fix it: before investing in improving the execution of something, ask the question that costs less and saves more: are we sure this is the right strategy? That question, asked in time, is worth more than any execution optimization that comes after.

Believing "more execution effort" fixes a bad outcome. What happens: seeing that a result isn't landing, the instinctive response is to push harder on execution — more hours, more people, more speed — without ever checking whether the problem was in the strategy, not the execution. Why it happens: execution is the lever the team controls most directly and immediately; strategy requires a different, more uncomfortable kind of conversation, with people who might not be in the room day to day. How to spot it: using the model, if you're in a wrong scenario, you'll notice that moving executionQuality from medium to great changes the score from 6 to 10 — a real improvement, but tiny compared to what's gained by moving strategyQuality from wrong to right. How to fix it: before investing more effort into executing better, run the calculation (even mentally): how much do you gain by improving execution within this strategy, versus how much would you gain with the right strategy and today's same execution? Almost always, the second question has a much bigger answer.

Using the model to justify mediocre execution ("strategy is what matters anyway"). What happens: someone reads this lesson and concludes that, if the strategy is right, execution quality stops mattering — after all, "the ceiling is high." Why it happens: it's a partial, comfortable reading of the argument that ignores half the model. How to spot it: scenario C above directly disproves it — right strategy with poor execution (score = 30) lands well below right strategy with barely decent execution (score = 60), and even further below right strategy with perfect execution (score = 100, computable with the same data). How to fix it: the model doesn't say "execution doesn't matter" — it says strategy sets a limit on how much execution can achieve, both upward and downward. The right strategy without execution is still, by this model, barely a poor. Both are needed; what this model isolates is which of the two, when it fails, is more expensive to fix later.

Exercises

Exercise 1 — Calculate the full ceiling. Without running the code yet, calculate outcomeOf({ strategyQuality: 'right', executionQuality: 'great' }) — the model's best possible case. What score and verdict do you expect? Verify by running it.

See solution

strategyCeiling.right = 100, executionFactor.great = 1.0, so score = Math.round(100 * 1.0) = 100. With score >= 70, the verdict is 'great'. This is, literally, the best result the model can produce — the right strategy executed flawlessly. It's worth noting the full gap between this case and scenario A from the lesson: 100 versus 10, a 10x difference, and the only variable that changed between the two was strategyQuality, not executionQuality (which was great in both cases). That comparison, more than any other, is this lesson's complete numeric proof: with execution held equal, strategy is what decides whether the outcome is a resounding success or a failure.

Exercise 2 — Find the crossover point. Is there any executionQuality combination for the wrong strategy that beats scenario C (right + poor, score 30)? Check the three possible executionFactor values and decide before running the code.

See solution

No. With strategyCeiling.wrong = 10, the maximum possible score under wrong is 10 × 1.0 = 10 (with the best possible execution, great). That 10 is still well below the 30 of scenario C, which was already the worst case of the right strategy. In other words: with these weights, no execution, not even perfect execution, makes the wrong strategy beat the worst possible case of the right strategy. That's a deliberate property of the pedagogical model, chosen so the lesson's argument can't be dodged with an edge case — in the real world, with real data, the gap would probably be less extreme, but the direction of the argument (strategy sets a ceiling that execution doesn't cross) holds.

Exercise 3 — Argue with your own numbers. Imagine a coworker tells you: "I'd rather bet everything on perfect execution; the strategy was already decided above me, I only control how I build." Using this lesson's outcomeOf results, build a 3-4 sentence argument to convince them it's still worth questioning the strategy when something doesn't add up.

See solution

One possible argument: "I get that you control execution more directly than strategy, but look at the numbers: with the wrong strategy, the best execution we could possibly achieve — a perfect 10 out of 10 — gives us a score of just 10. With the right strategy, even mediocre execution gives us 60, six times more. I'm not asking you to stop executing well — we still need that — I'm asking that, if something about the strategy doesn't add up to you, you say so, because the room for improvement there is far bigger than anything you could gain by further polishing the execution of a bet that's already aimed wrong." The argument works because it doesn't ask your coworker to abandon their role as executor — that's still central — but to recognize, number in hand, where the bigger lever actually is.

Summary and next step

In this lesson you built outcomeOf and confirmed, with numbers rather than intuition, the module's central thesis: execution doesn't rescue a wrong strategy. You saw that the model multiplies, instead of averaging, because in the real world a bad strategy doesn't subtract points — it puts a ceiling near the floor over the outcome, no matter how much the execution shines below that ceiling. And you saw, with scenario B, something counterintuitive but real: the right strategy, even poorly executed, almost always beats the perfect execution of the wrong strategy.

Before moving on you should be able to: explain why the model multiplies the two axes instead of adding or averaging them; calculate from memory the score for any combination of strategyQuality and executionQuality; and use scenario B's result as a concrete argument against the objection "I'd rather bet everything on execution."

Lesson 5 steps back and organizes the whole vocabulary you've accumulated — tactics, strategy, and two new terms, vision and execution — into four clear layers, with a map of which guide or module each one belongs to. It's the lesson that will leave you, once and for all, never confusing "this is a strategy question" with "this is a vision question" or "this is product-thinking tactics" again.

Resources

• Richard Rumelt, Good Strategy Bad Strategy: The Difference and Why It Matters — penguinrandomhouse.com/books/208668. The full book develops, with real case studies, why brilliant execution never substitutes for a good diagnosis. In English.
• Marty Cagan (Silicon Valley Product Group), "Product Strategy" — svpg.com/product-strategy-overview. Cagan argues, from the software product side, why the lack of strategy — not the lack of execution effort — is the most common reason teams fail to deliver results. In English.