The demo shift: from FAB to BAF

Nov 9, 2025  •  4   • 747 

Let’s be honest. You can prepare your demo perfectly.

You’ve tested the feature ten times. You’ve got a backup video, screenshots, even a second laptop ready, just in case the Wi-Fi doesn’t work.

But here’s the thing: Even if everything works flawlessly, your demo can still fall flat.

Because a technically perfect demo isn’t necessarily a memorable one. Without a story, your audience might remember what you did, but not why it mattered.

They’ll see the feature, but miss the meaning.

How to show what really matters

In 1968, Douglas Engelbart gave a live demonstration that changed the course of computing history. What he showed—technologies like the computer mouse, hypertext, and real-time collaboration—was so ahead of its time that the presentation later became known as The Mother of All Demos. At one point, while showing how the mouse worked, he casually remarked, “I don’t know why we called it that. It started that way and we never changed it.”

The audience was stunned by the possibilities of what the future might hold. The demo’s impact was so profound that, decades later, composers Mike Rouse and Ben Neill created an avant-garde opera called The Demo , entirely dedicated to Engelbart’s visionary presentation.

Watch ‘The Mother of All Demos’:

Now, chances are your next demo isn’t introducing the mouse or reinventing the Internet. You’re showing something smaller, a new feature, an improved flow, maybe a fix that finally works. But here’s the thing: you can still make it matter. You can still make people feel the “wow.” It just starts with how you tell the story.

Fast forward to today

You’re about to give your (sprint) demo. What do you do?

For many teams, it’s the feature itself. “Here’s a new button.”
“This screen now has extra filters.”

Nice for you. But your audience is thinking: so what?

Why inside-out demos are boring

The classic formula goes like this FAB:

1. Feature: what is it?
2. Advantage: how does it work?
3. Benefit: what’s in it for the user?

That’s inside-out. You start with what you built, hope someone will figure out why it matters, and wrap up with the benefit to the user.
The problem? Features are cold. They don’t make people feel anything. They don’t stick.

Fine for a manual.
But in a demo? Boring.

Flip it around: BAF.

That’s outside-in:

1. Benefit – start with the win for your audience.
2. Advantage – briefly explain what makes that possible.
3. Feature – only show the button, code, or interface once they already understand why it matters.

FAB is you-focused. You tell them what you built.
BAF is audience-focused. You make them feel what they get out of it.

Outside-in is value based

1. Problem: relatable pain: “Ever notice how your team gets stuck in endless email threads?”
2. Need: what should happen instead: “Imagine collaborating as if you’re sitting side by side.”
3. Benefit: the result: “You see each other’s updates live, with no duplicate work.”
4. Feature; how you built it: “We’ve added real-time co-editing to the document system.”

Why this works for internal demos too

Even if you’re not selling, you want your audience to get why your work matters.

• Managers instantly see the business value.
• Colleagues feel the impact on their own work.
• You get faster support, budget, or time for the next step.

How to structure your next demo

1. Start with context: in one sentence: what problem were you trying to solve?
2. Make the need come alive: describe the current state and why it’s a pain.
3. Show the benefit: what changes now that this is here?
4. Then reveal the feature: run it live, click through, let people feel it.

The next time you create a pitch, blog post, or demo, don’t ask yourself: “What can our product do?”
Ask: “What can my customer finally do now?”

Closing

I’ll admit it, I’ve fallen into that trap more times than I can count. I’d spend hours perfecting every detail of my demo: every click rehearsed, every shortcut memorized, even a backup video ready just in case. And when the moment came, everything went flawlessly… except it didn’t. Because while the tech worked perfectly, the story didn’t land. I was showing features, not meaning. Explaining what it did, not what it changed.

It took me a while to realize I had to flip the story and honestly, I’m still learning.

Every time I prepare a new demo, I keep this sentence in mind as my reminder:

Features are the manual. Benefits are what we want.