Metrics tree

Skill ramanbamba/10x-pm/skills/metrics-tree

Prompts don't compound. Skills do. The open-source AI toolkit for product managers — 13 Claude Code skills + 3 red-team agents for the full PM workflow.

Install

npx -y skills add ramanbamba/10x-pm --skill metrics-tree

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Define a north-star metric, decompose it into a driver tree, and produce an instrumentation spec engineers can implement. Use when the user says "define metrics for", "what should our north star be", "build a metrics tree", "KPI framework", or "what should we measure".

SKILL.md

3.2 KB, as published. Nobody here has run it

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

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.
Ask the business model. Ads, SaaS seats, usage-based, and marketplace products have structurally different trees.
Ask what's already instrumented. A beautiful tree over missing events is fiction.

Workflow

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.
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).
Assign input vs. output. Teams own input metrics (drivers); leadership watches output metrics. Mark which is which.
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).
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.