Pitching the strategy

Description

The one-pager's five previous layers are complete and verified: vision, where to play, how to win, moats, and the strategic filter applied to the backlog. But a document with five layers of code and tables still isn't something you can read out loud to Mercado's founding team in five minutes. This lesson builds the last step before the final project: a renderer that takes the already-verified results from lessons 2 through 6 and formats them into a single-piece document, readable by anyone who never saw any of this guide's seven previous modules.

Connection to the module. This lesson runs no new evaluation model — it takes the results already calculated by positionFit, differentiationMap, competitiveMap, moatScore, and strategicFilter in earlier lessons, and turns them into presentable text. It's the difference between having the evidence and knowing how to present it — the same distinction that separates a correct analysis from a decision the founding team can actually make with confidence.

An everyday analogy: the executive summary, not the entire appendix folder

No consultant hands an executive client, as the first page of their report, two hundred pages of technical appendices. They hand over an executive summary: a single page that says, plainly, what the conclusion is, what the key evidence supporting it is, and what's recommended — with the two hundred appendices available, but only for whoever wants to dig deeper. The executive summary isn't a "simpler" version of the analysis — it's a distilled version, where every sentence can be traced back to a specific appendix, but nobody has to read all two hundred to understand the conclusion.

This lesson's renderer is exactly that executive summary. The five verified layers from lessons 2 through 6 are the "appendices" —complete, with their tables, their models, their exact numbers—; the document renderOnePager produces is the page any stakeholder needs to read first, with every line traceable back to the layer that produced it, but with no requirement to review six complete lessons before understanding where Mercado is going.

Worked example: the complete one-pager, in a single block of text

// Mercado's complete one-pager, assembled with the already-verified
// results from lessons 2 through 6. renderOnePager() recalculates
// nothing -- it only formats what already ran, so it can be pasted into
// a document or read aloud in five minutes in front of the founding team.
function renderOnePager(p) {
  const lines = [];
  lines.push(`PRODUCT STRATEGY -- ${p.product.toUpperCase()}`);
  lines.push('='.repeat(40));
  lines.push('');
  lines.push(`VISION: ${p.vision}`);
  lines.push(`MISSION: ${p.mission}`);
  lines.push('');
  lines.push(`WHERE WE PLAY: ${p.whereToPlay} (margin +${p.whereToPlayMargin} over the best rival)`);
  lines.push(`HOW WE WIN: ${p.howToWin.join(' + ')}`);
  lines.push(`COMPETITIVE SPACE: ${p.competitiveSpace}`);
  lines.push(`REAL MOATS: ${p.realMoats.join(', ')} (${p.realMoatCount}/${p.moatCandidateCount})`);
  lines.push(`STRATEGIC FILTER -- roadmap: ${p.roadmap.join(' > ')}`);
  lines.push(`REJECTED, DESPITE GOOD RICE: ${p.rejected.join(', ')}`);
  return lines.join('\n');
}

const onePager = {
  product: 'Mercado',
  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.',
  whereToPlay: 'buyers who browse (explorers), not the ones searching for an exact SKU',
  whereToPlayMargin: 1.65,
  howToWin: ['curatedDiscovery', 'localSellerTrust'],
  competitiveSpace: 'open today (openSpace: true), closes in 3 years if nobody defends it',
  realMoats: ['sellerNetwork', 'purchaseData', 'logisticsNetwork', 'sellerToolsWorkflow'],
  realMoatCount: 4,
  moatCandidateCount: 8,
  roadmap: ['reviews', 'sellerTools', 'recommendations'],
  rejected: ['lowestPriceMatch (riceScore 7600)', 'fasterCheckout (riceScore 6400)'],
};

console.log(renderOnePager(onePager));

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

PRODUCT STRATEGY -- MERCADO
========================================

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.

WHERE WE PLAY: buyers who browse (explorers), not the ones searching for an exact SKU (margin +1.65 over the best rival)
HOW WE WIN: curatedDiscovery + localSellerTrust
COMPETITIVE SPACE: open today (openSpace: true), closes in 3 years if nobody defends it
REAL MOATS: sellerNetwork, purchaseData, logisticsNetwork, sellerToolsWorkflow (4/8)
STRATEGIC FILTER -- roadmap: reviews > sellerTools > recommendations
REJECTED, DESPITE GOOD RICE: lowestPriceMatch (riceScore 7600), fasterCheckout (riceScore 6400)

Nine lines summarize this guide's seven complete modules, and every one of those nine lines is traceable: the VISION line comes, unchanged, from module 2; WHERE WE PLAY comes from the productWeightedScore and bestRival positionFit calculated in lesson 3; HOW WE WIN comes from differentiationMap's realDiffs in lesson 4; COMPETITIVE SPACE comes from competitiveMap's openSpace, also lesson 4; REAL MOATS comes from counting verdict === 'moat' in the complete audit in lesson 5; and the last two lines come directly from strategicFilter's roadmap and rejected in lesson 6. Nothing in this document was invented at the moment of writing it — everything was copied from a result you already ran and verified before.

Deep dive: why renderOnePager shouldn't recalculate anything

Notice a deliberate design detail of renderOnePager: the function receives an onePager object already filled with concrete values (whereToPlayMargin: 1.65, realMoatCount: 4) — it doesn't receive Mercado's raw data or rerun positionFit or moatScore internally. This separation isn't a minor implementation detail: it's the same "single source of truth" discipline you saw in module 2 (never write the vision from memory, always cite it from the single document) now applied at the renderer level. If renderOnePager recalculated the models on its own, there would be a risk of the "presentation" version and the "verified" version silently diverging —for example, if someone updates positionFit's data in lesson 3 but forgets to update the object feeding the renderer. Keeping the renderer purely as a formatting function, with no business logic of its own, is what guarantees the final document says exactly what the verified layers say, no more, no less.

Common mistakes

Writing the presentation one-pager by hand, instead of generating it from verified results. What happens: someone, rushed before a meeting, writes the presentation text directly —"we win with a solid margin," "we have several real moats"— without connecting those sentences to any specific number from earlier lessons. Why it happens: writing persuasive prose by hand is faster, in the moment, than building the complete data object and formatting it with code. How to spot it: if the presentation one-pager doesn't have an exact number for every claim (the exact margin, the exact moat count, the exact riceScore of what was rejected), someone wrote it from memory instead of generating it from verified data. How to fix it: always require every line of the final document to be traceable back to a specific numeric value from an earlier lesson, as in this lesson's example.

Presenting the one-pager without the "rejected, despite good RICE" line. What happens: the final document highlights the approved roadmap (reviews > sellerTools > recommendations) but omits mentioning what was rejected and why, especially the two highest-riceScore bets in the whole backlog. Why it happens: showing only the positive feels cleaner and more action-oriented — the same mistake module 7 already warned about at the project level, now repeated at the final presentation level. How to spot it: if a stakeholder who knows the complete backlog would have to ask "what about fasterCheckout?" after seeing your one-pager, the rejected line is incomplete or missing. How to fix it: the REJECTED, DESPITE GOOD RICE line isn't optional — it's often the line that most convinces a skeptic the filter is real and not a formality.

Treating the rendered one-pager as the end of the work, without connecting it to what to build. What happens: the document gets presented, applauded, filed away — and nobody translates its nine lines into a concrete engineering decision about what to build first, or about which bet needs, besides belonging to the strategy, to reinforce a still-fragile moat. Why it happens: a well-formatted, complete document feels like an endpoint, when in reality the most important reading is still missing — crossing the roadmap against the moat audit. How to spot it: if nobody in the meeting where this one-pager gets presented asks "which of these three builds something defensible, not just something that belongs to the game?", the document's most valuable reading hasn't happened yet. How to fix it: proceed to lesson 8 — the final project doesn't stop at presenting the result, it crosses the roadmap against the moats and finds the answer to exactly that question.

Exercises

Exercise 1 — Add a risk line to the one-pager. Extend onePager with a new key topRisk: 'curatedDiscovery is not a moat yet (durability 3)', and add the corresponding line to renderOnePager. Write the new code block and predict where in the document that line should appear.

lines.push(`TOP RISK: ${p.topRisk}`);

Exercise 2 — Detect a deliberate inconsistency. If someone changed onePager.whereToPlayMargin to 2.5 without having rerun positionFit, how would you detect it, given that renderOnePager recalculates nothing on its own?

Exercise 3 — Present the complete one-pager in five minutes. Using this lesson's exact output text, write the script for a five-minute oral presentation in front of Mercado's founding team, without reading the nine lines verbatim — turn them into a natural spoken narrative.

Summary and next step

In this lesson you assembled Mercado's complete one-pager into a single presentation document: nine lines, each traceable back to a verified result from an earlier layer, ready to be read aloud to any stakeholder with no need for six lessons of prior context.

Before moving on you should be able to: explain why renderOnePager recalculates no model, and locate which lesson each of the document's nine lines comes from.

Lesson 8, this guide's final project, goes beyond presenting the result: it chains positionFit, differentiationMap, moatScore, and strategicFilter into a single pipeline run start to finish, derives winOn and avoid directly from code instead of declaring them by hand, and crosses the final roadmap against the moat audit — the whole guide's last finding, and the close of product-strategy-for-engineers-guide's entire arc.

Resources

• Marty Cagan (SVPG), "Product Strategy" — svpg.com/product-strategy-overview. Cagan insists that a good product strategy must be communicable clearly to any stakeholder — the exact standard this lesson's renderer pursues. In English.
• Roger Martin, "Playing to Win" (book site) — rogerlmartin.com/lets-read/playing-to-win. Martin's "cascade of choices" format is, in essence, a strategy one-pager — the same discipline of condensing complex decisions into a readable document. In English.
• Gibson Biddle, "Intro to Product Strategy" — gibsonbiddle.medium.com/intro-to-product-strategy-60bdf72b17e3. Real examples of how to communicate a complete product strategy in a short document, the same discipline this lesson applied to Mercado's case. In English.