How to Handle a Product Launch That Underperforms
Launch day dashboards rarely lie gently. They either climb the way the forecast promised, or they sit flat while the Slack channel that was popping with confetti emoji three hours earlier goes quiet. A PM recalculating the same conversion funnel four times, hoping the fourth calculation won’t match the first three, is a familiar scene on most product teams sooner or later. It usually does match. The launch has underperformed, and the next ninety minutes decide whether the team spends the following month fixing the right problem or the wrong one.
Most PM training covers how to plan a launch in detail and says almost nothing about what happens when the numbers come back soft. That gap matters, because the response in the first 48 hours shapes whether an underperforming launch becomes a fixable miss or a credibility problem that follows the team into the next planning cycle. A launch plan that spends twenty pages on go-to-market sequencing and zero on what happens if the numbers disappoint is a plan built on the unstated assumption that the launch will work — a reasonable hope, but not something to actually plan around.
First, Confirm It’s Actually Underperforming — Not Just Slow to Ramp
The instinct on launch day is to compare live numbers against the forecast and panic the moment they diverge. Resist that for the first 24 to 48 hours unless the miss is severe. Some launches ramp on a delay — a feature announced via email digest won’t show its real curve until users actually open that email, which might be two days later. Confusing “hasn’t ramped yet” with “underperforming” leads to premature interventions that waste effort and erode trust the next time a real miss gets flagged.
Define kill criteria and check-in cadence before launch, not during the anxious scramble after. Writing it explicitly into the launch plan works well: “we will not call this underperforming before the 48-hour mark unless activation is below X, and we will do a formal check-in at 24 hours and 7 days.” Agreeing on that threshold in advance, before anyone is emotionally invested in a specific number, removes a surprising amount of day-one anxiety and stops whoever has the loudest voice in Slack from declaring failure four hours in.
Diagnose Before You React
Once a miss is confirmed, the temptation is to jump straight to a fix — tweak the onboarding copy, add an incentive, escalate to engineering for a “quick win.” Resist that too. A launch can underperform for at least four structurally different reasons, and the fix for each differs enough that guessing wrong burns a sprint on the wrong problem.
Reach failure means the target audience never saw it — a segmentation bug, an email in spam, an in-app banner firing for a fraction of the intended cohort. Activation failure means people saw it and didn’t act — usually a friction or clarity problem in the flow itself. Value failure means people tried it and it didn’t do what they needed — the feature works as built but doesn’t solve the problem, a much harder and more expensive miss to fix. Measurement failure means the feature is fine and the instrumentation is lying — a broken event, a double-fired conversion pixel, a dashboard filter excluding the right cohort by accident.
A launch getting declared a failure in a leadership meeting before anyone checks whether the analytics event is firing correctly is a recognizable pattern. A tracking pixel deployed to only 60% of a rollout cohort due to a caching issue can make a feature actually performing above forecast look like a failure on the dashboard — and a team can spend a full week planning a relaunch for a problem that didn’t exist, when the real fix was one engineer and forty minutes once someone checked the raw event logs.
Who Needs to Know, and In What Order
This is where a product launch RACI earns its keep even after the launch is over — the same structure that assigns who’s responsible for execution should tell you who gets informed first when it underperforms, rather than everyone finding out simultaneously in a company-wide Slack channel that turns into public speculation.
Tell the direct manager and executive sponsor first, with a diagnosis in progress, not a fully-formed postmortem. “We’re seeing lower activation than forecast, here’s what we’re checking, we’ll have a clearer read by Thursday” beats silence followed by a polished deck at day five — silence reads as either not noticing or hiding it.
Sales and customer success need a different message if the feature was promised to specific accounts — whether to keep selling it as-is, pause outbound mentions, or manage expectations on a timeline. Marketing and PMM need to know whether external messaging should pause, especially with a paid campaign actively running against a feature that isn’t landing. This is exactly the cross-functional ownership question PM, PMM, and growth: who owns what is meant to resolve before launch day, so nobody’s guessing who has the authority to pause a campaign at 9 p.m.
Deciding Whether to Push, Pivot, or Pull Back
Once the failure mode is diagnosed, the decision is roughly a three-way fork: push through with a fix, meaningfully change the approach, or pull back and regroup. Reach and measurement failures usually mean push through — fix the plumbing, the underlying idea might be fine. Activation failures often mean iterate on the flow before concluding anything bigger is wrong. Value failures deserve real scrutiny about pulling back, because no amount of onboarding polish fixes a feature solving the wrong problem.
This mirrors the judgment call in when to kill a feature, with one difference: a fresh launch deserves a slightly longer runway than a mature feature with years of data, because day-one and day-two numbers are noisier. Recommending a kill nine days after launch based on a damning activation number is a common overcorrection — it sometimes recovers on its own once the second onboarding email in the sequence catches people who missed the first. The lesson isn’t “never kill anything early” — it’s “check whether the full activation sequence has actually finished before treating day nine as final.”
Launch Response Decision Table
| Signal | Likely Failure Mode | First Move | Who to Loop In |
|---|---|---|---|
| Low traffic to the feature entry point | Reach failure | Check segmentation, email deliverability, feature flag rollout percentage | Growth, Engineering |
| Traffic is fine, low completion of first action | Activation failure | Session recordings, funnel drop-off by step | Design, PM |
| Completion is fine, no repeat usage | Value failure | User interviews with people who tried and stopped | PM, User Research |
| Numbers look impossible given anecdotal usage | Measurement failure | Audit event firing and dashboard filters before anything else | Analytics/Data, Engineering |
| Numbers below forecast but inside first 48 hours | Possibly just ramp delay | Wait for the pre-agreed check-in point, don’t react early | None yet — hold |
When the Room Disagrees About What “Underperforming” Even Means
Not every disagreement is about diagnosis — sometimes it’s about the bar itself. A pricing-page redesign coming in at 60% of forecasted lift is a common flashpoint: a growth lead argues it’s a clear miss and wants to roll back, while the case for keeping it rests on the forecast having been built on a comparable launch from a different segment with meaningfully different intent — meaning 60% of an aggressive number is still a real, positive lift. Neither position is wrong; they’re arguing from different definitions of success never reconciled before launch, and that gap is worth naming explicitly rather than treating as a simple disagreement about whether the number is good or bad.
Going back to the original forecasting doc often surfaces the actual issue: an assumption buried in a footnote, like the comparable launch having run during a seasonal high-traffic period this one didn’t have. That reframes “is this launch a failure” into “was the forecast itself flawed” — a more productive, less personal argument. The resolution that tends to work: keep the change, adjust the forecast methodology for next time, land on a revised target with an explicit note about the wrong assumption, reviewed again in 60 days.
The broader lesson: “underperforming” isn’t a fact sitting in the dashboard — it’s a comparison against a forecast built on assumptions, and those assumptions deserve as much scrutiny as the results before anyone declares a miss.
When This Breaks: The Real Failure Mode Is Reacting Before the Data Is In
The single most common way this goes wrong isn’t a bad diagnosis — it’s skipping the diagnosis step entirely because the pressure to show movement outweighs the discipline to first confirm what broke. A VP asking “what are we doing about it” six hours after a soft launch tends to produce the same reflex: point at something and start fixing it, before knowing if that’s the actual cause. That produces busy work and little improvement, and burns goodwill when the “fix” ships and the number doesn’t move. Mind the Product’s roundup of how senior product people respond to failed launches makes a similar point: the PMs who recover well force themselves through a structured “what actually happened” pass before deciding what to do, rather than reacting to the first plausible explanation in the room.
A second common failure is running the response entirely inside the PM function without pulling in the people the RACI already designated, quietly re-litigating ownership at the exact moment speed matters most. A third is skipping a real retrospective once the dust settles — treating the recovery as the end of the story instead of feeding it into how the next launch gets forecast. A blameless postmortem on an underperforming launch surfaces the same process gaps an outage postmortem does — usually something about how the forecast was built — and skipping it means the next launch inherits the same blind spot.
A Worked Example: The Onboarding Flow That Looked Dead on Day Two
A 60-person B2B SaaS company at $9M ARR launched a self-serve onboarding redesign meant to lift activation from 34% to 45%. Day one showed 22% — worse than the old flow. The instinct in leadership Slack was to roll it back immediately.
The PM asked for 48 hours per the pre-agreed kill criteria. The diagnosis: reach was fine, traffic hitting the new flow as expected. The drop concentrated entirely at one step — a mandatory company-size dropdown added late for a sales segmentation need, rendering incorrectly on mobile and blocking roughly a third of new signups from completing the flow.
That’s a measurement-adjacent activation failure: the analytics weren’t lying, but the cause wasn’t the redesign’s core hypothesis, it was one late-added field with a rendering bug. The fix shipped in four hours. By day five, activation was at 41% — still short of target but a clear improvement, with a specific, evidence-backed explanation instead of a vague “the redesign didn’t work” that would have haunted the next roadmap conversation.
What to Do the Next Time a Launch Comes in Soft
Write the kill criteria and check-in cadence into the launch plan before launch day, not during the panic. When numbers come back soft, diagnose the actual failure mode before anyone touches the product. Use the launch RACI to control who hears what and in what order. And when the dust settles, run the retrospective even if the outcome was fine — the gap between forecast and reality is the most useful data the next launch plan will get.
References
- Mind the Product — “Lessons Learned When a Product Launch Fails” — https://www.mindtheproduct.com/lessons-learned-when-a-product-launch-fails/
- Reforge — resources on post-launch diagnosis and feature adoption — reforge.com
