Why this is your job, not just the founder's or the VP of Product's

Description

You've made it this far with the full vocabulary: tactics, strategy, and the four layers that organize them. The objection that probably already crossed your mind, especially after lesson 5 — where strategy ended up placed two layers above your daily execution work — is reasonable: "this sounds like a founder's job, a VP of Product's job, someone with that specific title. I write code." This lesson exists to dismantle that objection with concrete arguments, not a motivational slogan about "thinking like an owner."

The short reason: you are, almost always, the person with the most technical context on whether a strategic bet is even viable to build well — and you're also the one making, every day, architecture and build-vs-buy decisions that either serve the strategy, or waste it on a technically beautiful but irrelevant problem. This isn't about you replacing whoever defines the formal strategy. It's about the question "does what I'm about to build serve the game we chose to play?" no longer feeling foreign to your job, because you are, often, the only person in the room able to notice in time when it doesn't.

Connection to the module. Lessons 2 through 5 gave you the full vocabulary and the numeric evidence (outcomeOf) for why strategy matters more than brilliant, badly-aimed execution. This lesson connects that vocabulary to your specific role as an engineer, with a worked example on build-vs-buy and architecture decisions — exactly the kind of decision you make, not the founder or the VP of Product.

An analogy: the bridge engineer and the route layout

A civil engineer doesn't usually decide where a new highway is going to run — that decision, about which cities to connect and why, is made by someone further up the chain, with information about traffic, regional economics, politics. But when the proposed route lands on their desk, the bridge engineer is the only person able to say: "that river, at that exact point, has a geology that makes a bridge there cost ten times the budget — or makes it flatly impossible with the technology available." That information doesn't live in the head of whoever laid out the route. It lives, exclusively, in the head of whoever understands bridges.

If the engineer stays quiet — because "it's not my job to decide the route, only to build what I'm asked to" — the entire project moves forward for miles on a plan that, technically, can't be executed as designed, and the mistake is discovered late, when it's already very expensive to fix. If the engineer speaks up in time, the route gets adjusted with the best information available, and everyone wins: whoever laid out the original route, and the whole project. That is, with total precision, your place relative to Mercado's strategy: you don't decide alone where the highway goes, but you're the one who can see, before anyone else, whether the bridge the strategy needs is viable, very expensive, or flatly impossible — and that information, if you keep it to yourself, nobody else has.

Worked example: the radar for your own technical bet

Before proposing a migration, a rewrite, or a build-vs-buy decision, an engineer can run it through a two-question radar: is it a technically interesting problem? and, the one almost nobody asks, does it serve the strategy? Let's model that radar with engineeringBetReport. Keep in mind something important: this is not yet the formal filter over the product's entire backlog — that's strategicFilter, which you'll build in module 7 — this is your own personal check, before proposing a technical idea of your own.

// engineeringBetReport({ name, technicallyInteresting, servesStrategy }): an
// engineer's personal radar for ANY technical idea of their own -- migrating
// something, rewriting something, building instead of buying. It's not the
// formal filter over the whole product backlog (that's strategicFilter,
// module 7); it's the question you ask yourself BEFORE proposing anything.
function engineeringBetReport({ name, technicallyInteresting, servesStrategy }) {
  let verdict;
  if (servesStrategy && technicallyInteresting) verdict = 'build it -- serves the strategy and is also a good problem';
  else if (servesStrategy && !technicallyInteresting) verdict = 'build it anyway -- boring, but serves the strategy';
  else if (!servesStrategy && technicallyInteresting) verdict = 'careful -- tempting, but does not serve the strategy; probably NOT';
  else verdict = 'do not build it -- neither interesting nor strategic';
  return name + ': ' + verdict;
}

const candidates = [
  { name: 'Migrate search to an in-house engine with custom ranking', technicallyInteresting: true, servesStrategy: false },
  { name: 'Reputation and trust system for local sellers', technicallyInteresting: false, servesStrategy: true },
  { name: 'Recommendations pipeline with embeddings + ANN', technicallyInteresting: true, servesStrategy: true },
];

candidates.forEach((c) => console.log(engineeringBetReport(c)));

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

Migrate search to an in-house engine with custom ranking: careful -- tempting, but does not serve the strategy; probably NOT
Reputation and trust system for local sellers: build it anyway -- boring, but serves the strategy
Recommendations pipeline with embeddings + ANN: build it -- serves the strategy and is also a good problem

Look closely at the first case, because it's the most dangerous of the three, and not by accident. "Migrate search to an in-house engine with custom ranking" is, for almost any strong engineer, a fascinating problem: there are algorithms involved, there are benchmarks to optimize, there's a real sense of solving something hard. And yet, if Mercado's strategy — the one you watched take shape in lesson 3 — is to compete on human curation and not on search precision, this bet is exactly Ana climbing Cerro Torre with brilliant technique: a beautiful problem, badly aimed. The radar flags "careful," not "never" — because sometimes the right answer really is to build it, if the full strategic analysis justifies it — but the warning signal exists precisely to force the question before you start coding, not after.

The second case matters just as much in the opposite direction: "reputation and trust system for local sellers" isn't, for most engineers, as seductive a problem as a search engine with custom ranking — it's, in large part, forms, validations, moderation, work that feels less "interesting" in the traditional technical sense. But it directly serves the curation-and-local-trust strategy. The radar says "build it anyway," and that is, often, the bet an engineer in love with the technically flashy overlooks — not because it's bad, but because it doesn't shine.

Build vs. buy: the decision where your judgment matters more than anywhere else

There's a specific type of decision where your technical context is, literally, irreplaceable: build-vs-buy — do we build this piece ourselves, or buy/integrate an existing solution? This decision looks, at first glance, purely technical (do we have the capacity? how much does maintenance cost?), but it's actually a decision that should be filtered by strategy, and you're the one with the information on both sides to get it right.

Consider the case of a payments system for Mercado. Building it from scratch is a serious technical problem: regulatory compliance, security, accounting reconciliation, availability. An engineer could, with good reason, find it fascinating to build. But if payments isn't part of Mercado's differentiating strategy — if Mercado's strategic choice is to compete on curation and trust, not on payments infrastructure — then building a proprietary payments system is top-tier engineering effort invested in a problem where winning doesn't move any strategic needle: any existing payments provider solves the problem equally well for the buyer, and the engineering time spent reinventing it is time not spent on the seller reputation system, which is genuinely differentiating. The right decision, almost always, is to buy (integrate a provider) for the pieces that aren't part of "how we win," and build for the pieces that are. That distinction — is this piece part of our strategic advantage, or is it a utility anyone can buy just as well? — is exactly the question you'll see formalized, at the whole-backlog level, in module 7. Here, at the level of a single technical decision, you can already apply it yourself, today, without waiting for that module.

Common mistakes

Waiting for someone "from product" to bring the strategic question. What happens: an engineer is given the freedom to propose a technical improvement — a migration, a rewrite, a new piece of infrastructure — and proposes it based on technical judgment alone, never asking whether it serves the strategy, assuming that if it were a problem, someone else would have already asked. Why it happens: questioning the strategic fit of your own proposal sometimes feels like stepping outside your assigned technical lane. How to spot it: you can justify a technical proposal with architecture, performance, or maintainability arguments, but you can't say, with the same ease, which strategic choice it serves. How to fix it: use this lesson's radar before proposing, not after. The question "does this serve the strategy?" is a legitimate technical question about the return on your own effort, not an intrusion into someone else's job.

Falling in love with the technically beautiful and ignoring whether it matters strategically. What happens: a technical bet gains momentum of its own — it generates excitement on the team, attracts the most senior engineers, becomes the "cool" project of the quarter — without anyone stopping to ask whether it moves anything strategic. Why it happens: technically elegant problems generate their own social momentum: people want to work on them, talk about them, show them off. How to spot it: it's, literally, the first case executed above — "careful, tempting, but does not serve the strategy." If you notice the main reason to build something is "it would be an interesting project" and not "this serves the choice we made about where to play and how to win," the alarm should go off. How to fix it: consciously separate the radar's two questions — is it interesting? and does it serve the strategy? — and require the second one to have a "yes" before letting the first one decide.

Believing "more features" is, by itself, a strategy. What happens: the default answer to "how do we compete better?" becomes "let's add more functionality" — more options, more screens, more settings — without any of those additions being connected to a specific choice of where to play and how to win. Why it happens: building new things is what an engineering team knows how to do best, and "let's do more" feels like tangible progress, while "let's choose better what NOT to do" produces nothing you can show in a demo. How to spot it: if the answer to "what's our strategy?" is a list of planned features, with no sentence naming what's given up, you're facing the same mistake as lesson 3 — confusing a list of aspirations with a choice — this time applied to a full technical roadmap instead of a single offsite sentence. How to fix it: remember isRealStrategy's criterion — a real strategy says both what to build and what not to build, and why. "More features" is never a complete answer; it always needs the question that accompanies it: more features of what kind, for whom, sacrificing what?

Exercises

Exercise 1 — Run the radar on your own idea. Think of a technical improvement you've recently proposed or considered — a migration, a refactor, a new internal tool. Fill it into engineeringBetReport's format: was it technically interesting? Did it serve an explicit strategic choice (or, if there wasn't an explicit strategy, the product's general direction)? What verdict does the radar give you?

See solution

There's no single answer — the exercise is personal — but the useful reflection pattern is this: if your proposal falls into the "careful, tempting but does not serve the strategy" quadrant, it's worth honestly asking yourself how much of the energy you put into it came from it being a genuinely strategic problem versus how much came from it simply being a fun problem to solve. Neither motivation is shameful — we're all drawn to elegant problems — but only one of them should decide whether the effort gets invested ahead of other alternatives.

Exercise 2 — Build vs. buy with judgment. Mercado needs a push notification system (notifying a buyer when the price drops on something on their wishlist). An engineer proposes building it from scratch, "so we fully control the infrastructure." Using this lesson's build-vs-buy distinction, what questions would you ask before approving that decision?

See solution

The central question: is the notification system itself part of Mercado's strategic advantage, or is it a utility any external provider solves just as well? If Mercado's strategy — as it's been taking shape in the previous lessons — revolves around curation and local trust, a generic push notification system (the price of X dropped) isn't, by itself, differentiating: a specialized external service probably solves it with the same quality, faster, and with less future maintenance for Mercado's team. Concrete questions to ask: is there already a reliable provider that solves this with good integration? Does the "full infrastructure control" that building it in-house offers serve any specific strategic choice, or is it a general technical preference? Could the engineering time it would cost to build it from scratch instead be invested in something that is part of Mercado's differentiation, like the seller reputation system? If nobody can answer the first question with a "yes, it's strategic because...," the default decision should lean toward buying or integrating, not building.

Exercise 3 — The ambiguous case. A coworker argues: "Mercado's internal data and analytics infrastructure isn't part of the customer-facing strategy, so by your criterion we should buy all of it." Do you agree? What nuance would you add, considering that in module 6 of this guide you're going to see that data can, itself, be a moat?

See solution

Not entirely — the argument has a part that's true and a part it misses. It's true that data and analytics infrastructure isn't, itself, something the buyer sees or directly experiences — unlike the seller reputation system, it isn't "customer-facing" in the sense of a screen or a flow. But the important nuance, which module 6 will develop with moatScore, is that there's a huge difference between generic analytics infrastructure (dashboards, standard reports, something any commercial tool solves just as well — there, buying does make sense) and Mercado's own data accumulated on purchase behavior, discovery patterns, and trust between buyers and local sellers — that data, and what gets built on top of it (better recommendations, better fraud detection, better automatic curation), is exactly the kind of advantage a competitor can't buy or copy in a weekend, because it doesn't exist outside the platform's own accumulated activity. The right distinction isn't "customer-facing yes, infrastructure no" — it's "is this piece replaceable by any external provider, or is it where an advantage lives that only Mercado can have from having operated long enough?" The first gets bought. The second, even if the end buyer never sees it, is well worth building in-house — and that is, ahead of schedule, module 6's entire argument.

Summary and next step

In this lesson you dismantled the objection that strategy "isn't your job": with the bridge engineer, you saw that you have technical information nobody else in the room has, and that staying quiet about it — not out of bad intent, but from assuming "it's not my place" — lets costly mistakes slip through until it's too late to fix them cheaply. With engineeringBetReport run on three Mercado technical bets, you saw the two-question radar — is it interesting? does it serve the strategy? — and noticed the most dangerous of the three cases: the technically fascinating bet that, without that radar, gets built anyway, even though it serves nothing strategic. And you saw, with the payments example, how build-vs-buy is exactly the kind of decision where your technical judgment, crossed with the strategy, decides whether engineering effort gets invested where it actually matters.

Before moving on you should be able to: give at least two concrete reasons why strategy is also your responsibility as an engineer; apply the two-question radar to any technical proposal, yours or someone else's; and explain, with the payments example, why build-vs-buy should be filtered by strategy and not just technical capacity.

Lesson 7 returns to lesson 3's isRealStrategy model and puts it to the test on harder cases: sentences that sound sophisticated but choose nothing (what Rumelt calls fluff), lists of objectives disguised as strategy, and — most importantly — a case where the model itself gets fooled, so you learn not to trust it blindly.

Resources

• Richard Rumelt, Good Strategy Bad Strategy: The Difference and Why It Matters — penguinrandomhouse.com/books/208668. The book devotes an entire chapter to why "more features" or "more options" isn't a strategy without a real choice behind it. In English.
• Marty Cagan (Silicon Valley Product Group), "Product Strategy" — svpg.com/product-strategy-overview. Cagan argues specifically for why product strategy requires the technical judgment of whoever builds, not just whoever plans. In English.