From user value to business value: does this move anything the business reports?

How this connects to the module. Lessons 3 and 4 closed the first two baton handoffs: task → capability and capability → userValue. This one closes the last —userValue → businessMetric—, and of the three, it's the easiest to take for granted without verifying: when the benefit for the user feels obviously good, it's tempting to assume it "obviously" helps the business too. This link demands proof, not a feeling.

An everyday analogy: the spa that relaxes, but doesn't bring in more revenue

A spa introduces a new massage technique and clients love it: they leave visibly more relaxed, they mention it at the front desk, some even bring it up in a review. That's an undeniable userValue — the benefit is real, and whoever receives it notices. But the spa's owner never connects that fact to anything that touches their bank account: they don't know whether those relaxed clients book more sessions, whether they bring friends, or whether they simply go back to their lives and don't think about the spa again until their back hurts next time.

Feeling relaxed is real. That translating into more revenue for the spa isn't automatic — it depends on whether the relaxed client comes back, refers others, or pays more per session, and that's only known if someone measures it. The spa could be delivering a wonderful experience and going broke at the same time, if that experience never connects to a number that sustains the business. That's exactly the risk of the last link: a genuine user benefit that never connects to any number the business observes.

Worked example: two real benefits, do they move anything?

Let's compare two Mercado tasks that did complete the first three links —both produce a real capability that matters to a specific type of user— and ask, for each one, whether that benefit connects to a number Mercado reports.

// Third and final baton handoff: userValue -> businessMetric. We compare a
// task with a real user benefit but no connected metric, against one that
// does have a named businessMetric.
function traceChain({ task, capability, userValue, businessMetric }) {
  const links = [
    ['task', task],
    ['capability', capability],
    ['userValue', userValue],
    ['businessMetric', businessMetric],
  ];
  const brokenLabel = {
    capability: '(no visible capability)',
    userValue: '(no user value)',
    businessMetric: '(no business metric)',
  };
  const segments = [];
  for (const [key, value] of links) {
    if (value === null) {
      segments.push(brokenLabel[key]);
      return { complete: false, brokenAt: key, trace: segments.join(' -> ') + ': CHAIN BROKEN' };
    }
    segments.push(value);
  }
  return { complete: true, brokenAt: null, trace: segments.join(' -> ') + ': chain complete' };
}

const darkMode = {
  task: 'add dark mode to the storefront',
  capability: 'the buyer browses with a dark theme',
  userValue: 'less eye strain during nighttime shopping',
  businessMetric: null,
};

const recommendCheckout = {
  task: 'add recommendations at checkout',
  capability: 'the buyer sees 3 related products before paying',
  userValue: 'discovers items they wanted without searching for them',
  businessMetric: '+GMV (higher average ticket)',
};

console.log('=== Two real benefits for the user, do they move anything? ===\n');
console.log('dark mode      :', traceChain(darkMode).trace);
console.log('recommendations:', traceChain(recommendCheckout).trace);

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

=== Two real benefits for the user, do they move anything? ===

dark mode      : add dark mode to the storefront -> the buyer browses with a dark theme -> less eye strain during nighttime shopping -> (no business metric): CHAIN BROKEN
recommendations: add recommendations at checkout -> the buyer sees 3 related products before paying -> discovers items they wanted without searching for them -> +GMV (higher average ticket): chain complete

"Less eye strain during nighttime shopping" isn't a made-up benefit — it's completely believable that dark mode would reduce eye strain for someone shopping at 11 at night. The problem, again, isn't the userValue's truthfulness but the next link: nobody completed the sentence "and that moves...". Does it reduce abandonment among nighttime buyers? Does it increase how many times a week they reopen the app at night? Does it move nothing measurable and is it simply a nice courtesy? Without that answer, the task stays exactly where the spa stayed with its relaxed clients: delivering a better experience, with no evidence it sustains the business.

Going deeper: leading indicators, lagging indicators, and the "it feels good" trap

Not every businessMetric has to be the business's final number (GMV). Mercado, like any mature team, tracks both lagging indicators (final results, slow to move: GMV, revenue) and leading indicators (early signals, faster to move, that historically predict the lagging one: visit frequency, return rate, time in the app). A valid businessMetric can be either one, as long as it's a number the team already tracks and can show on a dashboard — not a hunch.

The most common trap of this link is treating "it feels good" as if it were, on its own, business evidence. There's a useful hierarchy to avoid falling into it:

1. "Users liked it" (a feeling, sometimes not even measured) — the weakest level, the one that caught the spa.
2. "Users use it" (adoption, a real leading indicator, but still doesn't say whether it generates more business) — better, but incomplete.
3. "Users who use it do X more than those who don't" (a correlation with a behavior the business already tracks: they buy more often, spend more, stay longer) — this is a candidate businessMetric.

Dark mode sits, at best, at level 2: it's plausible that people use it, but nobody got to level 3 —connecting its use to something Mercado reports—. That doesn't mean it isn't worth building (there are legitimate reasons to build level-1 or level-2 things, like courtesy or a low-cost bet), but if it's presented as a bet that will move the business, the chain, as it stands, doesn't support that.

Common mistakes

Treating "users liked it" as if it were a businessMetric. What happens: satisfaction, praise, or adoption gets reported as if it were evidence of business impact. Why it happens: satisfaction is the easiest, fastest signal to get —comments, an informal NPS— and it feels like a "result". How to spot it: ask "on which dashboard, under what metric name, does this show up?" — if the answer is "people commented positively", it isn't a businessMetric, it's a userValue not yet connected. How to fix it: look for level 3 of the hierarchy —what measurable behavior changes in the people who receive that benefit— before declaring the link closed.

Choosing the easiest businessMetric to move, not the most honest one. What happens: a userValue gets connected to a metric that sounds good but has no credible causal relationship —"less eye strain" connected directly to "+retention", with no data backing it—. Why it happens: closing the chain feels better than leaving it open, and any metric will do to "fill the box". How to spot it: ask yourself whether you could explain, in a credible causal sentence, why that userValue would move exactly that metric and not another. If it sounds forced, it probably is. How to fix it: if there's no metric with a credible causal connection, it's more honest to leave businessMetric: null and say so out loud, than to invent a weak connection.

Giving up at "this can't be measured". What happens: faced with a genuine but hard-to-connect userValue (like eye strain), the conclusion is "this can't be measured" and the link gets abandoned without trying. Why it happens: measuring behavior takes more work than measuring feeling, and it's tempting to give up. How to spot it: if you never defined what behavior you'd expect to see change if the userValue were true, it isn't that "it can't be measured" — it's that you didn't try. How to fix it: before giving up, ask "if this really helps the user, what behavior of theirs should change, and can we track that behavior?" — there's almost always an answer, even an approximate one (measuring it thoroughly, with statistical rigor, is the metrics guide's job).

Exercises

Exercise 1 — Place the level. For each statement, say whether it corresponds to level 1 ("felt good"), level 2 ("gets used"), or level 3 ("connects to a behavior the business already tracks") of the hierarchy:

• (a) "40% of buyers turned on dark mode in their first week"
• (b) "several buyers commented that dark mode looks elegant"
• (c) "buyers who use dark mode complete 8% more nighttime purchases than those who don't"

Exercise 2 — Predict before running. Without executing anything, for this task, say what traceChain would print:

const wishlistFeature = {
  task: 'add a wishlist to the storefront',
  capability: 'the buyer saves products for later',
  userValue: 'keeps track of products they cannot buy right now',
  businessMetric: '+GMV (buyers with a wishlist return and buy 20% more often)',
};

add a wishlist to the storefront -> the buyer saves products for later -> keeps track of products they cannot buy right now -> +GMV (buyers with a wishlist return and buy 20% more often): chain complete

Exercise 3 — Find the missing level 3. Go back to the dark mode task from the worked example (broken at businessMetric). Without making up fake data, write what question you would ask Mercado's data team to try to find a level-3 metric connecting "less eye strain during nighttime shopping" with something the business reports.

Summary and next step

The last baton handoff —userValue → businessMetric— is the one that separates "we did something good" from "we did something that sustains the business". A user benefit can be completely real —like the spa client's relaxation— and still not connect to any number the business observes, if nobody does the work of tracking the behavior that benefit should change. The three-level hierarchy —felt good, gets used, connects to a behavior the business already tracks— gives you a concrete way to demand level 3 of yourself before declaring the chain complete.

Before moving on you should be able to: tell a real businessMetric (a metric name that exists on a dashboard) apart from a feeling disguised as a metric; and for any user benefit, formulate the data question that would take it to level 3.

With all three baton handoffs covered separately —lessons 3, 4, and 5—, lesson 6 brings them back together: the full method for tracing a task end to end, applied to several backlog tasks at once.

Resources

• Amplitude, "Leading vs. Lagging Indicators" and related content on metrics trees — amplitude.com/blog. The distinction between early and final indicators that underpins this lesson's three-level hierarchy. In English.
• Reforge, public articles on "growth metrics" and metrics trees — reforge.com/blog. How real product teams connect user behavior with business metrics. In English.
• Marty Cagan, Inspired — svpg.com/inspired-how-to-create-products-customers-love. On why "users love it" isn't enough as a business justification without connecting to a measurable result. In English.
• Teresa Torres, "Opportunity Solution Trees" — producttalk.org/opportunity-solution-tree. Torres's tree explicitly connects the business goal to opportunities (user behaviors) before reaching solutions — the same order of reasoning as this link, read from business toward user. In English.