The Problem with Demos: Why One Meeting Can’t Solve Everything

Why don’t we have more demos?

Demos is one of those reoccurring topics in our dev department’s leadership conversations--usually kicking off with a familiar question: Why don’t we have more demos? From there, the conversation spirals into a tangle of ideas, frustrations, and well-meaning suggestions. Everyone has an opinion, but we rarely land on a clear solution. Sound familiar?

I have mixed feelings about demos, and I suspect many engineers, product managers, and tech leaders do too. The more I think about it, the more I’m convinced the issue isn’t a lack of demos—it’s that we (and by “we,” I mean the broader engineering culture, not just my current workplace) are trying to solve too many problems with a single demo meeting. We’re cramming mismatched goals, audiences, and expectations into one overstuffed agenda, and it’s no wonder things feel chaotic.

Let me be clear: I’m not advocating for more meetings. Nobody wants that. Instead, I’m pushing for a rethink of how we approach demos. It starts with a simple principle: the right people should be at the right meeting, with a clear purpose in mind. Let’s break this down. 

The Demo Dilemma: One Size Doesn’t Fit All

In most tech organizations, demos are treated like a catch-all solution. Need to show off a new feature? Demo. Need to get stakeholder buy-in? Demo. Need to align the team on progress? Demo. Need to impress the C-suite? You guessed it—demo. But each of these scenarios has a different audience, objective, and level of technical detail required. Trying to address them all in one meeting is like trying to cook a gourmet meal with a single pot. You might pull it off, but it’s not going to be pretty.

For example, when engineers demo a new feature to product owners, the goal is usually to validate that the implementation matches the product vision. The conversation might dive into technical details, edge cases, or trade-offs made during development. That’s a valuable discussion, but it’s not the same as demoing the same feature to a marketing team, who might care more about user experience or how it’ll be pitched to customers. And it’s definitely not the same as presenting to executives, who might only want a high-level overview of business impact. Mixing these audiences—or expecting engineers to tailor their presentation on the fly—leads to frustration that manifests into giving less demos.

Why This Matters for Engineering Culture

This approach isn’t just about making demos more effective—it’s about respecting everyone’s time and expertise. Engineers are often stretched thin, juggling coding, debugging, and planning. Asking them to also be polished presenters for every audience can lead to burnout or resentment. I’ve seen talented engineers dread demo days because they feel like they’re being judged on their presentation skills rather than their technical contributions. That’s not fair, and it’s not productive.

On the flip side, product managers and other non-engineering roles often have the context and communication skills to bridge the gap between technical work and business goals. By sharing the demo load, we create a culture where everyone plays to their strengths. It also fosters collaboration, as teams work together to decide who’s best suited to present based on the audience and objective.

What do you think of demos and what does your organization do to make information shared more effectively?   I'd like to hear your thoughts.