Doing things right versus doing the right things

Description

There's a distinction, old in the world of management, that's rarely taught with precision on an engineering team: doing things right (efficiency: executing with quality what you decided to do) is not the same as doing the right things (effectiveness: having decided well what to do, to begin with). You can have one without the other. A team can write flawless code, with sky-high test coverage, zero technical debt, and frictionless deploys — and be, with all that excellence, building something it shouldn't be building. That combination — tactical excellence on top of a wrong strategic choice — isn't a rare or hypothetical case: it's by far the most common and most expensive way to fail on a product team, precisely because it feels like success from the inside.

Connection to the module. This lesson opens the distinction that gives the entire module its name: tactics versus strategy. Everything that follows — what a strategy IS (lesson 3), its cost when chosen wrong (lesson 4), the four layers that organize it (lesson 5) — depends on this distinction being clear first. You're going to learn it through an analogy you'll recognize for the rest of the module: the mountain and the wall.

An analogy: the mountain and the wall

Imagine two climbers, on two different mountains, on the same day. Ana chooses "Cerro Torre" — one of the most technically demanding walls in the world, vertical ice, constant wind — and climbs it with extraordinary technique: every anchor perfect, every move calculated, zero errors in eight hours of ascent. Luis chooses "Aconcagua" and climbs with mediocre technique: clumsy steps, a couple of unnecessary stops, nothing elegant. At the end of the day, who "climbed better"? If the question is only about climbing technique — about how they climbed the wall in front of them — Ana wins without question.

But change the question. Suppose the real goal, the one that mattered before either of them started climbing, was reaching the summit of Aconcagua — that was the mountain someone needed conquered, for whatever reason. With that question in mind, Ana got nowhere that helped her: she climbed, with superb technique, the wrong mountain. Luis, with mediocre technique, got exactly where he needed to. Climbing technique — how you climb the wall in front of you — is tactics. Choosing which mountain to climb — which is the right wall — is strategy. And the uncomfortable lesson of this example is that climbing technique, however perfect, has no power whatsoever to fix a badly chosen mountain. Ana isn't "a little less successful" than Luis: in terms of the goal that actually mattered, she's exactly as far from the summit that mattered as if she hadn't climbed anything at all.

Translated to a product team: tactics is how you prioritize the backlog, how you size an opportunity, how you cut down to the right MVP, how you write the feature's code — everything product-thinking-for-engineers-guide teaches you to do well. Strategy is, before any of that, choosing which mountain: which segment you serve, who you really compete against, which bets even belong to the game you decided to play. A team that prioritizes flawlessly with RICE, measures every experiment rigorously, and deploys frictionlessly — but never asked whether the whole backlog was aimed at the right mountain — is Ana on the ice wall: perfect technique, wrong summit.

Worked example: Ana, Luis, and the summit that mattered

Let's model exactly this comparison with a minimal function, climbReport, that takes the mountain someone climbed, the mountain that actually mattered, and a technique score — and returns a verdict on exactly one thing: did you reach the summit that mattered to you?

// climbReport(): compares two climbers. Climbing technique (how you climb
// the wall) is tactics; which mountain you chose to climb is strategy. The
// report asks only one thing: did you reach THE summit that mattered to you?
function climbReport(name, mountain, targetSummit, techniqueScore) {
  const rightMountain = mountain === targetSummit;
  return name + ': climbed "' + mountain + '" with technique ' + techniqueScore + '/10 -- ' +
    (rightMountain
      ? 'reached the summit that mattered.'
      : 'reached the summit of ANOTHER mountain; their real summit remains untouched.');
}

console.log(climbReport('Ana', 'Cerro Torre', 'Aconcagua', 9));
console.log(climbReport('Luis', 'Aconcagua', 'Aconcagua', 5));

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

Ana: climbed "Cerro Torre" with technique 9/10 -- reached the summit of ANOTHER mountain; their real summit remains untouched.
Luis: climbed "Aconcagua" with technique 5/10 -- reached the summit that mattered.

Notice, carefully, what the report does not do: it never weighs techniqueScore to "compensate" for the wrong mountain. Ana's 9/10 isn't worth more, for the final verdict, than Luis's 5/10 on the right mountain — because, literally, there's no amount of technique that turns "Cerro Torre" into "Aconcagua". That's the central property of the relationship between strategy and tactics this entire module is going to develop: strategy decides whether technique counts for anything. It's not that Ana's technique never matters — on the right mountain, that same 9/10 technique would have gotten her there faster, safer, with more margin for error. What this example isolates is that, applied to the wrong mountain, not even the best technique in the world buys a single meter of distance toward the real summit.

From the mountain to Mercado: the same pattern, a different disguise

Ana's mistake rarely looks this obvious on a real product team, because nobody announces "we're going to climb the wrong mountain" out loud. Instead, it looks like this: the Mercado team decides, without an explicit strategic discussion in between, to spend the quarter building a search engine with its own custom ranking — a fascinating technical problem, with a lot to learn, that any strong engineer would enjoy solving. They execute it with excellent technique: clean architecture, solid benchmarks, measurably better search results than before. At the end of the quarter, the team is proud, rightly so, of the technical work. And yet, if the right choice for Mercado was to compete on curated discovery instead of search precision — a choice you'll see formalized in lesson 3, and that module 5 will show is nearly impossible to win head-on against the generic giant in pure search — then that entire quarter was Ana climbing Cerro Torre with a nine-out-of-ten technique: extraordinary, admirable, and strategically irrelevant to the summit Mercado needed to reach.

This isn't an argument against technical excellence — quite the opposite. It's an argument about where you aim that excellence. The same engineering skill that built the custom search engine, applied to the right problem — say, a reputation and trust system that makes discovering a local seller feel safe — would have been just as fascinating to build and, on top of that, would have moved Mercado toward the summit that actually mattered. The question in this module isn't "how well do you build?" — product-thinking answers that, and engineering itself even more so. The question is always the one that comes before: is this the right mountain?

Common mistakes

Measuring a quarter's success only by the technical quality of what shipped. What happens: a team reviews its quarter and reports "zero incidents, 95% test coverage, zero technical debt added" as evidence of a good quarter, without ever mentioning whether what was built pointed in the right direction. Why it happens: technical quality is easy to measure and pleasant to report; the question "was it the right mountain?" is uncomfortable, because sometimes the answer is no. How to spot it: in the quarterly retro, every metric mentioned is about how it was built, none about what was built and why. How to fix it: always add the prior question — before grading execution, ask whether the underlying choice was right. Lesson 4 gives you a model that combines both questions into a single number, so they stop being evaluated separately.

Believing "working faster" fixes a badly chosen mountain. What happens: noticing that a quarter didn't deliver the expected results, the reaction is to pick up the pace next quarter — more sprints, fewer meetings, deliver the same thing faster than before. Why it happens: speed feels like the lever you actually control, while questioning the underlying choice feels outside your lane. How to spot it: the following quarter delivers faster, with the same technical quality, and the business result still doesn't move. How to fix it: speed is a property of tactics — of how you climb the wall. If the mountain is still the wrong one, climbing it faster only gets you sooner to a place you didn't want. The question to ask isn't "how do we go faster?", it's "is this the mountain?"

Assuming "choosing the right mountain" is obvious and doesn't need discussing. What happens: the team jumps straight to prioritizing and building, assuming "obviously" everyone understands the strategic direction, without anyone having ever put it into explicit words or questioned it. Why it happens: questioning the underlying direction feels, on many teams, like questioning the authority of whoever set it — or nobody ever stopped to do it, because there's always something more urgent to build. How to spot it: if you ask three people on the team to describe, in one sentence, the mountain they're climbing, you get three different answers — or silence. How to fix it: the choice of mountain needs to be written down, explicit, and revisable, not assumed. That is, exactly, the work of module 2 onward: building that choice for Mercado, piece by piece, instead of taking it for granted.

Exercises

Exercise 1 — Tactics or strategy. For each Mercado decision, say whether it's a tactical decision (how to climb the wall) or a strategic one (which mountain to climb):

• (a) "We're going to use a microservices architecture for the new checkout."
• (b) "We're going to compete for buyers who browse, not for those searching an exact SKU."
• (c) "We're going to write the cart tests before writing the code (TDD)."
• (d) "We're going to build a data moat with purchase history, instead of competing on price."

Exercise 2 — Flip the outcome. Using climbReport, what would it print if Ana had climbed "Aconcagua" with technique 9 and Luis had climbed "Cerro Torre" with technique 5? Before running it, predict each verdict.

console.log(climbReport('Ana', 'Aconcagua', 'Aconcagua', 9));
console.log(climbReport('Luis', 'Cerro Torre', 'Aconcagua', 5));

Ana: climbed "Aconcagua" with technique 9/10 -- reached the summit that mattered.
Luis: climbed "Cerro Torre" with technique 5/10 -- reached the summit of ANOTHER mountain; their real summit remains untouched.

Exercise 3 — Find your own mountain. Think of a recent project — at work or personal — where you put in a lot of technical effort. Without judging it yet with the formal criterion (that comes in lesson 3), answer: before you started building, was it clear to you which was "the right mountain"? Had someone put it into explicit words, or did you take it for granted?

Summary and next step

In this lesson you installed the distinction that gives the module its name: doing things right (tactics, climbing technique) versus doing the right things (strategy, choice of mountain). With Ana and Luis, run through climbReport, you saw something uncomfortable and central: no amount of technique buys distance toward a summit other than the one you're climbing. And you saw how that same pattern, disguised, shows up on a real product team when technical excellence gets measured without ever asking whether it pointed in the right direction.

Before moving on you should be able to: explain the difference between tactics and strategy in your own words; recognize, in any team decision, whether it's about "how" or about "which game"; and describe why technique can't compensate for a badly chosen mountain.

Lesson 3 takes the mountain side — strategy — and defines it with an engineer's precision: what IS, exactly, a strategy? And what is it NOT, even when it sounds just as convincing? There you'll build isRealStrategy, the module's first executed model, and run it against the five sentences from Mercado's offsite you met in lesson 1.

Resources

• Richard Rumelt, Good Strategy Bad Strategy: The Difference and Why It Matters — penguinrandomhouse.com/books/208668. The source of the distinction that opens this module: executing well is not the same as executing the right thing. In English.
• Michael E. Porter, "What Is Strategy?" (Harvard Business Review, 1996) — hbr.org/1996/11/what-is-strategy. Porter opens the article, in almost the same words as this lesson, distinguishing "operational effectiveness" (doing things right) from "strategic positioning" (doing the right things). In English.