Your Demo Slot Is a Leadership Opportunity

Published: (January 20, 2026 at 02:45 AM EST)
3 min read
Source: Dev.to

Source: Dev.to

The Problem with Traditional Demos

Every two months I stand in front of stakeholders and present what my team shipped.
For years I did what everyone does: walked through features.

“We added an error page to the docs.”
Checkbox. Checkbox. Next slide.

Nobody remembers those demos. Most demos follow the same script:

  • “In this sprint we implemented feature X. It’s efficient.”

A demo becomes proof that work happened — not a place where shared understanding is built. Nobody explicitly asks for this framing; you just absorb it. This is what a “professional” demo looks like.

A Different Approach

Last Friday I had a PI demo for new features in our component library. The old version of me would have said:

“We added a comprehensive error documentation page listing all error codes and explanations.”

That’s accurate, but instead I tried something else. I told a story and gave the user a name.

The Story

Meet Bob.

Without us, Bob is staring at weeks of work: identity‑provider quirks, permission matrices, undocumented edge cases. With the component, he copies the quick‑start example. Five minutes later it runs, then it crashes. He binds the error callback — like the docs suggest — and gets this message. Bob sends the email. Later he discovers our error reference page and realizes something important: every failure mode is documented. He’s no longer guessing. He can build.

Same features, different framing. One is a deliverable; the other is a story.

Why Storytelling Works

A feature list teaches:

“Progress is shipping things.”

A story teaches:

“Progress is changing someone’s situation.”

Those lessons don’t show up as questions in the meeting. They appear when someone says “Bob” — and everyone knows what that means. A named character is a compression mechanism. In environments where “safe” means status reports and checklists, this models something else: alignment comes from empathy, not precision slides.

I’m not expecting applause. The signal I care about is delayed — and indirect. Weeks or months from now I’ll listen for:

  • “Bob is stuck at this step.”

If “Bob” ever reappears in a ticket, a meeting, or a backlog item, I’ll know the framing landed. If Bob never comes back — that’s data too.

Takeaways

  • The experiment is running; no results yet.
  • Nobody asked me to do this; the slot was mine, so I used it differently.
  • I came up with the story ten minutes before the demo. It showed clumsy phrasing, rough pacing, and I didn’t even name the character until later.
  • Doing it once, imperfectly, is already more than “thinking about doing it differently,” which is where most ideas quietly die.

This connects to something I wrote about recently: you often have more agency than you think — but only if you actually take it.

Next Steps

  • In the next demo, pick one feature.
  • Don’t describe what it does.
  • Give it a name.
  • Then watch what comes back.

Views and experiments described here are my own and don’t represent my employer.

Back to Blog

Related posts

Read more »

[인터뷰] 토스인슈어런스는 왜 디지털 온보딩 시스템을 개발했나

법인보험대리점GA 토스인슈어런스는 신규 설계사가 업무를 시작하기 위한 초기 준비 절차온보딩를 전면 전산화한 ‘디지털 온보딩 시스템’을 구축했다. 복잡하게 흩어져 있던 필수 과정을 하나의 흐름으로 통합해 설계사의 정착 속도와 사용자 경험을 동시에 개선했다는 평가다. 토스인슈어런스의 디지털...