Module 7: Strategy To Roadmap

Module overview: from strategy to roadmap

Next →

Why this module exists here

You've already done all the work above. Module 2 gave you Mercado's vision. Module 3 chose the segment —buyers who browse, not the ones searching for an exact SKU— and the positioning against the alternatives. Module 4 found the real differentiation, not parity. Module 5 mapped the complete competitive landscape and where it's moving. Module 6 identified what makes that position defensible —the moats: Mercado's seller network and purchase data, not a feature copyable in a weekend. You have, at this point, a complete strategy: where Mercado plays and how it wins.

And yet, none of those five pieces built a single line of product. A strategy that lives only in a document —no matter how well reasoned— changes nothing about what an engineering team does on Monday morning. This module closes that gap: how the strategy comes down to the roadmap, becoming the criterion that decides, before anything else, which bets even enter the conversation about what to build first.

This is where this guide crosses paths, head-on, with product-thinking-for-engineers-guide. In that guide's module 3, the Mercado team took its quarter's backlog —fasterCheckout, recommendations, sellerTools, reviews, improvedSearch— and prioritized it with the RICE formula. The result was clear: fasterCheckout won by a huge margin, with a riceScore of 6400, almost three times the second place. That analysis is correct on its own terms —RICE measures expected value per unit of cost well—, and yet it leaves an entire question unanswered, because it was never designed to answer it: does that bet belong to the game Mercado chose to play? RICE doesn't know. RICE can't know — it has no input that speaks to segment, positioning, differentiation, or moats. That's exactly this module's job.

Connection to module 6. Module 6 left you with the question of how defensible Mercado's position is if someone attacks it. This module starts one step earlier: how defensible the position is from the inside — if the Mercado team itself, with no competitor attacking, builds bets that reinforce neither the segment, nor the positioning, nor the moats it worked so hard to build, the strategy dilutes on its own, without needing a single competitor.

An everyday analogy: security check, before the departures board

In any large airport, before a passenger can even look at the departures board and decide which gate to rush to, they have to go through security check. Security check doesn't ask anyone "how urgent is your flight?" or "how expensive was your suitcase?" — it asks one single thing: do you have a valid boarding pass for a flight departing from here? If the answer is no, it doesn't matter how organized you are, how fast you walk, or how elegant your luggage is: you don't get through. And if the answer is yes, then —and only then— your name enters the board, where a completely different criterion —departure order, gate, time— decides how high up you appear.

They're two different filters, at two different moments, and mixing them up is the mistake that ruins the whole system. If you let "how organized the passenger is" decide who enters the airport —without first asking whether they have a valid pass— you'd have a terminal full of efficient people who can't fly anywhere. This module's strategic filter is exactly security check: it decides who belongs in the game, before anyone cares how well they score on RICE. The departures board —the final sequencing, the build order— is, literally, the work product-thinking-for-engineers-guide already taught you to do. This module doesn't replace the board. It builds the security check that has to happen before it.

Worked example: three bets, a quick look at the filter

Before building the complete model (lesson 3 onward), it's worth seeing the pattern once, with just three bets from Mercado's backlog. We're going to label each bet with the strategic dimension it claims to serve —servesDimensions—, and declare Mercado's strategy exactly as it was defined in previous modules: it wins on curated discovery and seller trust (winOn), and it explicitly decided not to compete on price (avoid) — the same decision you quoted, word for word, from module 2: "We chose to focus on buyers who browse, not the ones searching for an exact SKU, and we win by investing in curated discovery rather than the lowest price."

// riceScore reused, unchanged, from product-thinking-for-engineers-guide (module 3)
function riceScore({ reach, impact, confidence, effort }) {
  return (reach * impact * confidence) / effort;
}

// Pedagogical model: a bet "belongs to the strategy" if at least one of the
// dimensions it serves is in strategy.winOn (what the strategy chose to WIN
// on) AND none is in strategy.avoid (what it explicitly chose NOT to fight
// on). Serving a neutral dimension isn't enough.
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,
      servesDimensions: bet.servesDimensions,
      reinforces,
      conflicts,
      inStrategy: reinforces.length > 0 && conflicts.length === 0,
      riceScore: Number(riceScore(bet.rice).toFixed(2)),
    };
  });
}

const mercadoStrategy = { winOn: ['curatedDiscovery', 'sellerTrust'], avoid: ['price'] };

const teaser = [
  { feature: 'fasterCheckout', servesDimensions: ['convenience'], rice: { reach: 8000, impact: 2, confidence: 0.8, effort: 2 } },
  { feature: 'recommendations', servesDimensions: ['curatedDiscovery'], rice: { reach: 5000, impact: 1, confidence: 0.5, effort: 3 } },
  { feature: 'lowestPriceMatch', servesDimensions: ['price'], rice: { reach: 9500, impact: 3, confidence: 0.8, effort: 3 } },
];

console.log('=== strategicFilter: three bets from Mercado\'s backlog, ranked by RICE ===\n');
const result = strategicFilter(teaser, mercadoStrategy).sort((a, b) => b.riceScore - a.riceScore);
console.table(result);
console.log('The trio\'s highest riceScore (' + result[0].feature + ', ' + result[0].riceScore + ') has inStrategy: ' + result[0].inStrategy + '.');

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

=== strategicFilter: three bets from Mercado's backlog, ranked by RICE ===

┌─────────┬────────────────────┬────────────────────────┬────────────────────────┬─────────────┬────────────┬───────────┐
│ (index) │      feature       │    servesDimensions    │       reinforces       │  conflicts  │ inStrategy │ riceScore │
├─────────┼────────────────────┼────────────────────────┼────────────────────────┼─────────────┼────────────┼───────────┤
│    0    │ 'lowestPriceMatch' │      [ 'price' ]       │           []           │ [ 'price' ] │   false    │   7600    │
│    1    │  'fasterCheckout'  │   [ 'convenience' ]    │           []           │     []      │   false    │   6400    │
│    2    │ 'recommendations'  │ [ 'curatedDiscovery' ] │ [ 'curatedDiscovery' ] │     []      │    true    │  833.33   │
└─────────┴────────────────────┴────────────────────────┴────────────────────────┴─────────────┴────────────┴───────────┘
The trio's highest riceScore (lowestPriceMatch, 7600) has inStrategy: false.

There's the whole module, previewed in a single table. lowestPriceMatch —matching the market's lowest price— has the highest riceScore of the three bets, almost double the second place. And yet inStrategy is false: not because the number is miscalculated, nor because the bet is bad in the abstract, but because it competes on exactly the dimension Mercado decided not to fight on. fasterCheckout —the bet that won by a landslide in product-thinking-for-engineers-guide— doesn't pass either: it doesn't compete on price, but it also doesn't reinforce either of the two dimensions where Mercado chose to win. Only recommendations, with the lowest riceScore of the trio, truly belongs to the strategy. If you only looked at RICE, you'd build the two wrong bets first. That's, in one sentence, the problem this module solves.

The module's map

Save this route. The whole module moves from how strategy translates into concrete bets to the filter that decides who competes for priority, passing through the most expensive trap of ignoring it, the coherence among the bets that do pass, and how to say no with a real reason:

Idea                                          Lesson    Key concept
─────────────────────────────────────────────  ────────  ─────────────────────────────────────
From strategy to bets                            L2        translating "where we play and how
                                                            we win" into concrete candidates

The strategic filter                             L3        strategicFilter complete: belonging
                                                            to the strategy, BEFORE looking at RICE

High RICE, out of strategy                       L4        the trap: a large numerator doesn't
                                                            buy belonging to the game

Strategic coherence                              L5        the bets that pass reinforce each
                                                            other, they don't scatter

Saying NO at the strategic level                 L6        the explicit reason, not silence
                                                            nor "no time this quarter"

The strategy-roadmap bridge                      L7        filter first, RICE after --
                                                            connects with product-thinking
─────────────────────────────────────────────  ────────  ─────────────────────────────────────
Project: the strategic filter over                L8        Mercado's complete backlog,
Mercado's backlog                                          filtered and then sequenced

The boundary: what's NOT in this module

This module answers a specific question: which bets belong to Mercado's strategy, and in what order do the ones that do get built? It does not answer several neighboring questions, which belong to other modules of this guide or to other guides in the ecosystem:

  • "Which do we build first, among the ones that already passed the filter?" — that's RICE and WSJF's job, and you already did it thoroughly in product-thinking-for-engineers-guide (modules 3 and 7). This module doesn't reteach the formula or its four inputs — it reuses them, unchanged, and only after the filter has already decided who's eligible.
  • "How big is the opportunity for a specific bet?" — sizing is still the territory of product-thinking-for-engineers-guide (module 4). This module doesn't size anything; it decides belonging.
  • "Is the strategy itself well defined?" — you already built that in modules 2 through 6: vision, segment, positioning, differentiation, competition, and moats. This module takes that strategy as given and uses it as a criterion; it doesn't audit it again.
  • "How do we validate with real users that a bet is going to work?" — discovery, the territory of product-discovery-and-prototyping-guide. The strategic filter decides whether a bet belongs to the game; it doesn't measure whether it'll succeed once built.
  • "How do we measure whether the bet, once built, worked?" — metrics and experimentation, the territory of product-metrics-and-experimentation-guide. Here the filter runs before anything gets built.

Resources

  • Roger Martin, "Decoding the Strategy Choice Cascade" — rogermartin.medium.com/decoding-the-strategy-choice-cascade-475d40555eb1. The five cascading choices from Playing to Win deliberately end in concrete capabilities and management systems — the same descent from "where to play and how to win" to a concrete action that this module completes for Mercado. In English.
  • Melissa Perri, Escaping the Build Trap: How Effective Product Management Creates Real Value (O'Reilly, 2018) — oreilly.com/library/view/escaping-the-build/9781491973767. This whole module's underlying argument: a team can be completely busy, shipping high-RICE features, and still fall into the build trap if those features aren't connected to any real strategy. In English.
  • Marty Cagan (Silicon Valley Product Group), "Product Strategy" — svpg.com/product-strategy-overview. Cagan describes product strategy as the discipline of turning information into hard prioritization decisions — exactly the bridge this module builds between modules 2-6 and the roadmap. In English.
  • Itamar Gilad, "Why You Should Stop Using Product Roadmaps and Try GIST Planning" — itamargilad.medium.com/why-i-stopped-using-product-roadmaps-and-switched-to-gist-planning-3b7f54e271d1. Gilad argues that a roadmap of loose features, with no thread connecting them to the Goals they're supposed to pursue, is why most roadmaps age badly — the exact problem this module's strategic filter prevents. In English.
← PreviousMini-project: Mercado's moat auditNext →From strategy to bets