Most trade shows are produced like theatre.
Eleven months of rehearsal. Three days of performance. Strike the set, take a bow, send the thank-you emails. Then everyone collapses, half the team rotates out, and next year's edition starts from a blank call sheet — same venue, same anxieties, same arguments about the aisle widths, re-litigated from zero.
Software teams stopped working this way twenty years ago. Not because they got smarter, but because they found a discipline that made every release start where the last one ended instead of where the first one did. I think that discipline maps onto the show cycle almost perfectly — and the places where it doesn't map are just as instructive.
Your 2027 show is v12, not a new show
The core move is a change of noun. Stop thinking of next year's edition as a new event. It's a version. Your 2027 show is v12 of a product that's been in continuous development since v1 — same product, new release.
Say it out loud and it sounds obvious. But watch how most organizations actually behave in month one of a new event lifecycle: new deck, new floor plan drawn from scratch, new debate about things that were settled — and unsettled, and re-settled — three editions ago. The product is on v12; the process restarts at v1 every year.
That one reframe drags a whole toolkit in behind it. Here's what the software model looks like applied to a show, piece by piece.
Telemetry, not surveys. Software teams don't ship a release and then mail users a questionnaire six weeks later. They watch the product live. A show throws off signal all day — scan rates by hall, session fill, meeting no-shows, which aisles go quiet after lunch — and most of it evaporates because nobody is set up to catch it while it's happening. The post-show survey isn't wrong; it's just the flight recorder when what you needed was the cockpit. Live telemetry during the show, post-show reports after it — that's the capability layer this whole discipline sits on, and it's exactly the layer we obsess over building.
The changelog. Every serious codebase carries a written record of what changed and why. Most shows carry that record in the head of whoever hasn't quit yet.
When your ops lead of nine years leaves, she takes v3 through v11 with her — why the catering moved, why hall C failed as a startup zone, why registration opens at 8:30 and not 8:00. Write it down. Every decision that shapes the edition gets a line: what changed, why, what we expected. Institutional memory should be an artifact, not a person. I've written about this as a data problem in your show forgets everything every year — this essay is the same problem as an operating discipline. The data can persist all it wants; if nobody writes down why, you've archived the answers and lost the questions.
The retro. Software teams hold a post-mortem within days of a release, while it still hurts and while it's still true. Shows tend to hold theirs never, or in a debrief three months later that's really a budget meeting. Do it within a week. Make it blameless — the point is what the system did, not who to embarrass. And log the decisions that come out of it, because a retro that produces no written changes is a group therapy session.
Staging environments. You don't push untested code straight to production, and you shouldn't push an untested format straight to your main floor. Side events, a one-hall pilot, a new matchmaking format trialled on one exhibitor category — these are your feature flags. Small blast radius, real users, honest signal. If the format works at one hall, it earns its way into v13. If it dies, it dies cheap.
Rollback plans. If the new floor layout is failing, you should know by noon on day one — from the telemetry, not from an exhibitor cornering you at the gala. And knowing isn't enough: you need a pre-agreed plan B that doesn't require heroics. Which signage moves, who re-routes the flow, what gets announced. Software teams write the rollback before they deploy, precisely because nobody thinks clearly during the fire.
The backlog. This edition, you had 60 ideas and shipped 20. In the theatre model, the other 40 are gone — scattered across old decks and departed contractors' notebooks. In the software model, they're a ranked backlog: still alive, still argued over, waiting for the edition where they fit. Some of your best v14 features were rejected v11 ideas whose time hadn't come. Losing them isn't editing. It's amnesia.
Iterative event planning: cadence beats brilliance
Here's the deeper point, and it's the one I'd defend hardest.
A play optimizes for one perfect performance. Software optimizes for the rate of improvement. Those are different games with different winners.
In a market where attendees and exhibitors re-choose every single year — and they do; your show competes for its own audience at every edition — the compounding show wins. The show that improves 5% per edition, reliably, edition after edition, walks past the show that's 10% better today and standing still. Not immediately. But the gap closes, then flips, and once it flips it keeps widening, because one team is accumulating and the other is re-rehearsing.
That's why I care less about whether your next edition is brilliant and more about whether your improvement loop runs. Does telemetry reach a decision-maker? Does the retro happen while it's fresh? Does the backlog survive the team? If yes, brilliance becomes a byproduct — you'll stumble into it eventually, and when you do, you'll keep it. Brilliance is a lottery ticket. Cadence is an engine.
There's an experience-side twin to this argument — the show that never runs the same twice is about the event itself adapting to each attendee, while this essay is about how the team operates edition over edition.
What I won't claim
The analogy breaks in places, and pretending otherwise would make this a worse argument.
You can't A/B test a keynote. Software's superpower is cheap experiments and second chances: deploy, measure, revert, redeploy. A show gets no second deploy of day one. Opening morning is production, live, with no undo. So the discipline shifts shape: instrumentation before the show, observability during it, honest retros after it. You can't iterate within the performance — so you have to be ruthless about iterating between them, and about catching in-show signal while it can still change something (see rollback, above).
Theatre gets something right that software mostly doesn't. Craft. Drama. The specific electricity of opening night, of a thing happening once, live, in a room. Attendees don't fly in for your release process — they come for the performance. The goal isn't to turn your show into a sprint review with a coffee stand. It's software cadence with theatrical standards: iterate like an engineering team, perform like an opening night.
"Data-driven" done lazily is just theatre with dashboards. I've seen the failure mode: a survey nobody reads, a report that ships after the decisions are made, a wall of screens nobody's authorized to act on. Telemetry only matters if someone on the floor has the authority to act on it mid-show — to move the signage, re-route the flow, pull the trigger on plan B. Data without a decision-maker attached is décor.
Version control or amnesia
Strip everything above away and one fact remains: your show already ships once a year. That's not a choice — it's the show cycle. The cadence exists whether you use it or not.
The only question is what carries over between releases. Whether v12 starts from v11's changelog, backlog, telemetry and retro — or from a blank call sheet and whoever's left who remembers.
Your show ships annually either way. With version control, or with amnesia.
Start with the cheapest piece: before the next planning meeting, open a blank document, title it "Changelog — v[your edition number]", and write down the first three decisions you make and why. That's it. That's the whole entry fee to the compounding game.
Related reading linked in studio (2).