Module 1: Why Engineers Need Strategy

Guide overview: from what feature to build to what game we're playing and how we win

Why this guide exists

If you're coming from product-thinking-for-engineers-guide, you already know how to tell an output from an outcome, prioritize a backlog with RICE, size a bet before building it, and cut it down to the right MVP. That's a real arsenal, and with it you can answer the question "of these ten things we could build, which one first, and how big?" with judgment, not with the opinion of whoever shouts loudest in the meeting.

But notice something: that whole question — prioritize, size, cut down — assumes a list of ten reasonable things to choose from already exists. Nobody asked, before building that list, whether those ten things were even the right ones to start with. Product-thinking teaches you to play a game well. This guide teaches you to ask, before you play, what game this is, and how it's won.

That question — what game we're playing and how we win — is what the business world calls strategy, and most engineers treat it as someone else's problem: a VP of Product's job, a founder's job, something for people with a different title. That's an expensive mistake, and it's exactly the mistake this entire guide exists to correct. A team can prioritize beautifully, size with a surgeon's precision, and execute every sprint without a single bug — and still discover, at the end of the year, that it won the wrong race. Prioritizing better doesn't fix that. Prioritizing better just gets you faster to a place you didn't want to be.

The promise of this guide, in one sentence, is this:

From "what feature do I build" to "what game are we playing and how do we win".

"What feature do I build" is a tactical question: it assumes the game, and optimizes within it. "What game are we playing and how do we win" is a strategic question: it chooses the game, before anyone starts playing it. This entire guide — its eight modules — is the process of answering that second question with rigor, not corporate-retreat inspiration.

Where this guide sits. It builds directly on product-thinking-for-engineers-guide, which is its prerequisite. The relationship between the two is exact: strategy chooses the game; product thinking plays it. In module 7 of this guide, you'll use the same Mercado backlog you already know from the product-thinking guide — fasterCheckout, recommendations, sellerTools, reviews, improvedSearch — but this time not to prioritize it with RICE, but to filter it first: which of those bets even belong to the game Mercado decided to play? An item with the highest RICE score in the backlog might not serve the strategy at all, and in that case, no matter how high it scores: it doesn't make the cut. That's the exact relationship between the two guides, and you'll see it in code, not just in prose, once you get there.

The case that runs through the guide: Mercado's product strategy

The whole guide uses the same case you already know if you came from Fullstack or from product-thinking: Mercado, the marketplace. But here we look at it from a different angle — and in a sense, a prior one to all the others: what, exactly, is Mercado's strategy?

Over the eight modules you'll build that strategy piece by piece, with the same rigor that product-thinking used to build its prioritized backlog:

Mercado's vision: where it's headed, and why (module 2).
Its target segment and its positioning: who this is for — and who it's for — and what Mercado is in that buyer's mind against the alternatives (module 3).
Its differentiation: what makes it different, and better, for that specific segment, not for everyone (module 4).
The competitive landscape: who Mercado really competes against, and where the market is headed (module 5).
Its moats: what advantage, if built well, can't be copied in a weekend (module 6).
And, finally, how that whole strategy becomes a filter over the backlog you already know, deciding what makes the roadmap and what gets cut, regardless of its RICE score (module 7).

This module 1 doesn't build any of those pieces yet — modules 2 through 7 do that. What it installs is the judgment to recognize a real strategy when you see one, and to unmask one that isn't, no matter how confident it sounds on the whiteboard. Without that judgment, modules 2 through 7 risk producing, with a lot of effort, five slides as empty as the ones from the offsite above. With it, every piece you build from here on can pass the same test.

An analogy: the perfect suitcase for the wrong destination

Imagine you prepare for a trip with absolute discipline: you research the weather, choose the exact clothes for each day, pack every item in the optimal order so nothing wrinkles, calculate the exact weight to avoid an overweight fee, and arrive at the airport two hours early. Every decision, taken in isolation, is flawless. The problem shows up when you board the plane: you booked the flight to the wrong city. None of the perfect decisions you made while packing has any way of fixing that. You're going to land exactly where you didn't want to be, with the best-packed suitcase of your life.

That is, in miniature, the relationship between tactics and strategy this entire guide is going to develop. Packing well, arriving on time, choosing the right clothes for the weather: that's tactics — excellent execution within an already-decided plan. Choosing the right city: that's strategy — the prior choice, the one that determines whether all that tactical excellence was worth anything. Nobody would say "I packed perfectly, so the trip was a success" if they landed in the wrong city. And yet, on a product team, that's exactly the argument used all the time: "we executed the quarter flawlessly" — without ever asking whether the whole quarter was aimed at the right destination.

Worked example: what came out of Mercado's latest strategy offsite

Mercado's leadership team — the founder, the VP of Product, and two senior engineers invited into the conversation, something that almost never happens and that this entire guide argues should happen more — met last month for their annual strategy offsite. By the end of the day, the whiteboard had five sentences, each presented as "our strategy for next year." Let's look at them exactly as they were written, without judging yet which one is a real strategy and which isn't — that evaluation comes in lesson 3, with a model that runs it with explicit judgment, not intuition.

// The 5 sentences, verbatim, exactly as they ended up on the whiteboard at the close of the offsite.
// We haven't evaluated them yet -- that is, literally, the question that opens the module.
const mercadoOffsite = [
  'We are going to be the leading marketplace in the region.',
  'This quarter we are going to grow GMV by 30%.',
  'We are going to focus on buyers who browse without knowing what they want, instead of competing for exact-SKU searches where the generic giant already wins.',
  'We want to offer the best shopping experience in the market.',
  'We are not going to build a better search engine than the generic giant; we invest that effort in human curation and trusted local sellers instead.',
];

console.log('=== What came out of Mercado\'s strategy offsite ===\n');
mercadoOffsite.forEach((s, i) => console.log((i + 1) + '. ' + s));
console.log('\nAll 5 sentences sound like "strategy". Open question: how many of these 5 are, actually, a strategy?');

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

=== What came out of Mercado's strategy offsite ===

1. We are going to be the leading marketplace in the region.
2. This quarter we are going to grow GMV by 30%.
3. We are going to focus on buyers who browse without knowing what they want, instead of competing for exact-SKU searches where the generic giant already wins.
4. We want to offer the best shopping experience in the market.
5. We are not going to build a better search engine than the generic giant; we invest that effort in human curation and trusted local sellers instead.

All 5 sentences sound like "strategy". Open question: how many of these 5 are, actually, a strategy?

Read them again, slowly. All five are written with confidence, all five use the word "we're going to," all five could appear, without surprising anyone, on the opening slide of any annual planning meeting. And yet — this is exactly what you'll be able to prove with code in lesson 3 — not all five are the same. Some are a real choice, with a real cost: they say what's being given up in exchange for what. Others are a wish dressed up as a sentence: they say where they'd like to end up, without ever saying how, or what they're sacrificing to get there. That difference — invisible on the whiteboard, where all five look equally serious — is, at bottom, everything this module 1 exists to teach you to see.

The map of the guide's 8 modules

This guide has eight modules. Each one builds a piece of Mercado's complete strategy, on top of what the previous one leaves behind:

#	Module	What it's about
1	Why an engineer needs strategy (you are here)	What a strategy IS, what it's NOT, and the cost of flawlessly executing the wrong one.
2	Vision and mission	Where Mercado is headed and why; how a clear vision says both NO and YES.
3	Segment and positioning	Who Mercado is for — and who it's NOT for; what Mercado is in that buyer's mind.
4	Differentiation and value proposition	What makes Mercado different, and better, for that specific segment.
5	Competition and market	Who Mercado really competes against, and where the playing field is headed.
6	Moats and defensibility	What advantage of Mercado's can't be copied in a weekend, and what can.
7	From strategy to roadmap	How the whole strategy filters the product-thinking backlog before RICE gets a say.
8	Project: Mercado's strategy	The capstone: define Mercado's complete strategy and apply it as a filter over its real backlog.

Notice the progression: this module 1 doesn't build any piece of Mercado's strategy yet — modules 2 through 7 do that. What it installs is the judgment to recognize a real strategy when you see one, and to unmask one that isn't, no matter how confident it sounds on the whiteboard. Without that judgment, modules 2 through 7 risk producing, with a lot of effort, five slides as empty as the ones from the offsite above. With it, every piece you build from here on can pass the same test.

The map of this module

Inside module 1, eight lessons build the idea step by step:

Lesson    Question it answers
────────  ──────────────────────────────────────────────────
L1        (this one) What is this guide, and what came out of Mercado's offsite?
L2        What's the difference between doing things right and doing the right things?
L3        What IS a strategy, precisely, and what is it NOT?
L4        How much does it cost to flawlessly execute the wrong strategy?
L5        How do vision, strategy, tactics, and execution relate to each other?
L6        Why is this an engineer's job, not just the founder's or the VP of Product's?
L7        How do I recognize a "bad strategy" that's well disguised?
L8        Project: audit Mercado's offsite and measure the cost of the wrong sentence

Lesson 2 opens with the oldest distinction of all — doing things right versus doing the right things — and anchors it in the mountain analogy you'll recognize for the rest of the module. Lesson 3 defines strategy with an engineer's precision: not a plan, not a list of objectives, not an inspirational vision, but a coherent set of choices about where to play and how to win. Lesson 4 puts a number on the cost of getting that choice wrong, with a model you'll run yourself. Lesson 5 organizes the whole vocabulary — vision, strategy, tactics, execution — into four layers, so you always know which one you're standing on and which guide or module each question belongs to. Lesson 6 answers the most common objection: "this is someone else's job, with a different title." Lesson 7 goes deeper into recognizing a fake strategy even when it's better disguised than the offsite's five sentences. And lesson 8, the mini-project, has you audit Mercado's entire offsite and measure, with the executed model, exactly how much it would cost Mercado to pursue the wrong sentence with flawless execution.

The boundary: what does NOT belong in this guide (or this module)

This guide has siblings in the Product Engineering ecosystem, and each one covers a different part of the cycle. Knowing the entry boundary saves you confusion later:

Prioritizing the backlog, sizing opportunities, MVP, bets, and risky assumptions is product-thinking-for-engineers-guide — this guide's prerequisite. The boundary is exact: product-thinking decides which bet first, within a game already defined; this guide decides what the game is, and filters which bets even belong to it.
Validating with users, interviewing, prototyping is product-discovery-and-prototyping-guide.
Measuring rigorously — funnels, cohorts, A/B testing is product-metrics-and-experimentation-guide.
Launching, iterating, rolling out is shipping-and-iterating-products-guide.
Building the system, the architecture, the code belongs to the Fullstack and Architecture ecosystems. This guide informs build-vs-buy and architecture decisions — you'll see a concrete example in lesson 6 — but doesn't teach you to build.
MBA-level business strategy — detailed financial modeling, mergers and acquisitions, advanced pricing, organizational design — is out of scope for any guide in this ecosystem: what's taught here is the product strategy an engineer needs to build the right thing at the system level, not a full graduate program.

Within this module 1 specifically: you're going to learn to recognize what is and isn't a strategy, and to reason about the cost of choosing wrong. You're not going to build any piece of Mercado's strategy yet — not its vision, not its positioning, not its moats — that starts in module 2 and stays with you the rest of the guide.

Common mistakes

Thinking this guide is "more prioritization". What happens: someone arrives expecting another round of RICE, opportunity sizing, or MVP, and is surprised that module 1 doesn't touch any of those topics. Why it happens: "deciding what to build" sounds, from the outside, like a single problem — and in most teams, in practice, it gets solved with a single tool (a prioritized backlog) without ever distinguishing the two separate questions underneath. How to spot it: if you finish this module 1 expecting a RICE tutorial, you haven't caught the difference yet. How to fix it: reread the boundary above. Product-thinking prioritizes within an already-chosen game; this guide chooses the game. They're different questions, at different moments, and confusing them is, literally, the mistake this entire guide exists to correct.

Thinking "strategy" is synonymous with "long-term plan". What happens: someone assumes it's enough to write a detailed document, with dates and twelve-month deliverables, to have a strategy. Why it happens: a long plan feels strategic — it has scope, it has a horizon, it fills many pages. How to spot it: the "strategic plan" has dates and feature names, but if you ask "and what are we NOT going to do, and why?", nobody has an answer. How to fix it: lesson 3 defines this precisely — a plan is a sequence of steps; a strategy is the choice, prior to any step, of which game to play. You can have a detailed plan for the wrong game.

Assuming this topic isn't for engineers. What happens: you read the module's title and decide, before opening the first lesson, that this is founder and VP-of-Product territory. Why it happens: the word "strategy" carries executive connotation, boardroom connotation, PowerPoint connotation — none of it sounds like a stand-up or a pull request. How to spot it: you feel like this module "doesn't apply to your real work." How to fix it: lesson 6 is entirely devoted to dismantling this idea with a worked example about decisions you make, not someone else — build-vs-buy, architecture, how far to take a technical solution. Brief spoiler: if you never ask whether what you're building serves the right game, you end up building, with all your technical skill intact, the perfect suitcase for the wrong destination.

Exercises

Exercise 1 — Locate the question. For each question, say whether this guide (strategy) or product-thinking-for-engineers-guide (tactics) answers it:

(a) "Should we prioritize one-click checkout or personalized recommendations this sprint?"
(b) "Is it worth competing for the buyer who knows exactly which SKU they want, or do we focus on the one who browses without knowing what they want?"
(c) "How big, in potential users, is the opportunity for a search bar with autocomplete?"
(d) "Which segment are we giving up in exchange for dominating the segment we did choose?"

See solution

(a) Tactics — product-thinking. It's a question of order within an already-defined backlog: which one first, using what criterion (RICE). It doesn't question whether those items belong to the right game.
(b) Strategy — this guide. It is, literally, a "where to play" choice: which segment you serve, and by implication, which one you give up. It's exactly the kind of sentence you'll learn to recognize in lesson 3.
(c) Tactics — product-thinking. It's sizing a specific opportunity within an already-assumed game; it doesn't ask whether that game is the right one.
(d) Strategy — this guide. The key word is "giving up": every real strategic choice has an explicit cost. You'll see this idea formalized, in code, in lesson 3.

The rule to orient yourself, for the rest of the guide: if the question chooses the game (where to play, how to win, what's given up), it's this guide. If the question plays the already-chosen game (what to build first, how big), it's product-thinking.

Exercise 2 — The suitcase and the destination. A coworker tells you: "our team had the best technical quarter in our history: zero incidents, record velocity, flawless code." Does that sentence, by itself, tell you anything about whether Mercado had a good strategic quarter? Justify your answer with the suitcase analogy.

See solution

No, by itself it says nothing about the strategic outcome — and that's exactly the trap this module opens with. "Zero incidents, record velocity, flawless code" is a perfect description of the suitcase: the tactical execution was excellent. It says absolutely nothing about the destination: whether that flawless quarter was spent building something that serves the game Mercado decided to play (or should have decided to play), or whether it was spent building, with total technical polish, something irrelevant to that game. To answer whether the quarter was good strategically, you need a different and prior question: was the chosen destination the right one? Lesson 4 will give you a worked model to calculate, with numbers, exactly how much flawless execution is worth (or costs), depending on whether the destination was right or not.

Exercise 3 — Prediction about the offsite. Without having read lesson 3 yet, look again at Mercado's 5 offsite sentences. Pick out which ones, in your judgment, are a real choice (with something given up) and which ones are just a wish. You don't need the formal criterion yet — you need the argument.

See solution

Without getting ahead of lesson 3's formal model, a reasoned read: sentences 1 ("leader in the region") and 4 ("the best shopping experience in the market") don't say what's given up to achieve them — any company, in any industry, could copy and paste those two sentences without changing a word, and that's a warning sign: a real strategy should sound a little strange, uncomfortable, specific to your situation, not interchangeable with a competitor's. Sentence 2 ("grow GMV by 30%") is a number, not a choice — it doesn't say how, and a goal without a how is not a strategy, it's a target. Sentences 3 and 5 do explicitly state something Mercado is giving up: in 3, competing for exact-SKU searches; in 5, building a better search engine than the generic giant. That explicit trade-off — saying NO to something reasonable, in exchange for something else — is, ahead of schedule, exactly the criterion lesson 3 is going to formalize in code and run against these same five sentences.

Summary and next step

In this lesson you installed the promise of the whole guide — from "what feature do I build" to "what game are we playing and how do we win" — and met the case that runs through it: Mercado's complete strategy, which you'll build piece by piece across modules 2 through 8. You saw the map of the eight modules and the eight lessons in this module, drew the boundary with product-thinking and with the other sibling guides in Product Engineering, and met the five sentences from Mercado's latest strategy offsite — without judging them yet.

Before moving on you should be able to: explain in one sentence the difference between this guide and product-thinking; roughly place which module of this guide answers which type of question; and describe in your own words the perfect-suitcase-for-the-wrong-destination analogy.

Lesson 2 opens the module's central distinction, the one that gives it its name: doing things right versus doing the right things. There you'll meet Ana and Luis, two climbers with very different techniques — and you'll see, executed, why one of the two reaches the summit that mattered to them and the other doesn't, with climbing technique having nothing to do with the answer.

Resources

Richard Rumelt, Good Strategy Bad Strategy: The Difference and Why It Matters — penguinrandomhouse.com/books/208668. The book that gives this module its backbone; the source of the "bad strategy" concept you'll use throughout the rest of the guide. In English.
Michael E. Porter, "What Is Strategy?" (Harvard Business Review, 1996) — hbr.org/1996/11/what-is-strategy. The classic article that opens the distinction between operational effectiveness (tactics) and strategic positioning. In English.
Marty Cagan (Silicon Valley Product Group), "Product Strategy" — svpg.com/product-strategy-overview. The same idea written for software product teams, with the Superhuman example. In English.

Next →Doing things right versus doing the right things