The 7/30/90-Day Post-Launch Review That Prevents Metric Theater

A post-launch review works only if it happens more than once. Run a single check-in at day 7 for activation and bugs, day 30 for the adoption curve, and day 90 for retention and business impact — and force a go/adjust/kill decision at each. Skip the cadence and you get one celebratory recap, written the week ego is highest and evidence is lowest.

Quick Answer: Schedule three post-launch reviews — day 7 (activation and bugs, decide: fix or ship on), day 30 (adoption curve, decide: invest or reposition), day 90 (retention and impact, decide: scale, iterate, or sunset). Each checkpoint has a different question; skipping any one of them lets a bad signal hide until the quarterly business review.

Why one launch recap becomes metric theater

A single post-launch review, run once and filed away, almost always turns into metric theater — a presentation engineered to look successful rather than to surface what's actually true. It happens because the only data available at the two-week mark is early, noisy, and flattering by default: the people who show up in week one are your most motivated users, not a representative sample.

The fix isn't a better slide template. It's more checkpoints, each asking a different question. A single review collapses "did it launch," "is it being adopted," and "did it work" into one meeting, which means whichever question is easiest to answer favorably — usually "did it launch" — wins the narrative. Separating the three across 7, 30, and 90 days forces each question to be answered on its own evidence, at the point in time when that evidence actually exists.

This isn't a new idea dressed up. It rhymes with Teresa Torres's continuous discovery habits, which argue against treating any single artifact or meeting as a decision point, and with Marty Cagan's "outcomes over outputs" distinction in Inspired — a launch is an output; adoption and retention are the outcomes that actually matter. The 7/30/90 cadence is just a scheduling mechanism for taking both seriously.

What "metric theater" actually looks like

Metric theater has a recognizable shape once you've seen it a few times. It's not fraud — it's selective framing under time pressure, and it's rarely deliberate.

• Vanity numerator, missing denominator: "12,000 users tried the feature" without saying that's 3% of the eligible base.
• Cherry-picked window: reporting the single best day instead of the trend across the first two weeks.
• No counterfactual: claiming a lift without a baseline or control cohort to compare against.
• Activity mistaken for outcome: clicks, page views, or session starts standing in for the job the feature was actually built to do.
• Silence on the decision: a recap that describes what happened but never states what happens next.

If your last three launch reviews all read as unambiguously positive, that's itself a signal worth investigating — real launches have friction, and a review that never surfaces any is measuring enthusiasm, not adoption.

Day 7: activation and bugs, not celebration

At day 7, the only question worth asking is whether people who tried the feature could actually get through it — everything else is too early to read. This checkpoint is diagnostic, not evaluative: you're checking for breakage, not judging success.

Look at three things: activation rate (the share of exposed users who completed the core first-use action), error and support-ticket volume attributable to the launch, and drop-off point inside the first-use flow. If people are bouncing at a specific step, that's a UX or clarity problem you can often fix in days, not a strategy problem.

The decision this checkpoint triggers is narrow on purpose: fix a specific blocker, or confirm there's nothing blocking and let the rollout continue. Day 7 is not the moment to ask "is this working" — the sample is still self-selected toward your most motivated users, and three weeks of adoption data hasn't accumulated yet.

Common day-7 mistake: reading noise as signal

Small early cohorts move a lot on small absolute numbers — five users out of forty behaving unusually can swing a percentage wildly without meaning anything. Treat day-7 numbers as directional, not final: use them to catch outright breakage (a crash, a confusing empty state, a broken integration), not to forecast quarter-end adoption. If the numbers look great, resist writing the celebratory recap yet — you don't have enough data to know if it's real.

Day 30: read the adoption curve, not a single number

At day 30, the question shifts from "does it work" to "is usage compounding or plateauing," and the answer lives in the shape of the curve, not any single day's count. A rising curve, a flattening one, and a declining one all look similar in a single weekly total — the trajectory is where the information is.

Three curve shapes recur constantly, and each implies a different next move:

1. Compounding adoption — weekly active usage of the feature is climbing week over week, ideally with new users still discovering it organically. This supports continued investment.
2. Plateauing adoption — usage found an audience fast and then flattened. This usually means you've saturated the segment that had the underlying need without a broader distribution or discovery push.
3. Declining adoption — a spike at launch (often driven by an announcement or in-app nudge) followed by a steady drop-off as novelty wears off and the underlying job isn't being met.

Segment the curve by acquisition channel and by cohort (users who joined week 1 vs. week 3) rather than looking at an aggregate line — an aggregate can look flat while a genuinely strong new-user cohort is being diluted by a weak early one, or vice versa. This is also the point to revisit whether you shipped to the right slice of the base in the first place; the reasoning in a launch tiers framework is worth rereading here, since a Tier 3 rollout evaluated with Tier 1 adoption expectations will always look disappointing.

What decision day 30 triggers

Nielsen Norman Group's research on feature adoption curves consistently shows that a genuinely useful feature's usage tends to flatten upward — settling into a steady, higher baseline — while a novelty-driven one flattens toward its pre-launch baseline. The distinction matters more than the raw week-4 number.

The day-30 review is also the natural point to loop in go-to-market partners on what the data is actually saying, since the PM-PMM handoff usually assumed a certain adoption trajectory when messaging and enablement were built — if the curve looks different than planned, that handoff needs a second pass, not a shrug.

Day 90: retention and business impact, the only checkpoint that can say "it worked"

Day 90 is the first point where you can credibly claim outcome, because it's the first point with enough elapsed time to separate durable use from trial. Anything claimed as "impact" before this checkpoint is a forecast, not a result — say so explicitly in any interim reporting.

At 90 days, look at retention (are week-1 adopters still using it in week 12?), the metric the feature was built to move (tied back to the original hypothesis, not a proxy), and whether that movement holds up against a control or baseline cohort. This is where the customer journey work done pre-launch earns its keep — if the feature targeted a friction point in a specific stage of the journey, day 90 is when you can check whether that stage's emotion curve actually shifted for users who adopted versus those who didn't.

The day-90 decision menu

• Scale: retention holds, the target metric moved, and the effect survives scrutiny against a baseline — expand distribution, invest in the next iteration, consider it durable.
• Iterate: retention is soft or the metric moved less than hypothesized, but the underlying job is clearly still real — narrow the feature, fix the specific friction the data points to, and re-review at the next 90-day mark rather than treating this as final.
• Kill or deprecate: retention decayed to near-zero, the target metric didn't move, and the underlying job doesn't reappear when you check the jobs-to-be-done hypothesis against actual usage — sunset it deliberately rather than letting it linger as a maintenance cost nobody wants to own.

Being willing to write "kill" in a document with your name on it is the actual test of whether this cadence is diagnostic or theatrical. Teams that never reach a kill decision at day 90 aren't launching better features — they're just not looking hard enough, or the incentives around the review reward optimism over accuracy.

The 7/30/90 review template

A usable template is short enough to fill in fifteen minutes and specific enough that two different PMs would fill it out the same way given the same data. Use one shared template across every launch so patterns become visible across launches, not just within one.

Each row should end with one paragraph of narrative and one explicit decision — not a status update with no verb attached to it. "Adoption is steady" is not a decision. "We are narrowing eligibility to power users and re-reviewing in 30 days" is.

Who should be in the room at each checkpoint

Day 7 is usually a small group — the PM, engineering lead, and support or CS if ticket volume is relevant. Day 30 should widen to include design and the go-to-market partner who owns messaging, since curve shape often implies a messaging or targeting fix rather than a product one. Day 90 deserves the widest audience — this is the meeting that should have replaced the single celebratory recap, and it should include whoever makes the scale/iterate/kill call stick, not just whoever presents it.

Making the cadence actually happen

The reason most teams default to a single recap isn't disagreement with this framework — it's that nobody owns scheduling the follow-ups, and by day 30 everyone's attention has moved to the next launch. The cadence only works if the checkpoints are scheduled at launch time, not chased down later from memory.

This is a scheduling and knowledge-retention problem as much as an analytical one, and it's worth naming honestly: Prodinja's Reminders can be set at launch to notify you at the day-7, day-30, and day-90 marks so the checkpoints don't depend on anyone remembering three months out, and the Library is designed to hold each checkpoint's findings against the launch record so the next launch's review can actually reference what the last one learned, rather than starting from a blank page every time.

If you're deciding how big a launch should even be before any of this cadence applies, that sizing decision is really a separate exercise — see the guidance on choosing the right launch tier — and the full pre-launch-through-review arc is covered in the GTM launch complete guide.

Key Takeaways

• One post-launch recap almost always becomes metric theater — the data available at week two is inherently self-selected and flattering, and a single meeting collapses three different questions into one.
• Day 7 is diagnostic, not evaluative — check activation rate, error volume, and drop-off point; the decision is fix-or-continue, not a verdict on success.
• Day 30 is about curve shape, not a single number — compounding, plateauing, and declining adoption each imply a different move, and segmenting by cohort and channel reveals what an aggregate line hides.
• Day 90 is the only checkpoint that can credibly claim impact — retention and target-metric movement against a baseline decide whether to scale, iterate, or kill.
• A shared template across launches builds institutional memory — the second launch should be easier to review than the first because the first one's findings are still findable.
• Being willing to write "kill" is the actual test of whether a review is honest — a cadence that never produces that decision may just be under-scrutinizing every launch.