---
title: "Stop shipping blind - measure the launch in week one"
canonical_url: https://ampl.webclat.com/use-cases/measure-the-launch-in-week-one
description: "Ship a feature and know within days whether it's working, not next quarter. Instrument the launch metric before you ship, not after someone asks how it's doing."
source: Webclat | Amplitude Solutions (official Amplitude partner, independent consultancy)
---

# Stop shipping blind - measure the launch in week one

**In short:** We define the one metric a launch needs to move and instrument the events behind it before the feature ships, so the first week produces a real answer instead of a shrug. Most 'we don't know if the launch worked' problems are actually 'we forgot to instrument it' problems.

## The situation

A feature ships, two weeks pass, and when leadership asks how it's doing the honest answer is 'we're not totally sure yet.'

## The pain

Launches get judged on anecdote and Slack sentiment instead of data, so a genuinely bad feature can survive on good vibes and a genuinely good one can get killed because nobody could prove it worked.

## What we implement

We define the launch's success metric and its supporting events before code ships, then build the dashboard that reads them from day one - what's called instrumentation-first launch measurement - so the answer exists the moment someone asks for it.

## What you get

- A specific, agreed answer to 'is the launch working' within the first week, not the next quarterly review
- A go/no-go decision made from data instead of the loudest opinion in standup
- A record of what actually happened, so the next launch doesn't repeat the same guess

## Illustrative

A team that historically judged launches by support-ticket volume alone might find, once the real usage metric is instrumented, that a quiet feature with zero complaints is also barely used - a very different verdict than 'no news is good news' would have given. (Illustrative scenario - not a measured result.)

## FAQ

### What if we've already shipped and only realize now that we didn't instrument it?

Instrument it immediately - you'll have a partial week of data rather than none, and every week forward from that point is real signal. What you lose is the ability to compare against a true pre-launch baseline, which is the argument for instrumenting before the next launch, not a reason to skip it now.

### How do we pick the one metric that matters for a launch?

Ask what the feature was built to change, not what's easiest to measure - adoption, a specific action rate, or a downstream retention effect are the usual candidates. If the team can't agree on one metric before shipping, that disagreement is worth resolving before the launch, not after.

Related: [Amplitude Experiment: web vs. feature flags](https://ampl.webclat.com/blog/amplitude-experiment-web-vs-feature), [Product analytics metrics, defined](https://ampl.webclat.com/glossary/product-analytics-metrics), [Amplitude implementation sprint](https://ampl.webclat.com/services/amplitude-implementation)