Notes
Articles, thoughts, and perspectives on the current industry.
The Demo Problem: Why AI Keynotes Fail at the Moment of Truth
The real gap isn't technical, and you can't erase it.

The demo crashed at 11:47 a.m.
Not the software—the story.
The CEO had just spent eighteen minutes walking everyone through transformer architecture, then swerved into a big, cloudy promise about “AI-powered productivity” that was so nonspecific it could’ve been a stapler with Bluetooth. Nobody clapped. The room just… exhaled. The kind of exhale that means, I’m listening, but I still don’t know what this does for me.
I’ve been around technical keynotes for fifteen years and I keep seeing the same pattern in AI-era presentations. They tend to split into two familiar failure modes:
The Engineering Lecture (parameters, benchmarks, training data)
The Marketing Mirage (limitless “transformation,” zero texture)
They look different on the surface, but they land the same way: the audience can’t picture themselves using the thing. And if they can’t picture it, they won’t trust it, buy it, fund it, or champion it internally.
The real gap isn’t technical. It’s translation.
At Amazon, I built Project Helix to solve this exact type of problem. The translation gap between what a model is and what it feels like to use.
The goal wasn’t “replace designers with generative tools.” It was to prototype understanding.
Before we built a single slide for an internal AI rollout, we used tools like Sora and Midjourney to visualize the moment of use: the specific interaction between a human and an agent, in context, under real constraints. When we showed those prototypes to non-technical stakeholders, nobody asked about latency. They asked things like, “Will it know my calendar preferences?”
That’s the question that matters. Not because latency doesn’t matter, but because believability comes first. People need to understand where the system fits into their day before they care how many milliseconds it shaves off a response.

Here’s the contrarian lesson: don’t try to erase doubt.
This part took me a while to learn, and it came from translating everything from medical devices at Stryker to aerospace rhetoric for Project Kuiper. The best AI keynotes don’t leave audiences with zero doubt. They leave them with one specific doubt resolved and one specific limitation acknowledged.
Most AI keynotes try to do the opposite. They present the model as omniscient—confident, flawless, universally capable. But enterprise audiences—CFOs, CHROs, procurement teams, the Workday crowd—are trained to sniff out risk. When you refuse to name the constraint (the guardrail, the edge case, the human-in-the-loop requirement), you don’t build confidence.
You build suspicion.
Because if you’re not telling them where it breaks, they assume you either don’t know—or you’re hiding it.
The “Uncertainty Protocol” (and why it works)
In my rehearsal process now, I use something I call an Uncertainty Protocol.
After the normal run-through, I ask the speaker one question:
What’s the one thing this AI absolutely cannot do yet?
Then we pull that limitation into the narrative arc—not as a legal disclaimer, not as a tiny footnote, but as a trust signal. It tells the audience: We understand the edges. We’ve thought about the failure modes. We’re not hand-waving risk.
Recently,at a live demo where the agent failed gracefully: it surfaced its reasoning, flagged uncertainty, and handed off to a human at the right moment. Engagement was noticeably higher than the “perfect” demo earlier in the day—because people weren’t watching a magic trick. They were watching something real.
Three questions to ask before you open Keynote
Before you write a single slide, ask your AI product team these three questions:
What’s the “uncanny valley” moment?
When does the AI go from helpful to unsettling? That’s usually not an engineering problem—it’s a design and trust problem.What’s the 30-second “aha” that requires zero technical vocabulary?
If you need to say “neural network” to explain it, you haven’t translated it yet.What are we willing to show failing?
If the answer is “nothing,” you’re not doing a demo—you’re doing a magic trick. And CFOs don’t buy magic tricks.
I’m currently consulting on keynote strategy for a few smaller shows while making sense of these translation frameworks during down time. If you’re wrestling with the demo problem, I’d genuinely love to hear which of those three questions your team got stuck on—and what kind of audience you’re trying to win over.
Onward.
Comments
3
This is exactly what I needed to read today. The section about starting simple really resonated with me - I've been struggling with feature creep on my current project.

Great insights on user research. I think many teams skip the qualitative phase and jump straight to quantitative, missing crucial context.

Would love to see a follow-up post on specific metrics to track for different types of products. The measurement section felt a bit brief.