How to fail a product launch in 5 easy steps (I did all five)

The launch that looked perfect on paper

The feature itself was clean. No bugs, specs signed off, QA had approved it. It adjusted how a document got processed based on an existing account setting; simple on paper, one condition, one new behavior.

I warned people. One in-app message, a week before launch, explaining what was changing and what to check.

At launch, over 30,000 accounts had a setting that no longer matched the new behavior. Their automation stopped working the way they expected. Not because anything broke but because nothing had changed on their end, while everything had changed on mine.

The gap between "I warned them" and "they knew"

This wasn't a specs problem or a QA miss. It was a gap between sending information and that information actually landing — and that gap is bigger than most launch plans account for.

One message, sent once, competes with everything else in someone's day. Most people don't read in-app notifications closely, especially about a setting they haven't touched in months and don't think about. "I told them" and "they knew" feel like the same thing when you're planning a launch. They aren't.

What I'd do differently

1. A single channel is not a strategy — it's just a channel.
An in-app message informs. It doesn't confirm anyone read it, understood it, or acted on it. A real change management plan treats the message as the start of the job, not the whole job it defines what "success" looks like (a setting changed, an action taken) and tracks toward that, not just toward "message sent."

2. Targeting has to be designed before the build, not improvised after the incident.
The accounts that would break were identifiable before launch. Their configuration already showed the mismatch. Being able to isolate exactly who's affected, and speak only to them, should be a rollout requirement scoped alongside the feature, not something you scramble to figure out once the incident's already live and support tickets are piling up.

3. Repetition and multiple channels aren't noise. They're the actual strategy.
One perfect message, sent once, consistently loses to three mediocre reminders sent across different channels as the deadline approaches. Email, in-app, and for high-impact accounts, a direct outreach from account management. Redundancy isn't overkill here; it's the mechanism that gets information to actually land.

4. Anything that changes existing behavior deserves a warning period, not just a warning message.
A feature that changes what already works for people needs time for them to notice, understand, and act not a single heads-up immediately before cutover. A short transition window, where the old and new behavior can coexist with a visible reminder, turns a hard cutoff into a soft landing.

5. Communication time deserves the same budget as development time.
We estimate dev time as a matter of course. We rarely estimate the time it takes for a change to actually reach and register with the people affected by it and then we're surprised when that gap causes an incident. If a feature changes existing behavior for real users, the rollout plan is part of the scope, not an afterthought bolted on when something breaks.

What actually prevents a rollback

The feature was never the problem. The distance between "it's live" and "people know what to do about it" was and that distance doesn't close itself just because the code shipped clean.

If you've had a launch like this, technically fine, and still a mess, you're not alone, and it's rarely a sign you did the technical work badly. It usually means the rollout got less design time than the build did, which is exactly what tends to happen when a deadline is looming.

Want more of this kind of breakdown?

Your email is only used to send you this checklist. No spam, unsubscribe anytime.

I'm a product manager sharing what I use to spot and fix broken user journeys.
This is a free resource, no strings attached.
Questions? pmworkflowlab@proton.me