Metrics Tree

Metrics Tree

Define metrics that measure value delivered, decompose them into drivers a team can move, and specify the events needed to compute them — so the metric exists in a dashboard, not just a slide.

Before defining

1. Ask what the product's core value moment is — the thing a user does when the product has worked for them. The north star should count that, not activity around it.
2. Ask the business model. Ads, SaaS seats, usage-based, and marketplace products have structurally different trees.
3. Ask what's already instrumented. A beautiful tree over missing events is fiction.

Workflow

1. Propose the north star with 2 alternatives considered and rejected (show the reasoning — the rejections teach the team what the metric protects against). Test each candidate: Would this number go up if we made the product worse in a profitable way? If yes, it's gameable — fix or guard it.
2. Decompose into a driver tree, 2–3 levels deep. Each node must be: movable by a team, measurable from real events, and arithmetically connected to its parent (state the relationship: sum, product, funnel rate).
3. Assign input vs. output. Teams own input metrics (drivers); leadership watches output metrics. Mark which is which.
4. Add guardrails. For each driver, name the metric that catches the ugly way to move it (e.g., driver: sessions/user; guardrail: task completion rate).
5. Write the instrumentation spec. For every leaf node: event name, trigger, properties, and current status (exists / needs adding). Use consistent object_action naming.

Output format

# Metrics — [product], [date]

## North star
**[Metric]** — [exact definition, including counting rules and time window]
*Why:* [ties to value moment]
*Rejected:* [alt 1 — why not] · [alt 2 — why not]
*Gaming check:* [how it could be gamed, and the guardrail]

## Driver tree
[Indented tree, each node with: metric, relationship to parent, input/output tag, owning team]

North star
├── Driver A (product: A = B × C) [output]
│   ├── Driver B [input — Team X]
│   └── Driver C [input — Team Y]
└── ...

## Guardrails
| Driver | Ugly way to move it | Guardrail metric |
|---|---|---|

## Instrumentation spec
| Metric | Event name | Fired when | Properties | Status |
|---|---|---|---|---|

## Baseline & review
[Current values where known; proposed review cadence; owner of the metrics doc]

Quality bar — self-check

• North star counts value, not activity. Sign-ups, sessions, and page views fail unless the product's value literally is attention.
• Every definition is exact. "Active user" without the action + window that defines "active" fails.
• The tree's arithmetic works. Parent = stated function of children; no orphan vanity metrics.
• Every driver has a guardrail.
• The instrumentation spec is implementable as written — an engineer should not need a follow-up meeting to name the events.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: ramanbamba
• Source: ramanbamba/10x-pm
• License: MIT

Install and usage instructions live in the source repository linked above.