Module overview: the capstone — Mercado's product strategy

Why this module exists here

You've reached the end of seven modules that, each, built one piece. Module 2 gave you Mercado's vision — where it's going, and what it explicitly rules out. Module 3 chose the segment —buyers who browse, not the ones searching for an exact SKU— and the positioning against the alternatives, verified with positionFit. Module 4 found the real differentiation, separated from parity, with differentiationMap. Module 5 mapped the complete competitive landscape —direct, indirect, and the biggest substitute of all— and projected it three years forward. Module 6 audited what of all that is, in truth, a moat, with moatScore, and found the guide's most uncomfortable finding: the differentiation module 4 celebrated still isn't protected. Module 7 built the strategic filter, strategicFilter, which decides which backlog bets belong to the game before anyone cares about their riceScore.

Seven pieces, seven modules, each correct on its own. And yet, up to this point, you never saw them work together, in a single run, on the same case. This module closes that gap: you're going to build Mercado's strategy one-pager — a single document, verified with code from start to finish — and you're going to run, for the first time, the complete pipeline: positionFit → differentiationMap → moatScore → strategicFilter, chained together, each feeding the next, on the same real datasets you used in modules 3, 4, 6, and 7. There are no new concepts in this module — there is, for the first time, a single run that cuts across all of them.

Connection to module 7. Module 7 left you with a correct roadmap: reviews > sellerTools > recommendations, filtered against a strategy you declared by hand (winOn: ['curatedDiscovery', 'sellerTrust'], avoid: ['price']). This module doesn't repeat that result — it derives it. Instead of writing winOn and avoid as an act of faith, this module's pipeline calculates them from what differentiationMap and the vision already proved, and then crosses the filter's result against module 6's moat audit. The final number is the same. The difference is that, this time, you can trace every piece of that strategy back to the exact model that produced it — and you're going to discover something no earlier module, by itself, could show you.

An everyday analogy: the architect's final report, not seven separate memos

An architect designing a building doesn't hand the client seven separate memos —one about the land, another about materials, another about structure, another about budget. During the project, yes, each specialist worked their piece separately: the soil engineer measured the ground's resistance, the structural engineer calculated the loads, the cost engineer ran the budget. But on delivery day, the architect presents a single document: the final blueprints, where every design decision traces back to the technical report that justifies it — this column is this thick because the soil engineer found such-and-such resistance, this material was chosen because the budget allowed it without sacrificing the structure. A final blueprint that only showed the result, without the chain of whys, wouldn't be able to defend a single decision to a skeptical client or an inspector who asks "and why is this like this?"

This module is exactly that final report. You're not going to audit the land again (module 2, the vision, already did that), or recalculate the structure from scratch (module 6, the moats, already did that) — you're going to assemble the document that connects each piece to the next, so anyone reading it can ask "why is the final roadmap this one?" and find the complete answer, layer by layer, with no leap of faith.

Worked example: the same bet, two different questions

Before building the complete one-pager (lesson 2 onward), it's worth seeing, in one small experiment, why this module matters and isn't just "putting together what you already did." Take recommendations —the bet that serves curatedDiscovery in Mercado's backlog— and ask it two questions, each with the model that answers it:

// Teaser: two different questions about the SAME bet, answered by two
// different models from this guide -- strategicFilter (M7) and moatScore (M6).
function moatScore(advantage) {
  const { name, type } = advantage;
  let durability;
  switch (type) {
    case 'feature': {
      const { timeToCopyWeekends } = advantage;
      durability = Math.max(0, Math.min(3, timeToCopyWeekends));
      break;
    }
    default:
      durability = 0;
  }
  const verdict = durability >= 7 ? 'moat' : durability >= 4 ? 'weak-moat' : 'not-a-moat';
  return { name, durability, verdict };
}

function riceScore({ reach, impact, confidence, effort }) {
  return (reach * impact * confidence) / effort;
}
function strategicFilter(backlog, strategy) {
  return backlog.map((bet) => {
    const reinforces = bet.servesDimensions.filter((d) => strategy.winOn.includes(d));
    const conflicts = bet.servesDimensions.filter((d) => strategy.avoid.includes(d));
    return { feature: bet.feature, inStrategy: reinforces.length > 0 && conflicts.length === 0, riceScore: Number(riceScore(bet.rice).toFixed(2)) };
  });
}

const mercadoStrategy = { winOn: ['curatedDiscovery', 'sellerTrust'], avoid: ['price'] };
const bet = { feature: 'recommendations', servesDimensions: ['curatedDiscovery'], rice: { reach: 5000, impact: 1, confidence: 0.5, effort: 3 } };

const filterResult = strategicFilter([bet], mercadoStrategy)[0];
const moatResult = moatScore({ name: 'curatedDiscovery', type: 'feature', timeToCopyWeekends: 3 });

console.log('=== The same bet, two different questions ===\n');
console.log(`strategicFilter('${filterResult.feature}') -> inStrategy: ${filterResult.inStrategy}  (does it belong to the game?)`);
console.log(`moatScore('curatedDiscovery')     -> verdict: ${moatResult.verdict}  (is it defensible?)`);

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

=== The same bet, two different questions ===

strategicFilter('recommendations') -> inStrategy: true  (does it belong to the game?)
moatScore('curatedDiscovery')     -> verdict: not-a-moat  (is it defensible?)

There it is, in two lines, this module's reason for existing. recommendations does belong to Mercado's strategy — it reinforces curatedDiscovery, the exact dimension where module 4 confirmed real differentiation. And at the same time, what that bet deepens —curatedDiscovery, evaluated as the pure algorithm— is not yet a moat: any competitor with a good team could copy it in a few weeks. Neither earlier module, by itself, could show you this: module 7 would have told you "build it, it belongs to the game" and stopped there; module 6 would have told you "this isn't defensible" without telling you whether it's still worth building anyway. Only when you run both models on the same bet, in the same place, does the complete question appear: do we build recommendations? Yes. Is it enough to build it and rest easy? No. That's exactly the kind of finding this module's complete pipeline is going to produce, now over the whole backlog, not just one bet.

The module's map

Save this route. Every lesson fills one layer of the one-pager, in the same order you built them throughout the guide, and lesson 8 chains them all into a single pipeline:

Idea                                          Lesson    One-pager layer
─────────────────────────────────────────────  ────────  ─────────────────────────────────────
The strategy one-pager                          L2        the complete structure + the vision
                                                            and mission (module 2), unchanged

Where to play                                   L3        segment + positioning statement,
                                                            verified with positionFit (module 3)

How to win                                      L4        real differentiation (differentiationMap,
                                                            module 4) + the competitive landscape
                                                            (competitiveMap, module 5)

The moat layer                                  L5        the complete defensibility audit
                                                            (moatScore, module 6)

The strategic filter applied                    L6        strategicFilter over Mercado's
                                                            complete backlog (module 7)

Pitching the strategy                           L7        the complete one-pager, assembled
                                                            and formatted for a real stakeholder
─────────────────────────────────────────────  ────────  ─────────────────────────────────────
Project: define Mercado's strategy               L8        the complete, chained pipeline:
from start to finish                                       positionFit → differentiationMap →
                                                            moatScore → strategicFilter

The boundary: what's NOT in this module

This module answers a specific question: what does Mercado's complete strategy look like, from start to finish, and which backlog bets survive when required to pass all four tests at once? It does not answer several neighboring questions:

• "How do I define a vision, a segment, or a differentiation from scratch?" — you already did that, thoroughly, in modules 2, 3, and 4. This module takes those definitions as given and reuses them; it doesn't reteach how to build them.
• "What does a complete competitive map, with a future projection, look like?" — module 5. Here its conclusion (the open space, with an expiration date) is used as context for the "how to win" layer; the complete map isn't rebuilt again.
• "How do you prioritize within the bets that already passed the filter?" — RICE and WSJF are still the territory of product-thinking-for-engineers-guide. This module, like module 7, stops at the door: it decides who competes for priority, not the exact order each team builds in with its real capacity.
• "How do I technically build any of the bets that survive the filter?" — real architecture and construction are the Fullstack ecosystem. This whole guide —and this module, its close— defines what to build and why; it doesn't teach you to build it.
• "How do I validate with real users that the segment and job are well chosen?" — discovery, the territory of product-discovery-and-prototyping-guide. This module's one-pager assumes module 3's segment is correct; it doesn't test it again with users.

Resources

• Roger Martin, "Decoding the Strategy Choice Cascade" — rogermartin.medium.com/decoding-the-strategy-choice-cascade-475d40555eb1. Playing to Win's complete framework —five cascading choices, each conditioned by the one before— is, literally, the structure this module turns into executable code for Mercado. In English.
• Melissa Perri, Escaping the Build Trap — oreilly.com/library/view/escaping-the-build/9781491973767. The complete argument for why a team can be extremely busy, shipping high-RICE features, and still not have a real strategy — the exact problem this capstone solves with a verifiable document. In English.
• Marty Cagan (Silicon Valley Product Group), "Product Strategy" — svpg.com/product-strategy-overview. Cagan describes product strategy as the discipline of turning scattered information into hard, defensible decisions — exactly what this module's one-pager does, layer by layer. In English.
• Hamilton Helmer, 7 Powers — 7powers.com. The technical vocabulary behind this one-pager's moat layer (module 6), worth rereading now that you're going to see it work inside the complete pipeline, not in isolation. In English.