Operations Product Validation Measurement

Product Validation Measurement Plan Prompt

Turn a success metric into a measurement plan — the behavioral signals, funnel and cohort cuts, and feedback sources that will actually prove or disprove whether a shipped product hit its target.

Overview

A success metric you can't measure is just a wish. Once you've defined what success means for a shipped product, this prompt breaks it into the concrete signals that confirm or deny it: the behavioral events to watch, the funnel and cohort cuts that isolate the answer, the feedback sources to pull from, and how to read each one against the target. It plans the measurement, not the plumbing — you supply the live data; the plan tells you what to look at, how to slice it, and what counts as hit, partial, or miss before the numbers arrive.

How to use this resource

  1. Start from the metric, not the dashboard

    Feed in the success-metric definition first; the plan should derive signals from the target, not from whatever happens to be tracked already.

  2. Lock the thresholds before the data

    Fill in what hit/partial/miss looks like up front — thresholds set after seeing the numbers are just a story.

  3. List the confounders out loud

    Name the launch spike or seasonality now, so the read on the data accounts for them instead of being fooled.

Why This Works

  • Deriving signals from the metric stops the measurement from drifting toward easy-to-track vanity numbers
  • Pre-committing hit/partial/miss thresholds removes the room to rationalize the result later
  • Naming confounders up front keeps a launch spike from being mistaken for product-market fit

Best for

  • Teams validating a shipped product against a defined success signal
  • Translating a fuzzy 'is it working?' into measurable behavior
  • Avoiding a vanity-metric read of a launch

Not for

  • Building the analytics instrumentation itself — that is engineering work
  • Pre-launch market research — this measures a product that is already live
  • Rendering the final report — that is the Product Validation Report Prompt

Use cases

  • Turning a post-launch success metric into a concrete list of signals to watch
  • Deciding the cohorts and funnel cuts that isolate whether the metric was hit
  • Setting hit/partial/miss thresholds before the data is collected

FAQ

Does this prompt build the analytics tracking or just plan what to measure?

It plans measurement, not plumbing. A stated rule keeps it to "data the team can realistically collect; do not assume instrumentation that has to be built" — building the tracking is engineering work it explicitly excludes. You supply the live data; the plan outputs a table of signals with their source and cut, telling you what to look at, not how to instrument it.

Why does it make me set hit/partial/miss before any data comes in?

So the result can't be rationalized after the fact. The READING RULES fix what counts as hit, partial, or miss against the target up front, because thresholds set after seeing the numbers are just a story. Combined with the CONFOUNDERS list — seasonality, a launch spike, a pricing change — it keeps a spike from being read as product-market fit.

Where does the success metric that feeds this prompt come from?

From the Define-the-Metric step upstream — you paste its metric definition, target threshold, and measurement window into the INPUT block. The plan then derives BEHAVIORAL SIGNALS from that target rather than from whatever's already tracked, and every signal must map back to the metric so vanity numbers that don't move the verdict get dropped.

More resources from Multi-Step Prompt Builder

Resources that pair well

Related tools

Workflows that use this resource

Guides for this resource

Tip: Save time by exploring related resources and tools that integrate with this resource.