What is a tech rehearsal, and how is it different from a launch checklist?

A tech rehearsal is a full, live run-through of a launch where every owner executes their part in sequence, so you can find the failures that live in the handoffs between them. A launch readiness checklist proves each part *exists*; a tech rehearsal proves the parts *connect*. The checklist is the inventory, the rehearsal is the dress run. You need both, but only the rehearsal exposes the seams.

Why do most product launches fail?

By an oft-cited Harvard Business School figure, roughly 95% of new products fail—but usually not because the idea was weak. Launches break at the seams: the handoffs between marketing, engineering, sales, and support, where no single person owns the transition. The work itself is fine; the connective tissue between teams is what gives way, especially under a deadline.

How do you run a dry run before a product launch?

Pick a real, time-boxed launch, put every owner in one live session, and run the whole sequence end-to-end on staging. Then do a "cue-to-cue" pass: skip everything that already works and rehearse only the handoffs, confirming each receiver got exactly what the sender intended. Assign one owner to every broken seam, fix them, and re-run until there are no unowned transitions.

What's the difference between a pre-mortem and a tech rehearsal?

A pre-mortem is a thinking exercise: you imagine the launch has failed and work backward to guess why. A tech rehearsal is an execution exercise: you actually run the launch and watch what really breaks. Pre-mortems surface risks you can predict; tech rehearsals surface the ones you can't—the silent handoff failures that only appear in motion. Use the pre-mortem to plan and the rehearsal to verify.

How can a distributed team rehearse a launch across time zones?

Schedule one synchronous window where every owner is present, and treat it as non-negotiable—the rehearsal is the rare thing async can't replace, because async hides exactly the seams you're trying to test. Run the sequence live on a shared canvas so everyone watches the same handoffs at once, record it for anyone who truly can't attend, and capture each broken seam with a named owner. The point of the live session is to make the invisible handoffs visible.

The Tech Rehearsal: Why Launches Break at the Seams

By one of the most-repeated figures in business school, about 95% of new products fail. Harvard Business School's Clayton Christensen put it bluntly: nearly 30,000 new products launch each year, and almost all of them sink (MIT Professional Education).

Here's the part nobody wants to hear: most of those launches didn't fail because the idea was bad. They failed because the pieces never connected. Marketing was ready. Engineering was ready. Support was ready. And on launch day the handoff between them quietly fell apart.

Theater solved this problem a century ago, and gave the fix a name: the tech rehearsal. It is the run-through where you stop rehearsing the parts and start rehearsing the seams. This piece is about why your launch breaks where the parts meet, why distributed teams are uniquely blind to it, and how to run a tech rehearsal before you ship.

What a tech rehearsal actually is

In theater, a technical rehearsal "is a rehearsal that focuses on the technological aspects of the performance." It exists to integrate "lighting, sound, set changes, special effects, and other technical elements with the performance." Note what it is *not*: it is not actors practicing their lines. They already did that, alone, for weeks.

The tech rehearsal assumes every part already works. Its entire job is to prove the parts work *together*—in sequence, in real time, under the lights. The actor hits the mark, the light comes up, the sound cue fires, the set piece moves. Each of those is owned by a different person. The rehearsal is the only moment they all happen at once.

Theater takes this so seriously it built labor law around it. The grueling tech day even has a nickname: "ten out of twelve." As *American Theatre* explains, the title "refers to an Equity mandate that says that when actors are called in for 12 hours of tech rehearsal, they can only work 10 of those hours" (American Theatre). An entire union rule exists because the industry knows the seams take that long to get right.

There's an even sharper tool inside the tech rehearsal: the cue-to-cue. Instead of running the whole show, you skip the dialogue and jump straight between technical cues. As Wikipedia describes it, "a scene will start with the first few lines and then skip to the lines and staged blocking for the next lighting, sound, or other cues." You fast-forward past everything that already works to rehearse only the handoffs. That's the most important idea in this article, and we'll come back to it.

Your launch checklist is lying to you

Most teams already have a launch process. It's a checklist. A launch readiness checklist is a genuinely good thing, and you should keep yours. But understand exactly what it does and does not prove.

A checklist proves the parts *exist*. Marketing copy: done. Pricing page: done. Onboarding email: done. Support docs: done. Every box is green, so the launch feels ready.

A checklist cannot prove the parts *connect*. It never asks whether the onboarding email links to the page that's actually live, whether the pricing the sales team quotes matches the pricing the billing system charges, or whether the "done" support doc describes the feature that actually shipped. Those are seams. They live *between* the checkboxes, and a checklist has no row for the space between rows.

This is also where a tech rehearsal differs from good prep. Getting your own piece ready ahead of time—what we've called meeting mise-en-place—is necessary and not sufficient. Mise-en-place gets each station ready. The rehearsal is the only thing that proves the kitchen can plate a full dinner. You can have ten perfectly prepped stations and still send out a cold, late, wrong plate, because nobody rehearsed the pass.

Why the failures hide in the seams

If the parts mostly work, why do launches still fail so often? Because the seam is the least-owned, least-tested, highest-variance part of any plan.

Look at how software teams measure this. The 2019 State of DevOps research found that elite engineering teams achieve "a change failure rate that's 7x lower" than low performers (Code Climate). Same talent market, same tools, a 7x gap in how often a "go-live" breaks. That gap is not about who writes better code. It's about who has rehearsed the path to production—who knows what happens at every handoff between commit and customer.

Three things make seams fail quietly:

No single owner. Each part has a clear owner; the handoff between them has none. When the pricing page and the billing system disagree, whose bug is it? "Not mine" is the most expensive sentence in any launch.
They're only visible in motion. A static artifact looks fine at rest. The defect only appears when the baton is actually passed—when someone clicks the email link, runs the migration, or quotes the price out loud. That's drift you can't see until you move, the same way a team can dead-reckon itself far off course between check-ins.
They cost double. When a seam fails, work doesn't just stop—it bounces back to a context everyone has already left. The cost of that context switch is the tax you pay for finding the seam on launch day instead of in rehearsal.

The tech rehearsal attacks all three at once. It forces the seam to have a moment, an audience, and a name—before customers are watching.

Why distributed teams skip the rehearsal

Here's the uncomfortable twist for remote teams: async work, the thing that makes distributed teams productive, is also what hides the seams.

In an office, the seam is loud. You see the designer hand the file to the engineer, watch the confusion, hear the "wait, that's not what I meant." Async erases that signal. Each person marks their task done in a tracker, and "done" looks identical whether or not the next person can actually use the output. The baton is dropped silently, in a thread nobody is reading, eight hours before anyone notices.

This is what it means to manage a launch you can't see—to fly on instruments instead of by feel. Your dashboard says every task is green. Green means "the part exists," not "the part connects." The instrument you're missing is the one that shows the handoffs, and most tools simply don't have that gauge.

So distributed teams do the thing that feels efficient and is actually the trap: everyone preps their part in isolation, marks it done, and treats the launch itself as the integration test. The audience becomes the rehearsal. That's the moment a tech rehearsal is designed to prevent.

The comforting lie that lets you skip it

Theater has a famous saying that gives everyone permission to wing it: *a bad dress rehearsal means a good opening night.* It feels reassuring when the run-through is a mess. It is also almost certainly nonsense.

Trace the adage and it falls apart. As *Dramatics* magazine put it, the line was probably born when "a director trying to inspire a cast who'd just finished a lousy run-through" said it to lift their spirits—"Maybe it was totally made up, but the adage stuck" (Dramatics). Any truth it seems to carry is just regression to the mean: if your worst run is followed by an average one, of course the next one looks better. That's statistics, not foresight.

The workplace version is everywhere. "The demo always looks rough the day before—it'll come together." "We never feel ready, and we always ship fine." Sometimes that's true, the way a bad dress is sometimes followed by a clean opening. But you are not relying on a mechanism. You are relying on luck dressed up as wisdom—exactly the kind of folklore a real run-through replaces with evidence.

A tech rehearsal doesn't ask you to feel ready. It shows you, on a stopwatch, which seams are not.

How to run a tech rehearsal for your launch

You don't need a theater. You need a defined event, every owner in the room at once, and a cue-to-cue mindset. Here's a dry run you can run in 60–90 minutes.

Pick a real, time-boxed launch. A feature release, a big customer demo, a go-live, an incident drill—anything where multiple people hand work to each other under a clock. Vague "always-on" work has no opening night and can't be rehearsed.
Cast a stage manager. One person calls the sequence and owns the clock—not the most senior person, the most cross-cutting one. They decide when each cue fires and write down what breaks. Give them a clear statement of intent so they can adjudicate when a cue is ambiguous.
Run it end-to-end, live, once. On staging, in order, with the real people. Not "describe what you'd do"—actually do it. Send the email. Click the link. Run the migration. Quote the price. Watch where the room goes quiet.
Then go cue-to-cue. Skip everything that worked and rehearse only the handoffs. Designer → engineer. Engineer → support. Marketing's go-time → the system's actual state. For each, confirm the receiver got exactly what the sender meant—a readback, out loud, just like a cockpit. This pass is short and it is where the launch is actually saved.
Fix the seams and re-run. Each broken handoff gets one named owner before you ship. If a seam failed badly, rehearse it again. The goal isn't a perfect run—it's zero unowned transitions.

This is the part where being distributed stops being a handicap. A tech rehearsal is a live, shared session by nature, and that's exactly what a tool like Coommit is built for: one room where the video, the shared canvas, and the contextual AI all see the same sequence. You run the cue-to-cue together on the canvas, and the AI flags the transition nobody claimed—the seam that would otherwise be discovered by a customer.

The economics back this up. IBM's 2024 breach study found that organizations which had built and instrumented their response *before* the crisis—rather than improvising during it—contained incidents 98 days faster and paid $2.2 million less, against a global average breach cost of $4.88 million (IBM). Preparation that feels like overhead is just the bill you pay early instead of late, at a steep discount.

The launch is the opening night, not the rehearsal

Every other industry that performs under pressure—theater, aviation, surgery, sports—rehearses the full sequence before the audience arrives. Software keeps treating the launch itself as the first time all the parts run together, then acts surprised when the seams give way.

Your checklist will keep telling you the parts exist. Only a tech rehearsal will tell you they connect. Run one before your next launch, go cue-to-cue on the handoffs, and let opening night be the second time the show runs end-to-end—not the first.