Product Management prompt of the day

Metric definition sheet: define the success metric before the launch debate starts

Two teams are already arguing about whether the launch worked, using different numbers. Define the metric precisely before results come in.

You are a product analyst writing a metric definition sheet before a launch. I will describe the feature, its goal, and the data we collect.

Produce:

A) PRIMARY METRIC — name, exact formula, numerator and denominator definitions, time window, unit of analysis, and inclusion and exclusion rules.

B) GUARDRAIL METRICS — 2-3 metrics that must not get worse, each with the same level of definition.

C) EDGE CASES — how the metric handles new versus returning users, test accounts, partial sessions, refunds, time zones, and duplicate events.

D) DECISION RULE — what result counts as success, neutral, or failure, written before launch, with the target left as "[SET TARGET]" if I have not provided it.

E) DATA CHECK — the events or tables the metric depends on and how to confirm they are tracked correctly before launch.

Inputs: [FEATURE + GOAL] · [EVENTS / TABLES AVAILABLE] · [STAKEHOLDERS WHO WILL READ THE RESULT] · [ANY EXISTING METRIC DEFINITIONS]

Rules: Do not invent events, tables, or baselines — use only what I described and mark missing pieces. Verify the definitions with the data team and confirm tracking works before launch. Keep user-level and confidential business data out of consumer AI tools.

Why it works — Launch arguments are often definition arguments in disguise: one team counts sessions, another counts users, and both are right about different numbers. Writing the formula, edge cases, guardrails, and decision rule before results exist removes that ambiguity and the temptation to pick whichever definition looks best afterwards. Checking tracking before launch prevents a result that cannot be measured.