When a Demo Turns Into a Trial

For a long time, I've been interested in how teams receive feedback - not just what's said, but what it does to the people doing the work. Years ago, watching how theater companies rehearse and review early drafts changed how I think about product teams, especially during demos. I was talking to a friend last week. He's a product leader at a fintech company. He's shipped across industries, in startups and big companies. Somewhere in the middle of the call, he said, almost casually, that they had demoed the new version of their product. A live demo. The kind where you flip the switch on something your team has been building for months and let the organization see it breathe for the first time. Then he paused. Just long enough that I could tell he was choosing his words. I asked, "Did it not go well?" He said, "It's not that. Yes, we had bugs. A few glitches. But nothing was truly broken. I wouldn't call it a failure." That answer is what got my attention. Because if the product mostly worked, and the demo still felt bad, the problem usually isn't the product. I asked, "So what is it then?" He said: "It should have felt like a celebration. Instead, it felt like a trial." He meant the room, not the code. Feedback came in sharp and out of proportion. The energy turned defensive. And by the end, the people who had spent weeks building the thing were answering for copy choices and edge cases instead of hearing what actually landed. The Demo Is Rarely the Problem Hearing him talk brought all of it back. I've run product launch and update demos across multiple companies. Here's what I've come to believe: The demo is rarely the problem. The setup around the demo usually is. Most teams treat a demo like an event. A reveal. A moment of truth. But demos aren't endings. They're transitions. A demo is where internal work meets external reality. That meeting point is fragile. If you don't design for fragility, you get the same failure mode in different clothing: The wrong audience sees the wrong stage of readiness. Feedback arrives without proportion. Builders feel judged instead of supported. Stakeholders feel uninformed instead of included. In my friend's case, they invited the entire company to the first production test. What should have been an internal shakedown became a public performance. A three-hour troubleshooting session, live, with an audience. When the inevitable rough edges showed up, the room reacted as if they were seeing a finished product that had failed. He owned it as the leader: "That's on me. I should have set it up for success - prepped the audience, framed the goals, set expectations." The Theater World Doesn't Collapse Stages I'm working on a theater play. My first one. Recently, we held what the theater world calls a "living room read." A small group in someone's living room, reading the work out loud. Not performed. Not polished. Just read. I went in thinking I was about 90% done. I left realizing I was closer to 60%. That could have been devastating. It wasn't. Because before anyone read a line, the director set the room. He explained what this was and what it wasn't. He framed the goal: not to judge whether it was "ready," but to help it become better. So when feedback came - and it came in waves, big ones - it didn't feel like a trial. It felt like information. Then, toward the end, the director did something I didn't expect. He asked: What is one thing you would not change? What is one thing that touched you? Where did you understand the character clearly? He wasn't doing it to make me feel good. He was doing it to help me see what was working - the parts worth protecting, so I wouldn't "fix" my strengths out of existence while chasing flaws. I left energized. Clear about what needed to change. Equally clear about what needed to stay. That living room read was a demo. A demo of a creative product, in a safe environment, with intentional framing, structured feedback, and a deliberate effort to end with clarity on what worked. What Bad Demos Teach Teams Most teams focus on the visible cost of a bad demo: time. Bug fixes. A delayed launch. But the real cost is what the experience trains. It trains perfectionism. Teams learn that showing early work means getting punished, so they wait until it's "bulletproof." It trains politics. People manage perception instead of pursuing truth. It trains avoidance. The best builders quietly stop volunteering to demo. It trains sandbagging. Innovation gets scoped down before it gets tested. My friend said it plainly: "You end up in a defensive position. You're justifying everything instead of collaborating." Surprise Is the Silent Killer There is one thing that reliably turns a demo into a trial. Surprise. Not the good kind. The "wait, what is this?" kind. A rule helps: no one on the presenting team should see a meaningful change for the first time during the demo. Surprise doesn't just create confusion. It creates embarrassment. And embarrassment is where learning goes to die. Not All Demos Are the Same One of the simplest fixes is separating demos by intent. Here's a ladder inspired by the theater world: Level 0: Builder demo (private) - internal shakedown, zero shame Level 1: Friendly demo (small cross-functional) - clarity, usability, early friction Level 2: Org demo (wider visibility) - shared context, no live debugging Level 3: Launch rehearsal - operational readiness, handoffs, failure modes Most demo disasters happen when a Level 0 demo gets treated like a Level 2 demo. End by Protecting What Works At the end of every demo, before you go hunting for flaws, ask: What worked better than you expected? What is one thing we should not break as we iterate? The theater director didn't ask those questions out of kindness. He asked them to help me see what was strong enough to build on. In product, this matters even more. Because if teams never hear what's working, they start to assume nothing is. And a team that assumes nothing is working will either slow down to a crawl or stop showing their work entirely. Momentum Is the Real Goal People build things. They put weeks, sometimes months, into making something work. Then they stand in front of a room and show what they made. That's vulnerable. How the room responds shapes what happens next - and not just to the product, but to the people building it. If the room responds only with what's wrong, people learn that building is exposure. That showing your work is risky. So they wait. They polish. They protect themselves. Your team already knows what's broken. They were staring at it for weeks before anyone else saw it. What they need from the room is something different: What is worth protecting? That is how critique becomes momentum. And momentum, not perfection, is what ships.