Module 8: Project Define Mercados Strategy

The strategy one-pager

Next →

Description

A strategy that lives scattered across seven documents —a note on the vision, a slide on the segment, a differentiation doc, a competitive map in another folder, a moat audit in a third system, a filtered backlog in a spreadsheet— isn't a usable strategy. It's material for a strategy. This lesson builds the one-pager: a single document, with a fixed layer structure, where every layer has a clear owner (a specific module of this guide) and an exact place. It introduces no new concept — it introduces the skeleton lessons 3 through 7 are going to fill, one layer at a time, and that lesson 8 is going to execute as a single pipeline.

Connection to the module. This is the capstone's foundational lesson: it defines the shape of the final document before starting to fill it. It reuses, unchanged, Mercado's vision and mission you built in module 2 — the one-pager's first layer is, literally, that result, copied verbatim, not rewritten.

An everyday analogy: the cockpit instrument panel, not seven loose clocks

A pilot doesn't fly a plane by reading seven instruments scattered randomly around the cockpit, each in a different corner, with no order among them. They fly with an instrument panel: a fixed layout, standardized across the entire industry, where the altimeter is always in the same relative position to the artificial horizon, and the airspeed indicator is always where the pilot expects to find it, with no need to search for it. The panel's layout isn't decorative — it's what lets a pilot, in an emergency, find the right data point in under a second, without having to think "where was the fuel gauge on this plane?"

The strategy one-pager is that panel, applied to product decisions. When someone at Mercado asks "why aren't we building lowestPriceMatch, if it has such good RICE?", the answer shouldn't require a half-hour investigation across seven different documents — it should be in a fixed place on the one-pager, exactly where anyone on the team expects to find it. This lesson builds that panel, layer by layer, before the following lessons start filling in each instrument.

The one-pager's layers, and who fills them

This module's one-pager has six layers. Each corresponds to an earlier module of the guide —or, in the last case, to this same module— and none is skipped until the previous one is complete:

Layer                    This module's lesson       Source module       Model run
───────────────────    ───────────────────────    ─────────────────   ─────────────────
foundation               L2 (this lesson)           M2 (vision)         --  (data, not a model)
whereToPlay               L3                         M3 (target)         positionFit
howToWin                  L4                         M4 + M5             differentiationMap +
                                                                          competitiveMap
moats                     L5                         M6                  moatScore
strategicFilter            L6                         M7                  strategicFilter
(complete pipeline)       L8                         M3+M4+M6+M7          the 4 chained together

Notice something important: the foundation layer —the vision and mission— is the only one that runs no executable model. It's, deliberately, the one-pager's only qualitative starting point: a direction the team chose, not something an algorithm calculated. Everything that comes after —where to play, how to win, the moats, the filter— does get verified with code, precisely because it starts from a foundational choice that, at some point, had to be decided without a model to validate it. That's, in one sentence, the difference between choosing a direction and verifying that later decisions are coherent with it.

Worked example: the one-pager's skeleton, with the first layer filled

We build the onePager object with its six layers, mark which are filled and which are pending with a small status function, and fill the one layer this module doesn't need any model to complete: the vision and mission, copied verbatim from module 2.

// Mercado's strategy one-pager: six layers, one per lesson of this module.
// This lesson fills the first -- the vision and mission, unchanged since module 2.
const vision = {
  statement: 'The world where anyone discovers on Mercado what they didn\'t know they wanted.',
  horizon: '10+ years, no deadline',
  includes: ['curatedDiscovery', 'localSellerTrust', 'serendipity'],
  excludes: ['exactSkuSearchEngine', 'lowestPriceRace', 'genericMegastore'],
};
const mission = {
  statement: 'We exist to connect curious buyers with trusted local sellers, today, with what already exists.',
  horizon: 'today, with what already exists',
};

const onePager = {
  foundation: { vision, mission },
  whereToPlay: null,
  howToWin: null,
  moats: null,
  strategicFilter: null,
};

function onePagerStatus(pager) {
  return Object.entries(pager).map(([layer, value]) => ({
    layer,
    status: value === null ? 'pending' : 'complete',
  }));
}

console.log('=== Mercado\'s strategy one-pager, layer by layer ===\n');
console.table(onePagerStatus(onePager));
console.log(`Vision:  "${vision.statement}"`);
console.log(`Mission:  "${mission.statement}"`);
console.log(`Excludes: ${vision.excludes.join(', ')}`);

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

=== Mercado's strategy one-pager, layer by layer ===

┌─────────┬───────────────────┬─────────────┐
│ (index) │       layer       │   status    │
├─────────┼───────────────────┼─────────────┤
│    0    │   'foundation'    │  'complete' │
│    1    │   'whereToPlay'   │  'pending'  │
│    2    │    'howToWin'     │  'pending'  │
│    3    │      'moats'      │  'pending'  │
│    4    │ 'strategicFilter' │  'pending'  │
└─────────┴───────────────────┴─────────────┘
Vision:  "The world where anyone discovers on Mercado what they didn't know they wanted."
Mission:  "We exist to connect curious buyers with trusted local sellers, today, with what already exists."
Excludes: exactSkuSearchEngine, lowestPriceRace, genericMegastore

One layer of five is complete, and the other four are, deliberately, marked pending — not empty by oversight, but waiting their turn for their corresponding lesson. This is the pattern you're going to repeat, with different data, in each of the next five lessons: never declare a layer ready without having verified it with the model that corresponds to it. A pretty vision, with no explicit excludes, doesn't count as a complete foundation — and that's why vision.excludes is explicitly printed at the end of this example, not just the inspiring statement.

Deep dive: why the layer order isn't arbitrary

You might ask why whereToPlay comes before howToWin, and why moats comes after both, instead of, say, starting with the moats —the defensibility question, which sounds more "strategic" at first glance. The order matters because each layer depends on the previous one, the same way Roger Martin's cascade in Playing to Win chains its five choices:

  • You can't define how you win (howToWin, differentiation) without having first chosen where you play (whereToPlay, segment) — differentiation is always differentiation for someone specific, never in the abstract. That's why module 4 came after module 3, and why this lesson comes before the next.
  • You can't audit moats with any rigor without first knowing what differentiation you're trying to defend — a moat that protects nothing about your real value proposition is a fortress around an empty field. That's why moats comes after howToWin, never before.
  • You can't apply the strategic filter to the backlog without winOn and avoid already existing — and those two values come, precisely, from whereToPlay and howToWin. That's why strategicFilter is the last layer before the complete pipeline.

This strict dependency is why the one-pager has layers, not a flat list of six unrelated data points. Every layer is an input to the next, and skipping one —for example, auditing moats without having first defined the real differentiation— produces a document that looks complete but can't explain its own conclusions.

Common mistakes

Starting the one-pager with the layer that's most exciting, not the one that comes first. What happens: someone on the team, excited about moats —it sounds like the "most strategic" part—, starts filling that layer before precisely defining the segment and differentiation those moats are supposed to protect. Why it happens: where to play and how to win feel like prep work, while moats and the strategic filter feel like the final result — and it's tempting to jump straight to the result. How to spot it: if someone can name a Mercado moat without being able to say, in the same sentence, which specific differentiation that moat protects, the order got skipped. How to fix it: respect this module's sequence, lesson by lesson — each layer requires the previous one to already exist, no exceptions.

Treating foundation as if it needed no verification for being "just" the vision. What happens: the team copies the vision and mission into the one-pager without checking whether they have explicit excludes, taking for granted that, since they were already written in module 2, they're automatically ready. Why it happens: the foundation layer is the only one with no executable model, and that gets confused with "no quality standard at all" — when in reality module 2 demands exactly the same rigor (explicit includes and excludes) as the layers with models. How to spot it: if your onePager.foundation doesn't have excludes as concrete as includes, it isn't complete, even if onePagerStatus marks it 'complete' just for not being null — this lesson's check verifies presence, not quality. How to fix it: before marking foundation as ready, apply module 2's same criterion: do the excludes name legitimate, profitable businesses Mercado says no to, or are they just obvious statements?

Confusing "the one-pager has six layers" with "the one-pager must fit on a single screen with no scrolling." What happens: someone tries to compress the six layers —including complete positionFit and differentiationMap tables— into a visually tiny document, sacrificing the detail that makes each layer verifiable. Why it happens: the name "one-pager" gets interpreted literally as a physical-space restriction, instead of as a structure restriction: a single document with a fixed structure, not necessarily a single screen with no scrolling. How to spot it: if your one-pager omits the executed detail (the tables, the numbers, the fitsSegment: true) to fit in less space, it stopped being verifiable and went back to being just pretty prose. How to fix it: prioritize every layer being traceable back to its model and its data — "a single source of truth," not "a single screen." The final project (lesson 8) shows how to keep both: compact in the narrative, complete in verification.

Exercises

Exercise 1 — Predict the status before running it. Without running code, if you add a seventh key to the onePager object called pitch: null, what new row would appear in the onePagerStatus table, and with what status?

See solution

A row { layer: 'pitch', status: 'pending' } would appear, in the position where the key was added (at the end, if added to the end of the object, since Object.entries preserves key insertion order). onePagerStatus's logic is generic: any key with a null value gets marked 'pending', regardless of its name — the model knows nothing about what each layer represents, only whether it has an assigned value or not.

Exercise 2 — Verify foundation's quality, not just its presence. Write, in pseudocode or real JavaScript, a foundationIsComplete(foundation) function that returns true only if foundation.vision.excludes has at least as many elements as foundation.vision.includes (module 2's rigor standard, not just "it exists").

See solution 
function foundationIsComplete(foundation) {
  const { includes, excludes } = foundation.vision;
  return Array.isArray(excludes) && excludes.length >= includes.length;
}

With this lesson's data, includes.length is 3 (curatedDiscovery, localSellerTrust, serendipity) and excludes.length is also 3 — the function would return true. This exercise shows the difference between onePagerStatus's check (does something exist, or is it null?) and a real quality check (does what exists meet the standard of the module that originated it?) — the more demanding kind of verification a real one-pager needs, beyond just filling in the blanks.

Exercise 3 — Explain the layer order to an impatient colleague. An engineering colleague, who wants to "skip straight to the moats because that's the interesting part," asks why they can't just write that layer first. Using the "Deep dive" section's vocabulary (dependency between layers, Roger Martin's cascade), write your answer in 2-3 sentences.

See solution

A sample answer: "A moat only makes sense if you know exactly what it's defending — if you start with the moats without having first defined where we play and how we win, you end up auditing the defensibility of an advantage you haven't even confirmed is real. It's the same as Roger Martin's cascade: every choice depends on the one above it, and skipping a step doesn't save time, it produces a document that can't explain its own conclusions when someone asks 'ok, but moat of what, exactly?'"

Summary and next step

In this lesson you built Mercado's strategy one-pager's complete skeleton: six layers, each with a source module and an executable model (except foundation, the only qualitative one by design), and you filled the first with the vision and mission, copied verbatim from module 2. You confirmed, with onePagerStatus, that the remaining five layers are correctly marked as pending — not empty by oversight, but waiting their turn.

Before moving on you should be able to: name the six layers in order, explain why each depends on the previous one, and distinguish between "a layer exists" (what onePagerStatus verifies) and "a layer meets its source module's standard" (what you verified in Exercise 2).

Lesson 3 fills the second layer: where Mercado plays, with positionFit running on module 3's exact segment and alternatives — this one-pager's first executable model.

Resources

← PreviousModule overview: the capstone — Mercado's product strategyNext →Where to play