당신의 데모 슬롯은 리더십 기회
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
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.