A product metric can look familiar while meaning something different in every dashboard. Before a trend changes a roadmap or launch decision, the team needs to agree on the behavior, population, denominator, time window, source, exclusions, and limits behind it.

Strawberry can work across product documents, dashboards, event definitions, experiments, customer evidence, and approved data tools. Your companion can reconcile competing definitions, keep data-quality gaps visible, and remember the accepted metric framework for the next review.

Start with the product decision

Clarify the product outcome, user behavior, feature or flow, population, time horizon, decision, existing measures, and source systems. Decide whether the team needs a metric framework, a performance review, or both.

Want to try it?

Ask your Strawberry companion: “Define the product metrics this decision needs, review the performance we can support with current data, and make the definitions, gaps, and implications clear.”

Skill

Define and review product metrics

Define the smallest useful metric framework, review supported performance, or do both for the decision in front of the team.

Make each metric complete

Definition elementQuestion to answer
Behavior or outcomeWhat does this measure represent in the product?
Population and calculationWho is eligible, what are the numerator and denominator, and how are identity and duplicates handled?
Source and freshnessWhich event or record owns the value, how is it transformed, and when was it updated?
Time and segmentationWhat window, cohort, attribution rule, segment, and exclusions apply?
Baseline, target, and guardrailsWhat comparison or threshold is accepted, and which quality, trust, retention, reliability, or cost measures protect it?

Reconcile conflicting labels, event names, funnel stages, filters, and time zones. Flag sampled, modeled, delayed, missing, backfilled, or recently changed data before interpreting it.

Build the smallest useful framework

  • One outcome measure tied to the product decision.
  • The few input or leading measures that can explain movement.
  • Necessary guardrails.
  • Relevant funnel, retention, quality, or reliability measures.
  • The segments or cohorts most likely to hide a materially different result.

Explain why each measure belongs, how it is calculated, which source owns it, what gap blocks it, and which decision it could change. Do not build a large scorecard simply because the data exists.

Review performance without inventing causality

Where reliable data exists, review baselines, trends, seasonality, funnels, cohorts, segments, concentration, anomalies, experiment context, and changes in product or instrumentation.

Separate observed movement, plausible explanations, alternatives, and product implications. Do not hide a thin denominator behind a percentage or treat correlation as a product cause.

Deliver the decision and the gaps

Return the outcome and decision, complete metric definitions, source quality, baseline and supported findings, hypotheses, alternatives, implications, and the next decision or experiment. Put instrumentation and data gaps into separate proposed work.

Use shared Data capabilities when SQL, joins, statistics, or validation becomes substantial. A metrics review does not approve instrumentation, production-data, dashboard, experiment, or product changes.

Official Strawberry skill
Copy skill file Download skill file
name
review-product-metrics
description
Define a practical product metric framework or review existing performance by checking metric definitions, source quality, baselines, trends, funnels, cohorts, segments, hypotheses, guardrails, and implications. Use when a product team needs measurable outcomes and a decision-ready view; keep deep data engineering and instrumentation changes separate.

Review Product Metrics

Define the measures a product decision needs, review the performance that already exists, or do both. Make definitions and data quality visible before drawing conclusions.

1. Start with the product decision

Clarify the product outcome, user behavior, feature or flow, population, time horizon, decision, known metrics, and source systems. Determine whether the team needs a metric framework, a current performance review, or a framework followed by a review.

Use product strategy, specifications, customer evidence, prior decisions, existing dashboards, event documentation, experiments, and relevant business context when available. Avoid adopting a generic North Star, funnel, or benchmark without showing why it fits this product decision.

2. Inspect definitions and sources

For every material metric, establish:

  • the behavior or outcome it represents;
  • numerator, denominator, unit, eligibility, identity, and deduplication rules;
  • event or record sources, ownership, freshness, and known transformations;
  • time window, attribution or cohort rule, segment, and exclusions;
  • baseline, target or decision threshold when one is accepted; and
  • guardrails that protect quality, trust, retention, cost, or another important outcome.

Reconcile conflicting dashboard labels, event names, funnel stages, filters, and time zones. Flag sampled, modeled, delayed, missing, backfilled, or recently changed data.

When deep extraction, SQL, joins, statistical analysis, or data validation is needed, use available shared Data capabilities. Instrumentation design and implementation remain separate Engineering work.

3. Define a useful framework

When the measures are unclear, propose the smallest coherent framework that can answer the decision:

  • one outcome measure;
  • the few input or leading measures that explain movement;
  • necessary guardrails;
  • relevant funnel, retention, quality, or reliability measures; and
  • the segments or cohorts most likely to hide a materially different result.

Explain why each metric belongs, how it is calculated, which source owns it, what current gap blocks it, and what decision it could change. Do not create a large scorecard simply because data is available.

4. Review current performance

Where reliable data exists, examine baselines, trends, seasonality, funnels, cohorts, segments, concentration, anomalies, experiment context, and changes in product or instrumentation.

Separate observed movement, plausible explanation, and implication. Check alternative explanations and qualitative evidence. Do not claim causality from correlation, ignore a definition change, or hide a thin denominator behind a percentage.

5. Validate and deliver

Check calculations, units, filters, denominators, source freshness, segment coverage, and reproducibility. Compare a sample back to the source when practical. If the data cannot support the requested conclusion, say what is known, what is not, and what would resolve it.

Deliver:

  • the decision and product outcome in scope;
  • the metric framework and complete definitions;
  • source quality, coverage, and material limitations;
  • current baseline, trend, funnel, cohort, or segment findings where supported;
  • hypotheses and alternative explanations;
  • product implications and the next decision or experiment; and
  • instrumentation or data gaps as separate proposed work.

Follow Strawberry's active scoped permission for every source, account, destination, and action. If the current permission covers updating an approved metric document or review artifact, apply and verify it; otherwise return a draft or ask. Do not change instrumentation, production data, dashboards, experiments, or product behavior as part of this review.

Preserve accepted definitions, source ownership, review cuts, and decision thresholds for the next cycle. Revalidate them when the product, population, or instrumentation changes.