Name the moments that signal value in your product.
Interviews you about your product, names the events that mean real value, tiers each by reliability, and rolls them into a short capability list your analyst can score.
In plain English: “What should my product analyst actually measure?”
Inside: The value-moment finder, the Tier 1/2/3 reliability test, the capability rollup, and the adoption rubric.
Install it in one line, or paste it in.
~/.claude/skills/ and runs automatically when it is relevant.Connect your context. Set it to your motion.
it reads your live event stream, so it names real events instead of ones you hope exist, and flags the ones that barely fire.
it checks event volume and reliability across the whole base before it trusts an event.
it maps the taxonomy to the journey you already designed.
This was built to be product-agnostic. Set these to your product:
The taxonomy is yours. The skill's job is to help you find the 5 to 15 moments that actually predict retention and expansion in your product, and to throw out the ones that just look busy.
| Set this | What it is | Default / Example |
|---|---|---|
| ANALYTICS tool | your product-analytics connector | |
| VALUE_MOMENTS | the actions that signal real value | your own list (the skill helps you find them) |
| CAPABILITIES | how events roll up into features | 5 to 15 named capabilities |
| RELIABILITY_BAR | volume/consistency an event needs to be trusted | fires for most active accountsmost weeks |
| GRAIN | how you group users into an account | domainworkspace idorg id |
| ANTI_SIGNALS | events that look like value but are not | loginspage viewspassive opens |
Everything the skill does, in full.
Turns "what should we actually measure?" into a taxonomy your team can trust. It interviews you about your product, names the events that signal real value (not vanity clicks), tiers each one by how reliably it means what you think it means, and rolls the whole set into a short list of capabilities an analyst can score. The output is the source of truth every downstream product read runs on, so two people asking "how are they using us?" get the same answer.
- 1Name the value moments
Start from the outcome, not the feature. Ask what a customer has to do repeatedly for the product to be working for them. Those repeated, outcome-linked actions are your candidate value moments. A click is not a value moment. A completed core action that ties to why they bought is.
- 2Tier every event by reliability
Every candidate event gets a tier: TIER 1 (fires cleanly, means exactly one thing, high volume), TIER 2 (useful but noisy or lower volume, use with care), TIER 3 (a trap, looks like value but is not, or double-counts a Tier 1). Name the traps out loud so no one builds a read on them later.
- 3Roll events into capabilities
Group the trusted events into a short list of capabilities, the features that actually signal value. Each capability maps to its raw events explicitly, so an analyst can score adoption per capability instead of drowning in event names.
- 4Set the adoption rubric
Define what POWER, ESTABLISHED, EMERGING, DORMANT, UNTOUCHED, and NEVER-ADOPTED mean for each capability, in your product's real numbers. This is the rubric every product read reuses, so adoption means the same thing every time.
- 5Flag the anti-signals
Call out the events that inflate a picture: logins, page views, passive opens, anything that rises when nothing of value happened. A baseline "any activity" signal is fine as a floor, never as proof of value.
- Every trusted event has a named tier and a one-line reason. No untiered events in the taxonomy.
- Traps are named explicitly, not quietly dropped.
- Each capability lists the exact raw events it rolls up, never a vague label.
- The adoption rubric is in your product's real numbers, not borrowed defaults.
- No event is trusted on volume it does not have. A rare event is Tier 2 or 3, never Tier 1.
EVENT TAXONOMY · [your product] · built [date] Capability Raw events (trusted) Tier Core action action_completed 1 Automation rule_created, rule_ran 1 Templates template_used 2 (noisy: counts drafts) AI assist ai_compose_accepted 1 Integrations integration_connected 2 (low volume) TRAPS (do not build reads on these): - session_start looks active, means nothing about value - page_view inflates any "usage" number Adoption rubric (Core action): Power >= 5 completions/week · Established 1-4 · Emerging <1 · Dormant used then stopped 14d+ · Untouched never fired Next: instrument ai_compose_accepted server-side; it is Tier 1 logic but currently client-only, so ~15% of fires are lost.
The tiers, the reliability bar, and the adoption thresholds are yours to set. The examples here suited a weekly-rhythm SaaS product. If your product is used in bursts or on a monthly cycle, retune the thresholds. The logic, name the outcome, trust events by reliability, roll up to capabilities, does not change.
Where an operator takes this next.
The taxonomy is step one. Here is where an operator takes it once it holds.
You define value once, and every downstream read inherits it.
Feed the taxonomy to a product-usage analyst skill so every account gets scored on your real capabilities, on demand or nightly from Amplitude or your warehouse.
Have a scheduled Claude task re-check event volumes weekly and flag when a Tier 1 event starts dropping fires, so instrumentation bugs surface before they corrupt every read.
Push the taxonomy to Notion or your docs so product, CS, and sales all score adoption the same way instead of arguing about definitions.
One skill is the on-ramp.
A single skill does one job. Chained into a playbook, or run as a full build, it becomes a system. Here is where this one plugs in.