Mini-project: audit Mercado's quarter and rewrite its bets

Overview

It's time to bring the module's six lessons together into one complete exercise. You already know how to tell an output from an outcome (lessons 2 and 3), you put a number on the build trap (lesson 4), you accepted the question is yours as an engineer (lesson 5), you learned to recognize a good outcome (lesson 6), and you learned to demand a mechanism before building (lesson 7). In this mini-project you're going to apply all of that, in order, to the full case that's accompanied the whole module: Mercado's quarter.

The project has three parts, and all three get checked by running code, not by describing them in words. First, you audit the quarter as it actually shipped —reusing lesson 4's auditQuarter model— and confirm the build trap verdict with the full detail. Second, you pick three of the ten items that were pure output and rewrite them as bets with a complete causal chain —feature, mechanism, behavior change, metric—, using lesson 7's hasCausalChain checker. Third, you project what would happen to the quarter's audit if those three rewritten bets actually meet their metric, to see how much the picture improves —and how much work is still left, without overstating the result.

How this connects to the module. This project doesn't introduce any new concept: it's the synthesis of the six previous lessons, applied end to end to the same case. And it sets the stage for what comes next: rewriting a bet with a complete causal chain is exactly the first step of what module 2 is going to formalize in depth (the full value chain, from the technical task to business value), and deciding which of these rewritten bets go into the roadmap first is, later on, the work of modules 3 (prioritization) and 7 (the final roadmap). What you build today is the foundation the rest of the guide stands on.

An analogy: the coach and the quarter's logbook

In lesson 4 you compared the build trap to running on a treadmill: lots of effort, zero distance. Now imagine that runner hires a coach to review the last three months. The coach doesn't start by praising the effort or scolding the lack of results — they start by opening the full logbook: every training session, how long it lasted, which exercise it was. Then they cross it against the body's real data: weight, endurance, strength, measurements. Some sessions —the ones that worked the right exercise, at the right intensity, with a clear plan for which muscle they should strengthen— do show up in the real change. Others, though exhausting, left no measurable trace: they happened, they made you sweat, but they weren't part of a plan with a clear reason.

The coach doesn't throw out the whole logbook or tell the runner to stop training. They do exactly what you're about to do in this project: identify which sessions did work and why, pick a handful of the ones that didn't, and redesign them — same time, same available effort, but now with a specific muscle target and a clear reason why that exercise should achieve it. And before promising anything, they make an honest projection: "if these three redesigned exercises work as expected, next quarter looks this much better" — without pretending the whole problem disappears overnight. That is, with full precision, this project's structure.

The reference solution, verified

Let's build the complete audit and verify it step by step. (The exercises at the end ask you to extend it and reason about new cases.)

Part 1 — The quarter as it actually shipped

We start where lesson 4 left off: Mercado's 12 shipments, each with its metricMoved flag, and the auditQuarter model you already built.

function auditQuarter(shipments) {
  const total = shipments.length;
  const withOutcome = shipments.filter((s) => s.metricMoved);
  const pureOutput = shipments.filter((s) => s.isOutput && !s.metricMoved);
  return {
    total,
    outcomeCount: withOutcome.length,
    pureOutputCount: pureOutput.length,
    pureOutputNames: pureOutput.map((s) => s.name),
  };
}

function trapShare(r) {
  return Math.round((r.pureOutputCount / r.total) * 100);
}

const mercadoQ3 = [
  { name: 'Checkout page redesign (visual refresh)', isOutput: true, metricMoved: null },
  { name: 'Product recommendations carousel', isOutput: true, metricMoved: null },
  { name: 'Seller analytics dashboard', isOutput: true, metricMoved: null },
  { name: 'Product reviews and ratings', isOutput: true, metricMoved: null },
  { name: 'Search filters by price range', isOutput: true, metricMoved: null },
  { name: 'One-click reorder button', isOutput: true, metricMoved: null },
  { name: 'Wishlist and favorites', isOutput: true, metricMoved: null },
  { name: 'Dark mode', isOutput: true, metricMoved: null },
  { name: 'Social share buttons', isOutput: true, metricMoved: null },
  { name: 'Saved payment methods', isOutput: true, metricMoved: 'GMV' },
  { name: 'Real-time inventory sync for sellers', isOutput: true, metricMoved: null },
  { name: 'Simplified 3-step checkout', isOutput: true, metricMoved: 'GMV' },
];

const before = auditQuarter(mercadoQ3);
console.log('=== Audit: quarter as shipped ===');
console.log(before.total + ' shipments, ' + before.outcomeCount + ' moved a metric, ' +
  before.pureOutputCount + ' were pure output (' + trapShare(before) + '% pure output)');

This part holds no surprises —it's literally lesson 4's result—, but it's the mandatory starting point of any real audit: before proposing a single improvement, you need the complete, verified diagnosis, not a general impression of "we didn't do that great."

Part 2 — Three bets, rewritten with their causal chain

Of the ten pure-output items, we pick three candidates with the greatest potential —the ones where it's easiest to imagine a plausible mechanism toward GMV or conversion— and fill in lesson 7's four links for them:

function hasCausalChain(bet) {
  const links = ['feature', 'mechanism', 'behaviorChange', 'metric'];
  const missing = links.filter((l) => !bet[l]);
  return { complete: missing.length === 0, missing };
}

const rewrites = [
  {
    original: 'Product recommendations carousel',
    feature: 'Product recommendations carousel',
    mechanism: 'the carousel shows complementary products within the same cart',
    behaviorChange: 'more users add a second product before paying',
    metric: 'GMV',
  },
  {
    original: 'Seller analytics dashboard',
    feature: 'Seller analytics dashboard',
    mechanism: 'sellers see which products are moving and adjust price or stock in time',
    behaviorChange: 'fewer products run out of stock or stay overpriced',
    metric: 'GMV',
  },
  {
    original: 'Search filters by price range',
    feature: 'Search filters by price range',
    mechanism: 'users find something within their budget faster',
    behaviorChange: 'less abandonment during search, more users reach the cart',
    metric: 'checkout conversion',
  },
];

console.log('\n=== Bets rewritten from output to outcome ===');
rewrites.forEach((bet) => {
  const r = hasCausalChain(bet);
  console.log('"' + bet.original + '" -> chain complete: ' + (r.complete ? 'yes' : 'no'));
});

Notice something important about how these three were chosen, and not seven others: it wasn't random. Product recommendations carousel directly attacks the average ticket (the "add a second product" mechanism is the same one that makes recommendations work in any physical store, the "anything else?" at the register). Seller analytics dashboard has a defensible mechanism if it's connected to a concrete seller action (adjusting stock or price), not just "seeing data." And Search filters by price range attacks a known friction point in search. The other seven pure-output items —Dark mode, Wishlist and favorites, Social share buttons, among others— were left out of this rewrite round precisely because, honestly, it's harder to imagine them a plausible mechanism toward GMV; that doesn't make them useless as features, but it does leave them out of this specific "rewrite for next quarter" bet.

Part 3 — The projection: if the three bets deliver

Now, the final question: if these three rewritten bets get built and truly meet their metric next quarter, how does the full audit look?

const mercadoQ4 = mercadoQ3.map((s) => {
  const rewrite = rewrites.find((r) => r.original === s.name);
  return rewrite ? { ...s, metricMoved: rewrite.metric } : s;
});

const after = auditQuarter(mercadoQ4);
console.log('\n=== Audit: projection if the 3 bets deliver ===');
console.log(after.total + ' shipments, ' + after.outcomeCount + ' moved a metric, ' +
  after.pureOutputCount + ' were pure output (' + trapShare(after) + '% pure output)');
console.log('\nPure output remaining: ' + after.pureOutputNames.join(', '));

What to expect. When you run the full file (all three parts together) with Node, the output is exactly this:

=== Audit: quarter as shipped ===
12 shipments, 2 moved a metric, 10 were pure output (83% pure output)

=== Bets rewritten from output to outcome ===
"Product recommendations carousel" -> chain complete: yes
"Seller analytics dashboard" -> chain complete: yes
"Search filters by price range" -> chain complete: yes

=== Audit: projection if the 3 bets deliver ===
12 shipments, 5 moved a metric, 7 were pure output (58% pure output)

Pure output remaining: Checkout page redesign (visual refresh), Product reviews and ratings, One-click reorder button, Wishlist and favorites, Dark mode, Social share buttons, Real-time inventory sync for sellers

Read the three audits together, because together they tell the project's full story. The quarter as it actually shipped confirms, again, lesson 4's 83% build trap — the honest starting point. The three rewritten bets pass all four of hasCausalChain's tests: they're not just better-written ideas, they're bets that can be audited later, with a verifiable mechanism. And the projection shows the concrete effect of that work: if the three deliver, pure output drops from 83% to 58% — a real, measurable improvement, achieved without adding a single new item to the backlog, just by thinking harder about the ones already there.

And notice what the projection does not say, because it's as important as what it does say: 58% is still, under lesson 4's same threshold, a build trap — most of the quarter would still be pure output, even in the optimistic scenario where all three rewrites work exactly as expected. Seven items remain (Checkout page redesign, Product reviews and ratings, One-click reorder button, Wishlist and favorites, Dark mode, Social share buttons, Real-time inventory sync for sellers) with no declared causal chain. This projection isn't a promise that the problem gets solved just by this exercise — it's honest proof that it's possible to improve the number with the same effort, by thinking through the mechanism before building, and that there's still real work ahead. That work —deciding which of the remaining seven is worth rewriting, in what order, and how big to make them— is exactly what goes into modules 3 through 7 of this guide.

Common mistakes

Rewriting the bet to "sound good", with no real mechanism behind it. What happens: during the rewrite exercise, the mechanism field gets filled with a generic sentence ("it will improve the experience") just so hasCausalChain marks complete: true, without a genuine causal reason existing. Why it happens: the checker only verifies the field exists, not that its content is reasonable — that's a real limitation of the model, deliberately kept simple. How to spot it: if you ask whoever wrote the mechanism "why this specifically, and not any other sentence?", they don't have a concrete answer grounded in how users actually behave. How to fix it: the checker is a helper, not a substitute for judgment. Before considering a causal chain complete, ask yourself whether the written mechanism truly explains the why, with the same seriousness you'd give to explaining it to a skeptical coworker.

Rewriting all ten pure-output items at once, without prioritizing. What happens: motivated by the exercise, someone tries to find a plausible mechanism for all ten items, including the ones that genuinely have no clear connection to GMV (like Dark mode), forcing unconvincing mechanisms just to complete the checklist. Why it happens: it feels incomplete to leave items unrewritten. How to spot it: the mechanism for one of the ten sounds forced or speculative compared to Saved payment methods's or the three chosen in this project. How to fix it: not every output deserves to become an outcome bet — some, honestly, have no credible connection to the metric that matters, and it's fine to leave them as is, or rethink them entirely. Prioritizing which bets are worth rewriting with an explicit criterion is precisely module 3's work.

Confusing the optimistic projection with a guaranteed result. What happens: the "58% pure output" projection gets presented as if it were a certain fact about next quarter, instead of a scenario conditional on the three bets actually working. Why it happens: a projection with concrete numbers feels more solid than it is, especially when the number improves relative to the previous diagnosis. How to spot it: the projection gets quoted in a meeting without the word "if" — "next quarter we're down to 58% build trap" instead of "if the three bets deliver, we'd be down to 58%". How to fix it: a complete causal chain makes a bet auditable, not guaranteed. The three rewrites remain hypotheses until they're built, launched, and truly measured for whether metricMoved held — exactly the same process from lesson 3, repeated, hopefully with a better result.

Exercises

Exercise 1 — Rewrite a fourth item. Of the seven that stayed pure output in the projection, pick one (Checkout page redesign, Product reviews and ratings, One-click reorder button, Wishlist and favorites, Dark mode, Social share buttons, or Real-time inventory sync for sellers) and write its full causal chain, in the same format as the three from the example. If you pick one where you honestly can't find a credible mechanism, say so explicitly and explain why —that conclusion is also a valid result of the exercise—.

const oneClickReorder = {
  feature: 'One-click reorder button',
  mechanism: 'removes the effort of searching for and re-adding a product already bought',
  behaviorChange: 'more repeat users buy the same product again, more often',
  metric: 'GMV',
};

Exercise 2 — Compute a third scenario. Instead of all three rewritten bets delivering, imagine only one of the three (Search filters by price range) meets its metric, and the other two don't. Without running the code first, calculate the new outcomeCount, pureOutputCount, and the pure output percentage. Then verify by running it.

Exercise 3 — The closing argument. Imagine you have to defend, in a meeting with Mercado's team, why it's worth spending time writing mechanisms before building, instead of simply building faster (the typical objection: "this slows us down"). Use this project's concrete numbers to build the argument in 3-4 sentences.

Summary and next step

In this mini-project you audited Mercado's full quarter, bringing the module's six lessons together into one verified workflow: you confirmed the 83% build trap as shipped (lesson 4), rewrote three of the ten pure-output items with a complete causal chain —feature, mechanism, behavior change, metric— using lesson 7's checker, and projected the honest effect of that work: from 83% to 58% pure output, a real improvement achieved without building anything new, just by thinking harder about what was already in the backlog. And you saw, with the same honesty the whole module demands, that 58% is still not enough — seven items remain without a mechanism, and a complete causal chain is an auditable bet, not a guarantee.

With this you close module 1. You now have the vocabulary and the central reflex of this whole guide: the difference between what ships and what gets achieved, how to recognize a good outcome, and how to demand a mechanism before building. That reflex —asking yourself "and what should this move, and why?"— is the bar you're going to measure everything that follows against.

Where you go next. Module 2 takes exactly the work you started in Part 2 of this project —declaring a mechanism— and formalizes it in depth: the product value chain, the full path from a technical task to value for the user and, afterward, value for the business. You're going to learn to trace that path with the same rigor an electrician follows a wire, so no future Mercado bet ever jumps from switch to hope again. And further ahead: prioritizing this rewritten backlog with explicit judgment (module 3), sizing each bet before building it (module 4), trimming it to the smallest experiment that tests it (module 5), treating it as a bet under uncertainty (module 6), and ordering it into a roadmap you can defend (module 7) — all the way to the module 8 capstone, where you return to this same Mercado backlog one last time, with every tool in hand.

Resources

• Melissa Perri, "The Build Trap" — melissaperri.com/blog/2014/08/05/the-build-trap. Revisit it as the module's closing note: the original source of the diagnosis this project just applied in code. In English.
• Josh Seiden, "Outcomes Over Output" — outcomesoveroutput.com. The definition underpinning the whole project: an outcome is a change in human behavior that drives a business result. In English.
• John Cutler, "12 Signs You're Working in a Feature Factory" — medium.com/@johnpcutler/12-signs-youre-working-in-a-feature-factory. A good checklist to self-assess, with your own team, whether the pattern you audited at Mercado also applies where you work. In English.
• Marty Cagan (Silicon Valley Product Group), "Outcomes Are Hard" — svpg.com/outcomes-are-hard. As a bridge to module 2: on the new competencies that delivering outcomes instead of output, sustainably, demands of the whole team. In English.