Use this when helping a client define what to measure and how to structure their metrics for a product or initiative.

How it works

1. You provide the client name, product or initiative, objectives, and relevant context
2. The skill designs a metrics framework with North Star, input metrics, health guardrails, and business metrics
3. It returns a client-ready metrics dashboard specification with definitions, targets, alert thresholds, and review cadence

Prompt

You are designing a metrics framework as part of the practitioner's strategic-comms-roadmapping engagement. Before writing, read knowledge/voice-tone-guide.md -- use the client-facing voice (clear, structured, professional -- this will be shared with the client's team).

Inputs I will provide:

• Client: {{CLIENT}} (company name and engagement context)
• Product: {{PRODUCT}} (the product, feature, or initiative being measured)
• Objectives: {{OBJECTIVES}} (business goals, OKRs, or strategic priorities the metrics should track against)
• Context: {{CONTEXT}} (current analytics setup, team maturity, tools in use, any constraints)

Step 1: Understand the measurement landscape

Before defining metrics, clarify:

• What decisions will these metrics inform?
• Who will be looking at this dashboard (executives, PMs, engineers, the whole company)?
• What is the team's current data maturity (no analytics, basic events, mature pipeline)?
• What tools do they have or are willing to adopt?
• Is their data warehouse-native (Snowflake, BigQuery, Databricks, Redshift) with a composable-CDP / reverse-ETL setup, or copied into a siloed analytics tool? In 2026 the warehouse is increasingly the source of truth (Hightouch-style), and the dashboard should read governed metrics from there rather than a parallel copy.
• Do they have an AI-insights layer (Amplitude auto-recommendations, Mixpanel Spark AI) that surfaces anomalies and churn predictions without being asked? If so, the dashboard plugs into it; if not, flag the gap.

If any of these are unclear from the inputs, note them as [CLARIFY WITH KATE: ...].

Step 2: Pull relevant frameworks

Read knowledge/pm-execution-templates.md for metrics framework structures This skill uses with clients.

Read knowledge/pm-growth-frameworks.md, specifically:

• North Star Metric methodology -- how to identify the single metric that captures core value delivery
• AARRR / Pirate Metrics for acquisition-through-revenue coverage
• Input metrics concept -- the levers that drive the North Star

Step 3: Design the metrics framework

North Star Metric

• Metric: [name]
• Definition: [exact calculation -- numerator, denominator, time window]
• Why this metric: [how it captures core value delivery for {{PRODUCT}}]
• Current baseline: [if known, or [NEEDS DATA]]
• Target: [goal value with timeframe]

Input Metrics (3-5)

The levers that drive the North Star. For each:

Health Metrics

Guardrails that ensure the team is not optimizing the North Star at the expense of product health:

Business Metrics

Revenue, cost, and unit economics the leadership team cares about:

Step 4: Capture baseline snapshot

Before designing the dashboard layout, document current-state measurements for each proposed metric. This establishes the "before" so the team can track improvement.

If the team has no baseline for a metric, that's critical to surface now -- you can't measure improvement without a starting point. Flag each gap with [NEEDS INSTRUMENTATION]. If more than half the metrics have no baseline, recommend an instrumentation sprint before dashboard design.

Step 5: Specify the dashboard layout

Provide a visual layout recommendation:

• Top row: North Star with trend indicator
• Second row: Input metrics with sparklines
• Third row: Health guardrails
• Bottom row: Business metrics

Include which visualization type suits each metric (line chart, bar, single number, funnel).

Step 6: Define the operating rhythm

Review Cadence

• Daily: which metrics to check and who checks them
• Weekly: which metrics to review in team standups
• Monthly: which metrics to present in leadership reviews
• Quarterly: strategic recalibration -- are these still the right metrics?

Alert Rules

For each alertable metric:

• What threshold triggers investigation
• Who gets notified and through what channel
• Expected response time

Revenue Attribution Layer

For each input metric, estimate the financial impact so the dashboard connects operational movement to business outcomes:

• Sensitivity analysis: For each input metric, estimate: "If this metric improves by 10%, the expected revenue impact is approximately $X/month." Ground estimates in the client's unit economics where available, or flag as [NEEDS DATA: revenue sensitivity estimate requires baseline conversion and ARPU figures].
• Unit economics integration: Map where CAC, LTV, and payback period sit in the metric hierarchy. Input metrics should ladder up: acquisition inputs drive CAC, retention inputs drive LTV, and the ratio between them determines payback period. If the dashboard does not make this connection visible, flag it.
• Financial leading indicators: Identify which input metrics predict revenue 30, 60, and 90 days out. Activation and engagement metrics typically lead by 30-60 days; retention and expansion metrics lead by 60-90 days. Label each input metric with its revenue lead time.
• Threshold annotations: For each alertable metric, add a financial annotation: "If [metric] drops below [threshold], expected revenue impact is $X/month based on [assumption]." This turns operational alerts into business urgency.

Step 6.5: Wire in the AI-insights layer and semantic-layer handoff

In 2026 the dashboard is not just a wall of numbers the team pulls and reads. Warehouse-native platforms ship an AI layer that surfaces anomalies, predicts churn, and answers natural-language questions (Amplitude auto-recommendations, Mixpanel Spark AI) without anyone framing the right query first. That changes the human's job. The team's work is no longer "pull the report." It is "validate, contextualize, and decide on what the AI already surfaced." Design the dashboard for that reality.

For each section of the framework, specify two things:

1. What the AI watches. Which metrics get auto-anomaly detection and predictive alerts (for example, churn-risk scoring on retention inputs, spike/drop detection on activation). The AI surfaces the signal. Do not make a human eyeball the line chart to catch it.
2. What the human validates. For every AI-surfaced insight, name the validation step: is the anomaly real or an instrumentation artifact, what is the business context, what decision does it trigger? The dashboard should route each AI alert to an owner who confirms or dismisses it, not let it auto-act.

Semantic-layer handoff. A metric defined three different ways across three dashboards is worse than no metric. Hand off each metric definition from Step 3 to the client's semantic layer (dbt Semantic Layer, Cube, or the platform's governed metrics store) so the AI and every dashboard read the same governed definition. This is now competitive infrastructure: it is what keeps AI-surfaced insights trustworthy and consistent. If the client has no semantic layer, flag it: [NEEDS SEMANTIC LAYER: metric definitions live only in this doc and will drift -- recommend a governed metrics store before AI insights can be trusted].

Step 7: Validate metric quality

For each metric in the framework, check against these criteria:

1. Understandable -- does it create a common language across the team?
2. Comparative -- can it be tracked over time, not just as a snapshot?
3. Ratio or rate -- is it a ratio (more revealing) or a raw number (less useful)?
4. Behavior-changing -- if this metric moves, will the team actually do something different?

Flag any metric that fails these checks:

For defining the North Star Metric that anchors this dashboard, use the north-star-metric skill. For setting OKRs around these metrics, use okr-workshop.