Demo the outcome, not the code

You have twenty minutes to show the work. You open with the architecture, because the architecture is the achievement: the queue you introduced, the retry semantics, the thing you are quietly proud of. People nod. Somebody says it looks great. Nothing happens afterwards.

The usual diagnosis is that you went over their heads and lost them. The evidence says something less comfortable.

They were not lost. They felt well served

In 2025 researchers ran nine experiments with 6,698 participants on how lay audiences respond to technical language. Jargon-laden explanations were rated more satisfying while being understood less. The mechanism is not confusion, it is inference: people assume the technical detail they cannot follow is filling the gaps in the explanation, so the presence of things they do not understand reads as evidence that the account is complete.

So showing your implementation does not teach anyone that you cannot translate. It produces a room of people who feel informed, are not, and have no way to discover the difference. That is worse than losing them, because losing them is visible.

There is an older result underneath this. In 1990 Elizabeth Newton had people tap out well-known tunes with a finger and predict how many listeners would name them. Tappers predicted around 50%. The actual rate was 3 correct out of 120 attempts, under 3%, a figure outside the entire range of the tappers’ own predictions. They could hear the music. They could not imagine hearing only tapping.

Your architecture diagram is tapping. You are hearing the whole song.

The move

Show the person who has to decide the thing doing its job, in their world, with their data, then hand them the keyboard.

Their world, not yours

The demo that lands has three properties, and none of them is about polish.

Their data. Not test_user_3 and not Lorem Ipsum. The actual account of an actual customer they have heard of, with the real record that is currently wrong. The moment a stakeholder sees a name they recognise, they stop evaluating your work and start evaluating the outcome, which is what you wanted.

Their words. If support calls it a bounced invoice, the demo says bounced invoice, not PaymentIntent in state requires_action. You are not dumbing it down. You are removing the exact material the study above shows will make them feel satisfied and stay ignorant.

Their starting point. Begin where their day begins, which is usually an inbox, a queue or a dashboard, and not the part of the system you changed.

There is a reason the canonical product demos are structured this way. When Jobs introduced the iPhone at Macworld in 2007, the framing was three products in one: “a widescreen iPod with touch controls, a revolutionary mobile phone and a breakthrough internet communications device.” Three outcomes a person already wanted. Not one architecture.

BEFORE                              AFTER

"So the ingest pipeline now         "Miriam in support gets this ticket
 writes to a staging table,          every Monday: the invoice bounced
 and there's a reconciler            and nobody knows why.
 that picks up orphaned rows
 on a schedule, which lets us        Here's her queue. Here's the ticket.
 replay failures without
 double-charging..."                 Watch the reason appear on the ticket
                                      itself. She doesn't ask us.
  slide of boxes and arrows
  nodding                            Now you drive. Open any ticket
  'looks great'                      from last week and tell me whether
  nothing happens                     you'd know what went wrong."

Then hand over the keyboard

This is the part almost nobody does, and the same research explains why it matters.

The inflated sense of understanding collapses when people have to produce their own explanation. Watching you is what created the illusion; doing it themselves is what dissolves it.

So end the demo by giving them control. Let them pick the record. Let them try the thing you did not rehearse. You will find out in ninety seconds whether they actually understood what you built, and they will find out whether they believe it, and both of those are the point of the meeting.

It is also the only honest test. A demo where you drive is a claim. A demo where they drive is evidence.

What it costs

Every rehearsed demo is a golden path. You have chosen the account that works, the flow you tested, the data that renders correctly. The more you rehearse, the further that path drifts from what a real user hits, and the more confident everyone becomes about a system nobody has actually exercised. Handing over the keyboard is partly a fix for this: it is the one moment where the unrehearsed case can surface in front of the people who need to know it exists.

It takes real preparation, and none of it is engineering. Finding the right customer record, checking the data is safe to show, learning what support actually calls the thing. Half a day, routinely, for twenty minutes of meeting. That is a genuine cost and it is not glamorous.

And you will feel underestimated. The queue and the retry semantics were the hard part and they will go unmentioned. That is the trade. The work is not being hidden, it is being reported in the only units your audience can price.

Try this week

Take the last thing you shipped and rewrite the first sentence of how you describe it.

Right now it probably starts with a component. Rewrite it to start with a person and a Monday: who was doing what, and what went wrong for them, before your change existed.

Then find one real record that demonstrates it, get whatever approval you need to show it, and put sixty seconds on the end where you do not touch the keyboard.

If nobody can drive it without you, you have not built a demo. You have built a performance, and performances are why your last one got a nod and no decision.