product-metrics — the Metric Brief
The gap the old pipeline acknowledged without filling: product-strategy demands that "with no
metric, the problem is not clear", but no tool helped build that metric — it handed off to a metrics
coach that never existed. This is that station: it defines the candidate North Star, builds the tree
of levers that hold it up, and gives every active hypothesis a number, a way of measuring it and a
value as of today.
When it is invoked
| When | From / to |
|---|---|
The metric gate of product-strategy does not pass ("with no metric, the problem is not clear") |
Entry from product-strategy (.claude/skills/product-strategy/SKILL.md) |
| The Metric Brief is written | Exit toward prd (.claude/skills/prd/SKILL.md) — the strategic context/ of the node is completed with the metric already defined |
| With no prior gate | Invocable on its own, over the product node already loaded |
Both neighboring stations are already installed in this pack: naming them here is real, not invented — unlike the old reference to a metrics coach with neither spec nor owner.
The interview
It is run with the pressure method of .claude/skills/grill/SKILL.md#method — cited by path, never copied.
The five ingredients (counter-question with an example, pressure capped at 1-2 attempts, escape
hatches, evidence hierarchy, every gap recorded) are applied exactly as described there.
Before asking: if the loaded product node has dated research from product-strategy (a Discovery
Brief with hypotheses), read it — the active hypotheses come from there, they are not asked again.
If there is no prior research, they are asked directly.
Four steps, in this order:
1. Candidate North Star
A single candidate North Star metric, with the reason in one line: which product decision it moves, not why "it matters". Faced with an answer that names no decision ("because it measures success", "because it is the one everybody looks at"), grill returns it with a counter-question.
2. Metric tree
The North Star on top, its levers below — the variables that, if they move, move the North Star. Every lever carries where it is measured (which event, which table, which source — the where, never how to instrument it: that belongs to the body of the user's product, not to this tool). A lever with no where-it-is-measured is a gap, not a complete line.
3. Metric per active hypothesis
For each active hypothesis (the ones product-strategy brings, or the ones raised here if there is
no prior research): which number validates or refutes it, measured how, against what value as of
today.
Hard rule: no value with a source, no data. A value as of today that the operator cannot cite
with its origin (a dashboard, a measurement, a dated figure) is not written as if they could: it is
recorded as a gap, with who closes it — the same gap format grill uses. Inventing the number so the
row looks complete is the same incomplete scan presented as complete that the rest of the system
forbids.
4. Antimetrics
What should not get worse while the North Star improves, with the threshold that triggers the alarm — a number or a verifiable condition, never "if it gets much worse".
The vanity metric
After every proposed metric (North Star, lever or hypothesis metric), this question is applied: which decision does this number change, in whichever direction it moves?
If there is no answer, or the answer is another metric ("it changes how we see growth"), it is a vanity metric: it is said outright — "this is a vanity metric: it changes no decision" — and the concrete decision the metric should move is requested before accepting it into the Brief. It is neither discarded in silence nor accepted to avoid interrupting the interview.
The Metric Brief
It closes by writing the deliverable as dated research of the loaded product node, in:
research/<YYYY-MM-DD>-metric-brief.md
Dated, never overwritten — the same criterion the research folder of this repo already uses. The
path falls inside content: */products/*/research/*.md line of the brain's own tree.md: no new
glob and no resolver row are needed. Without a product node, this same file —
<YYYY-MM-DD>-metric-brief.md — is what lands in the current folder instead.
The Brief carries these four sections, in this order, each with its literal heading:
## Candidate North Star
## Metric tree
## Metric per hypothesis
## Antimetrics
- Candidate North Star: the metric and the reason in one line (which decision it moves).
- Metric tree: the North Star on top, each lever on one line with its where-it-is-measured.
- Metric per hypothesis: one entry per active hypothesis — which number, measured how, value as of today or a gap with an owner.
- Antimetrics: each one with its alarm threshold.
If the interview detected a vanity metric along the way, the Brief leaves it written anyway —with the label "(vanity: it does not change [the decision that was asked for and never got an owner, if it was left unclosed])"— and never deletes it in silence.
What this deliverable does not claim
The Metric Brief neither creates nor demands a new canonical file of the product node: it is dated
research, it adds to what is already there, and it neither replaces nor forces re-versioning a live
file of the context/. If a metrics canonical file were ever needed (a live metrics.md that gets
overwritten), that decision is approved by the operator — not by this tool.
Destination
The skill resolves the destination before producing the deliverable, never after. Three cases, two destinations:
- A product node is loaded: the deliverable goes to
research/<YYYY-MM-DD>-<name>.mdof that node. - There is a brain, but no product node — no workspace yet, or a workspace without one: the deliverable is written to a file in the current folder.
- There is no brain at all: the deliverable is written to a file in the current folder.
With no product node, the file is written to the current folder anyway. The closing message names only the path it just wrote and stops there — that is the normal way this skill ends, not an anomaly to qualify.
This skill never asks which destination to use, and it never invents a third one.
The rest of the pack installs one skill at a time. Look at .claude/skills/ first and offer only
the ones that are not there — once per session: the first time this skill closes in the session,
never again on a later close of the same or another deliverable:
grill—npx skills add pedroromeroluna/ai-first-product-skills --skill grillprd—npx skills add pedroromeroluna/ai-first-product-skills --skill prdproduct-strategy—npx skills add pedroromeroluna/ai-first-product-skills --skill product-strategy
The whole pack at once: npx skills add pedroromeroluna/ai-first-product-skills. That command installs what the pack offers;
anything listed above it is installed by naming it.