Product metric catalog for reliable product decisions

Most teams don't have a metrics problem. They have a trust problem with their metrics. Ask three people what "active user" means and you'll get three definitions, two dashboards, and one Slack thread that ends with "let me get back to you." By the time someone confirms the number, the roadmap meeting is already over and a decision got made on vibes.

A product metric catalog fixes the part everyone skips: not which metrics to track, but how each metric is defined, who owns it, where its data comes from, and what happens when it drifts. It's governance for the numbers that steer your roadmap. When it's missing, the failure isn't loud — it's a slow erosion where nobody quite believes the dashboard, so everyone quietly reverts to opinion.

This is the systems view: how the catalog, ownership, lineage, and metric-level reliability targets connect — and what breaks at each stage as you grow.

Why metric trust decays as teams scale

At five people, metric governance is basically a person. Someone in the room knows that "conversion" excludes internal test accounts, remembers the day the signup event got renamed, and can eyeball a number and say "that's off." That tribal knowledge works right up until it doesn't.

1. 1
   Definitions fork silently. Marketing counts a trial the moment someone hits the pricing page. Product counts it at account creation. Finance counts it at first payment intent. Nobody's wrong, but three "trial" numbers now exist and leadership gets whichever one lands in their deck first.
2. 2
   Instrumentation drifts from intent. An engineer renames an event during a refactor. The dashboard keeps running because it points at the old table, which now silently returns zero. Nobody notices for three weeks because the number "looked plausible."
3. 3
   Ownership evaporates. The person who built the retention query left. The query still runs. When it breaks, there's a game of hot potato about whose job it is to fix it.

The number of metrics grows linearly in most product orgs, but the number of possible disagreements grows combinatorially. Every new metric that isn't cataloged is a future argument scheduled for the worst possible moment — usually a prioritization review.

The core issue is that metrics get treated as outputs of dashboards rather than as governed assets with a definition, a source, an owner, and a reliability expectation. Fix that framing and most of the downstream chaos disappears.

The four layers of a working catalog

A metric catalog isn't a spreadsheet of KPIs. It's four connected layers, and skipping any one of them is where things fall apart.

Layer 1: The catalog schema

Every metric entry needs enough structure that a new PM could understand it without asking anyone. A minimal but sufficient schema:

The two fields most teams leave out are exclusions and decision usage — and those are exactly the two that cause the loudest fights. Exclusions are where definitions secretly fork. Decision usage is what tells you whether a metric even deserves governance effort. If a metric doesn't feed a decision, it's dashboard decoration and shouldn't consume your reliability budget.

Layer 2: The ownership matrix

An owner in the catalog is a name, but ownership in practice has three distinct roles that constantly get collapsed into one:

1. 1
   Definition owner — decides what the metric means. Owns the exclusions, the grain, and any change to the formula. Usually a PM or analyst.
2. 2
   Pipeline owner — keeps the data flowing correctly. Owns the instrumentation and the transformation. Usually an engineer or data engineer.
3. 3
   Consumer of record — the primary decision-maker who uses the metric and gets paged when it breaks at a bad time.

A typical failure mode: a metric has an engineer listed as "owner," but that engineer owns the pipeline, not the definition. So when someone asks "should reactivated accounts count as activated?", the engineer has no authority to answer and the question rots in a backlog for a month.

The thing most teams miss: shared metrics need a single definition owner even when three departments consume them. The moment two owners can both change the definition, you're back to forked numbers.

Layer 3: The lineage checklist

Lineage is the "where does this number physically come from" trail. When a metric looks wrong, lineage is what lets you debug in ten minutes instead of two days. A practical lineage check for any decision-grade metric:

1. 1
   Source events identified — you can name the exact events or tables feeding the metric.
2. 2
   Transformation documented — every join, filter, and dedup step is written down, not living only in someone's SQL.
3. 3
   Freshness traceable — you know when each upstream source last updated and whether the metric reflects it.
4. 4
   Change alerts wired — if an upstream event is renamed, removed, or drops to zero volume, someone gets notified before the dashboard lies.
5. 5
   Reconciliation point defined — there's a "source of record" (often finance or the raw event log) the metric can be checked against.
6. 6
   Downstream consumers mapped — you know which dashboards, decks, and gates break if this metric changes.

Step 6 is the one people forget and regret. Change a metric definition without knowing its downstream consumers and you'll silently invalidate three dashboards and a board slide. The instrumentation you set up at launch needs documented lineage or it decays into noise within a quarter — same principle as any analytics spec work done pre-launch.

Layer 4: Metric-level SLOs

Borrowing SLO thinking from reliability engineering is the piece that turns a static catalog into something that stays trustworthy over time. Not every metric deserves the same reliability investment, so tier them.

The mistake is treating every metric as Tier 1 because it feels important. If everything is critical, your data team burns out chasing freshness on numbers nobody makes decisions with, and the genuinely critical metrics don't get the attention they need. Tiering forces an honest question: does a decision actually hang on this?

Mapping metrics to roadmap decisions and prioritization gates

This is where the catalog stops being documentation and starts being infrastructure. The point of governing a metric is that it can gate something without triggering an argument about whether the number is real.

1. 1
   Gate

   "We won't invest more in onboarding features unless activatedaccounts7d is below 40%."

2. 2
   Precondition for the gate to hold

   the metric is Tier 1, has a single definition owner, has documented exclusions, and hasn't had a lineage break in the reporting window.

Without that precondition, the gate becomes theater. Someone shows a number, someone else challenges the definition, and the whole thing collapses into opinion. With it, the conversation goes straight to the actual decision.

The same discipline pays off when you're deciding which bets to run. When you validate roadmap bets with lightweight experiments, the readout is only as good as the metric feeding it — a poorly-defined success metric turns a clean experiment into an inconclusive one. And a catalog is the backbone that makes a real measurement architecture with leading indicators and dashboards hold up over time instead of rotting into a graveyard of stale charts.

A useful workflow, end to end:

1. 1
   A roadmap decision needs a metric to gate it.
2. 2
   Check the catalog. Does a governed metric exist that measures this?
3. 3
   If yes and it's Tier 1 — use it, cite the definition, move on.
4. 4
   If yes but Tier 2/3 — decide whether to promote it to Tier 1 before it gates a real decision. Promotion means assigning owners, documenting lineage, and setting an SLO.
5. 5
   If no metric exists — don't invent one live in the meeting. Log it, define it, catalog it, then gate on it next cycle.

Here's a simple workflow visualization.

Step 5 is unpopular and correct. Metrics invented under time pressure in a roadmap meeting are exactly how forked definitions get born.

A real scenario: the two-retention-numbers problem

A B2B SaaS team, around 40 people, three product squads. Their board deck showed monthly logo retention around 92%. The customer success team's dashboard showed something closer to 85%. Same metric name, two very different numbers, and every quarterly review wasted twenty minutes relitigating which was real before anyone could discuss the actual roadmap.

The gap came down to exclusions. The board number excluded customers still inside their initial contract — they couldn't churn yet — which inflated the figure. The CS number counted everyone. Neither was wrong. They were answering different questions with the same label.

After cataloging: they split it into two explicitly named metrics, assigned a single definition owner (the finance analyst) for both, documented the exclusions in plain language, and set a Tier 1 SLO on the board version. The immediate payoff wasn't a better number — it was that the retention argument stopped happening. Roadmap reviews got roughly fifteen minutes back each time, and the retention-related prioritization gate finally held because nobody could challenge the definition anymore.

The quieter win came a few months later when an upstream billing event changed and the metric would have silently broken. The lineage alert caught it before the board deck went out. Pre-catalog, they'd have shipped a wrong number to the board and found out afterward.

When this level of governance makes sense

When it's worth it:

1. 1
   You have more than one squad and metrics are shared across teams.
2. 2
   Roadmap or investment decisions actually gate on specific numbers.
3. 3
   You've had at least one "wait, which number is right?" incident in a leadership setting.
4. 4
   Your dashboards have started outnumbering the people who understand them.

When it's overkill:

1. 1
   You're a small team where one person still holds all the definitions in their head and that person isn't a bottleneck yet.
2. 2
   Your metrics don't gate decisions — you're still in pure exploration.
3. 3
   You'd be governing metrics nobody uses, which is pure ceremony.

Who should not do this: teams that would use the catalog as a reason to add metrics. The catalog should shrink your metric surface, not grow it. If governance becomes an excuse to track more things "properly," you've inverted the point. A good catalog often ends with fewer metrics that everyone trusts, not more metrics that are all documented.

Starting without boiling the ocean

The failure mode when teams adopt this is trying to catalog everything at once. It stalls in week two under its own weight. A leaner path:

1. 1
   Start with decision-gating metrics only. The five to ten numbers that actually appear in prioritization discussions and board decks. If a metric never gates a decision, it can wait.
2. 2
   Fill exclusions and decision-usage first. These two fields prevent more damage than the rest combined.
3. 3
   Assign a single definition owner per metric before anything else. No owner, no catalog entry — it's not real.
4. 4
   Add lineage for Tier 1 only at the start. You don't need documented lineage for exploratory metrics nobody makes calls on.
5. 5
   Wire one alert per Tier 1 metric. Even a crude "this dropped to zero" check catches most silent breaks.

“

Start with the five to ten metrics that actually gate decisions.

Do that and you've covered the metrics that carry real decision weight, which is the vast majority of the value for a fraction of the effort.

The system, in one view

The pieces connect in a specific order, and understanding that order is what keeps the whole thing from collapsing into busywork. The schema makes each metric unambiguous. Ownership makes someone accountable for keeping it that way. Lineage makes it debuggable and safe to change. SLOs make its reliability match its importance. And decision mapping is the reason any of it matters — a metric with no decision behind it doesn't deserve governance.

When those layers are missing, the symptoms look like people problems: teams arguing, leadership distrusting dashboards, decisions made on gut feel. They're not people problems. They're the predictable result of treating metrics as dashboard outputs instead of governed assets. Build the catalog, and the arguments you keep having about which number is right simply stop showing up — which frees the roadmap conversation to be about the actual decision, where it belonged the whole time.

The pieces connect in a specific order, and understanding that order is what keeps the whole thing from collapsing into busywork. The schema makes each metric unambiguous. Ownership makes someone accountable for keeping it that way. Lineage makes it debuggable and safe to change. SLOs make its reliability match its importance. And decision mapping is the reason any of it matters — a metric with no decision behind it doesn't deserve governance.

When those layers are missing, the symptoms look like people problems: teams arguing, leadership distrusting dashboards, decisions made on gut feel. They're not people problems. They're the predictable result of treating metrics as dashboard outputs instead of governed assets. Build the catalog, and the arguments you keep having about which number is right simply stop showing up — which frees the roadmap conversation to be about the actual decision, where it belonged the whole time.