From feature to metric: the missing link

Overview

You have the three pieces: you know what an output is (lesson 2), what an outcome is (lesson 3), and how to recognize whether that outcome is well framed (lesson 6). One last question remains, the easiest one to skip: why should this specific feature move that specific metric? It isn't enough to name a feature and a metric in the same sentence — you need a mechanism, an explanation of the cause-and-effect chain that connects them. Without that mechanism, what you have isn't a reasoned bet: it's a hope with a technical name.

This lesson introduces four links that any bet should be able to name before a single line of code gets written: the feature (what gets built), the mechanism (why it should change something), the behavior change (what the user does differently as a consequence), and the metric (the number that behavior change moves). If you can name all four, you have a bet that can be audited later, with judgment, whether it was met or not. If you only have the feature and the metric —without the two middle links—, you have exactly the pattern that produced ten of the twelve pure-output items in Mercado's quarter.

How this connects to the module. This lesson closes the module's conceptual loop before the project: lesson 4 showed you that most of Mercado's shipments didn't move GMV; this lesson starts explaining why — because they skipped the mechanism. And it deliberately leaves a door ajar: fully formalizing how a technical task turns into value for the user and then for the business is exactly the work of module 2 — the product value chain. Here you only install the question ("does a mechanism exist, or is this a hope?"); module 2 gives you the full framework for tracing it with rigor.

An analogy: the switch and the light in the other room

Imagine an old house with wiring nobody ever documented well. You find a switch on the hallway wall and, without thinking twice, flip it expecting it to turn on the light in the next room. Sometimes it works. Sometimes the switch is wired to a completely different circuit —the bathroom fan, an outlet in the garage— and the room's light stays off, with no idea why. Flipping switches at random, hoping something turns on where you want it, is exactly what a roadmap does when it jumps straight from the feature to the metric without declaring the mechanism: sometimes it connects, by pure coincidence, and often it doesn't.

A real electrician doesn't flip switches blindly: they follow the wire. They open the junction box, trace the circuit, and can tell you, before touching anything, "this switch is wired to that light, because the red wire runs from here to there." That traceability —being able to follow the whole path, link by link, from the action to the effect— is what separates an electrician from someone trying their luck. This lesson's four links are literally that wire: the feature is the switch, the mechanism and the behavior change are the wiring in between, and the metric is the light that turns on. If you can't trace the full wire, you don't know —you're only hoping— that flipping the switch is going to turn something on.

Worked example: the causal-chain checker

Let's build hasCausalChain, a checker that verifies whether a bet has all four links complete, and run it on two cases from Mercado's backlog: one with the full chain, and one where the team jumped straight from feature to metric, hoping it would connect on its own.

// hasCausalChain(): a shipment aiming at a metric needs all four links --
// feature, mechanism, behavior change, metric -- or it's just HOPING the
// metric moves on its own. Module 2 formalizes this chain; here we only
// check whether it exists.
function hasCausalChain(bet) {
  const links = ['feature', 'mechanism', 'behaviorChange', 'metric'];
  const missing = links.filter((l) => !bet[l]);
  return { name: bet.feature, complete: missing.length === 0, missing };
}

function printChain(bet) {
  const r = hasCausalChain(bet);
  console.log(bet.feature + ':');
  console.log('  feature           -> ' + (bet.feature || '(missing)'));
  console.log('  mechanism         -> ' + (bet.mechanism || '(missing)'));
  console.log('  behavior change   -> ' + (bet.behaviorChange || '(missing)'));
  console.log('  metric            -> ' + (bet.metric || '(missing)'));
  console.log('  chain complete    -> ' + (r.complete ? 'yes' : 'no (missing: ' + r.missing.join(', ') + ')'));
}

const savedPayments = {
  feature: 'Saved payment methods',
  mechanism: 'fewer steps and less friction when paying',
  behaviorChange: 'more users finish the purchase instead of abandoning the cart',
  metric: 'GMV',
};

const sellerDashboard = {
  feature: 'Seller analytics dashboard',
  metric: 'GMV',
};

printChain(savedPayments);
console.log('');
printChain(sellerDashboard);

What to expect. When you run the file with Node, the output is exactly this:

Saved payment methods:
  feature           -> Saved payment methods
  mechanism         -> fewer steps and less friction when paying
  behavior change   -> more users finish the purchase instead of abandoning the cart
  metric            -> GMV
  chain complete    -> yes

Seller analytics dashboard:
  feature           -> Seller analytics dashboard
  mechanism         -> (missing)
  behavior change   -> (missing)
  metric            -> GMV
  chain complete    -> no (missing: mechanism, behaviorChange)

There it is, formalized, exactly why Saved payment methods was one of the two bets that moved GMV in lesson 4: it wasn't just a good idea, it had all four links declared before it was built. The feature (saving the payment method), the mechanism (fewer steps, less friction), the expected behavior change (less cart abandonment), and the metric (GMV). Each link explains the next: less friction leads to less abandonment, and less abandonment leads to more GMV. It's a chain, not a coincidence.

And there, just as formalized, is the problem with Seller analytics dashboard: it has the feature and it has a metric in mind (GMV), but it's missing the two middle links. Nobody wrote why a dashboard should move GMV — because sellers will react faster to stockouts? Because they'll adjust prices better? Because they'll simply feel more professional using the platform? Any of those could be the real mechanism, but since nobody wrote it down, nobody can verify it, nor build the version of the dashboard that actually activates it. The team jumped straight from the switch to "let's hope the light turns on in some room of the house" — and in lesson 4 you saw the result: it didn't turn on.

The four links, one by one

FEATURE            what gets built. "Saved payment methods."
      |
      v  (why should this work? -- without this, it's a hope)
MECHANISM          the causal reason. "Fewer steps, less friction when paying."
      |
      v  (what does the user do differently, specifically?)
BEHAVIOR CHANGE     the behavior that changes. "Less cart abandonment."
      |
      v  (what business number reflects that change?)
METRIC              the measurable result. "GMV."

The link that's almost always missing —and the one hasCausalChain was designed precisely to expose— is the middle one: the mechanism. It's easy to name the feature (it's what you're going to build) and it's easy to name the metric the business cares about (it's always some variation of GMV, conversion, retention). What's hard, what demands real thinking before writing code, is explaining the middle step: why that specific feature should produce that specific behavior change. That effort of thinking through the mechanism, done seriously, is exactly what separates a reasoned bet from a hope with a roadmap.

An important clarification so you don't get ahead of yourself: this lesson teaches you to check whether the mechanism exists, not to build it with rigor — precisely tracing how a technical task turns into value for the user and then into value for the business, with all its intermediate steps, is the full work of module 2. Here the goal is smaller and more urgent: before building anything, ask yourself "can I fill in the four boxes, or am I skipping one?"

Common mistakes

Writing the mechanism afterward, to justify a result already known. What happens: a feature gets built with no declared mechanism, the metric does move (for whatever reason, maybe coincidence), and only then does someone invent an explanation for why it "made sense" — a mechanism written with the result already in hand. Why it happens: it's tempting to narrate success as if it had been planned, and it's easy to find a reasonable explanation in hindsight for almost any result. How to spot it: nobody can show you the mechanism written before the launch — only an after-the-fact explanation exists. How to fix it: demand that the mechanism be declared before building, not after measuring. If it truly holds, the mechanism written beforehand should match, in essence, the later explanation; if it doesn't match, that's a sign the success was coincidence, not cause.

Confusing "has a plausible mechanism" with "the mechanism is correct". What happens: a reasonable-sounding mechanism gets declared on paper —"the dashboard will make sellers react faster to stockouts"— and it's taken for granted, because it sounds logical, without planning how to check it after launch. Why it happens: filling in the mechanism box feels like finishing the analysis work. How to spot it: nobody defined, before launching, what specific data would confirm or refute that mechanism (for example, "the time between a stockout and the seller's price adjustment should go down"). How to fix it: a declared mechanism is a hypothesis, not a certainty — you still need to measure afterward, with the metric and, if the mechanism allows it, with an intermediate indicator (the behavior change) to confirm the whole chain held, not just the final result.

Treating the missing mechanism as a bureaucratic detail you can skip "to move faster". What happens: in the rush of sprint planning, the decision is to build directly, with the idea of "we'll justify it later if it works." Why it happens: declaring the mechanism takes thinking time, and in the moment it feels like friction before you get to start coding. How to spot it: check the current backlog — how many items have a written mechanism, and how many only have a feature name and, if you're lucky, a metric next to it? How to fix it: remember the real cost: at Mercado, skipping this step in ten of twelve items cost a whole quarter of effort with almost no measurable result. The time it takes to write four sentences of mechanism is minimal compared to the cost of building without knowing whether it's going to work.

Exercises

Exercise 1 — Find the missing link. For this Mercado bet, identify which of the four links are present and which are missing: "We're going to build product reviews (feature) because we believe it will raise GMV (metric)."

Exercise 2 — Complete the chain. For exercise 1's bet, write a full version with all four links, in the same format as the worked example's bet object (feature, mechanism, behaviorChange, metric).

const productReviews = {
  feature: 'Product reviews and ratings',
  mechanism: 'reviews from other buyers reduce uncertainty before purchasing',
  behaviorChange: 'fewer users abandon the product page without adding to cart',
  metric: 'GMV',
};

Exercise 3 — Design the intermediate check. For productReviews's full chain from exercise 2, propose a concrete data point —different from the final metric (GMV)— that the team could review two weeks after launch to know whether the intermediate mechanism is holding, before waiting to see whether the full GMV moved.

Summary and next step

In this lesson you installed the last question before building: it isn't enough to name a feature and a metric in the same sentence — you need an explicit mechanism connecting them, and an intermediate behavior change you can check. With the switch and the wire you saw why flipping features without tracing the full circuit is, literally, hoping something turns on by chance. And with hasCausalChain executed, you confirmed in code exactly what you already suspected since lesson 4: Saved payment methods had all four links complete; Seller analytics dashboard —like probably several of the other nine pure-output items— only had two.

Before moving on you should be able to: name the four links from memory; mentally apply the checker to any feature proposal you hear; and explain why writing the mechanism before building is different —and more valuable— than justifying it afterward.

With this you close out module 1's conceptual part. Lesson 8, the mini-project, has you audit Mercado's full quarter with everything you've learned: you'll classify the 12 shipments into outputs and outcomes, confirm the build trap verdict, and rewrite 2 or 3 of the pure-output bets as bets with a complete causal chain —checked, again, with the model executed in Node.

Resources

• Marty Cagan (Silicon Valley Product Group), "Outcomes Are Hard" — svpg.com/outcomes-are-hard. On why connecting a solution to a business result demands reasoning work that goes beyond building well. In English.
• John Cutler, "12 Signs You're Working in a Feature Factory" — medium.com/@johnpcutler/12-signs-youre-working-in-a-feature-factory. Symptom number one it describes is exactly the absence of a declared mechanism behind each feature. In English.