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."
"We improved the callback API."
Checkbox. Checkbox. Next slide.
It's efficient. It's safe. And it's forgettable.
More importantly, it quietly trains the organization to think in outputs, not situations. A demo becomes proof that work happened — not a place where shared understanding is built.
But a demo slot is stage time.
And stage time is influence — whether you intend to use it or not.
Trying Something Different
Last Friday, I had a PI demo. 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.
And it would have evaporated instantly.
Instead, I tried something else.
I told a story — and I gave the user a name.
"Meet Bob.
Bob is a developer integrating our authentication component into his research platform.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:
'Your test user lacks permission XYZ. Send this email to support. Response time is usually two days.'Bob sends the email.
Two days later, it works. He's not stuck anymore.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.
Same code.
Same sprint.
Different framing.
One is a deliverable.
The other is a worldview.
Why This Matters
Demos quietly teach people what kind of work matters.
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 show up later — in how problems are framed, in what's considered "done," in which gaps feel uncomfortable.
They show up when someone says "Bob" — and everyone knows what that means.
A named character is a compression mechanism.
It turns an abstract "integrator" into a reference point the organization can think with.
In environments where "safe" means status reports and checklists, this models something else: that alignment comes from empathy, not precision slides.
The Signal I'm Looking For
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."
"Bob's journey breaks here."
"Bob needs one last thing to close the loop."
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.
What Actually Happened
Nobody asked questions. No follow-up messages. No visible reaction.
It was a Friday afternoon PI demo on Teams. We wrapped. People went into the weekend.
The experiment is running. No results yet.
Try It Once
Nobody asked me to do this. Nobody rewarded it. The slot was mine. So I used it differently.
This connects to something I wrote recently: you often have more agency than you think — but only if you take it.
I came up with the story ten minutes before the demo. It showed. And I didn't even name the character — "Bob" arrived while writing this.
But I did it once. Imperfectly.
Next demo, pick one feature. Don't describe what it does. Describe who uses it. Give them a name.
Then watch what comes back.
Views and experiments described here are my own and don't represent my employer.
Top comments (0)