Gtm Metrics Architect

GTM Metrics Architect

The most common measurement failure in GTM isn't having too few metrics — it's reporting a metric at the wrong level of the ladder and letting it stand in for a level it doesn't actually reach.

Inputs to gather

Required:

• The actual dashboard, report, or metric list in question — paste it, describe it, or list the metric names

Helpful, not blocking:

• Who the audience is (board, exec team, internal ops) and how often they see it
• What decision the report is supposed to support — if nobody can name one, that's itself the finding

If none of this is available: ask directly — "what decision is this report meant to drive, and who's making it?" If the answer is vague, the report likely fails the audit before a single metric is even classified.

The metric-class ladder

Two cross-cutting classes apply at any level:

• Efficiency — magnitude divided by resource spent (e.g. pipeline $ per rep, cost per lead)
• Readiness — capability to perform, independent of current output (e.g. team certification levels, database completeness, capacity utilisation)

The failure to catch: reporting an Activity or Output number in a context that implies Impact. "Engagement is up" is an Activity claim; it is not evidence of pipeline health, and presenting it as if it were is the single most common way exec reporting loses credibility.

Apply the ladder at the right altitude

A metric only belongs on a dashboard if a real decision at that level depends on it:

Organisation → Programme → Function → Tactic-type → Tactic

A Tactic-level metric (e.g. subject-line open rate) has no business on an Organisation-level board — it doesn't inform any decision made at that altitude. Conversely, an Org-level Impact metric is too coarse to diagnose which specific tactic to fix.

Build sequence

1. Strategy — define scope, name the stakeholders, and state the decisions the measurement system needs to support before picking metrics.
2. Execution — build the reporting, test it against real decisions, launch, train the people who'll read it.
3. Evolution — monitor whether it's actually being used to decide anything; refine or retire metrics that aren't.

How to apply it

1. Audit the existing dashboard/report. For each metric: what class is it (Activity/Output/Outcome/Impact/Efficiency/Readiness)? What level is it aimed at?
2. State the decision. For each metric, name the specific decision it's meant to drive. If none exists, it's decorative — cut it, or attach it to a real decision.
3. Check for class-inflation. Flag any Activity/Output metric being narrated as if it proved Impact.
4. Rebuild at the right altitude. Match each surviving metric to the organisational level where its decision actually gets made.

Output format

• Metric-by-metric classification (class + level)
• Decision each metric drives — or "none found, recommend cutting"
• Class-inflation flags — where Activity/Output is being read as Impact
• Rebuilt metric set, organised by decision-owner and level

Skill 5 of 6 diagnostic skills in the GTM Skills collection by Christopher Swarup — GTM Ops leader, 15+ years in RevOps/MOPS across Finastra, Equinix, Nutanix, Pleo, Contentsquare and DevRev.