# Demo Why Not What

## Intro

This year at Square we started shipping aggressively. Powered by a completed migration, new feature roadmaps, and AI adoption, we shifted into a build, demo, iterate, ship cycle. My team was showing our work to other engineers all the way up to the C-suite. To help us stand out I put together a short framework of how to make demos great, especially while shipping fast and showing progressive improvement.

This is that framework.

## Why Not What

The "what" in a demo is obvious, it's on the screen. The audience can see the buttons and the flow of the UI. What they can't see is **why it matters**. Stories ground the features we build by making an example of their usefulness. Without a story, the audience is left to guess the value.

## Fine vs. Great

**Fine Demo: What was built**

> "We added a modifier button to the order screen."

**Great Demo: The problem it solves**

> "Baristas needed a faster way to customize drinks during rush hour without slowing the line."

* * *

**Fine Demo: Walks through features**

> "First you tap here, then select the size, then add modifiers from this menu..."

**Great Demo: Tells a customer story**

> "A regular walks in and orders their usual. The barista pulls up their history and the order is ready in two taps."

* * *

**Fine Demo: Audience evaluates the work**

> "We implemented item search using the new API and added caching."

**Great Demo: Audience imagines the user whose day got easier**

> "Now when the line is out the door, the barista isn't fumbling through menus, they're making drinks."

## Lead With a Story

Before showing anything, answer these four questions from the user's perspective:

1.  **Who are you?** Give the audience a person to root for.
    
2.  **What are you trying to do?** Set up the job to be done.
    
3.  **What was painful before?** Make the problem known.
    
4.  **What's different now?** Show the contrast.
    

## Demo Recipe

Follow this structure to build a compelling narrative!

1.  **Open with a one-sentence persona + goal**
    
    > "A seller at a busy counter needs to get someone checked out fast."
    
2.  **Name the pain in one sentence**
    
    > "Before, this meant digging through three menus to find the right option, which backed up the line."
    
3.  **Show the happy path first** One clean flow. No detours, no edge cases. Just the thing that proves the value.
    
4.  **Call out the moment of value** Don't make the audience guess. Say it:
    
    > "This is the part that used to take 30 seconds. Now it's two taps."
    
5.  **Close with the outcome** Time saved. Fewer errors. Clearer decisions. Happier customers. Name the win.
    
6.  **Save build details for the end** Technical deep-dives are great for people who want them. Offer them as a follow-up, not the main event.
    

## Make It Stick

### Critical

*   **Visibility Matters** - Introduce yourself and your team at the start, call out contributors by name when showing their work, and share credit generously. Demos are a team effort!
    
*   **Keep it short** - A tight demo is 1–3 minutes, not 10.
    
*   **Trust your instincts** - If it feels too short, it's probably right.
    
*   **Rehearse once** - Even one dry run catches awkward transitions and filler words.
    
*   **One takeaway** - What's the single sentence the audience should walk away with? Know it before you start.
    

### Polish

*   **Clean your environment** - No "Test User 69." Realistic data makes it believable.
    
*   **Consider a backup** - Live is better, but a 30-second video or a few screenshots can save the moment.
    
*   **Handle questions at the end** - "I'll cover that at the end" keeps the flow intact. Answering mid-demo often derails the story.
    

### Credibility

*   **Own the gaps** - Call out what is missing and what's coming next.
    

## Common Traps

**Don't apologize for what's not done yet**

*   ❌ "Sorry, this part isn't quite finished but…"
    
*   ✅ "This is in progress - here's what's coming next."
    

**Don't detour into bugs or edge cases**

*   ❌ "Now if you do this weird thing, it breaks but…"
    
*   ✅ Save edge cases for Q&A unless they're critical to the story.
    

**Don't narrate clicks**

*   ❌ "And then I click here, and then I click here…"
    
*   ✅ "I'll add the modifier…" *(while clicking)*
    

## Handling Q&A

*   **Repeat the question** - Ensures everyone heard it and gives you time to think.
    
*   **Bridge back to the story** - "That's a great question about \[XYZ\]. Remember our bartender…"
    
*   **Defer deep dives** - "That's a great technical question, let's sync after."
    
*   **Make space for multiple voices** - Take the lead and go through the queue of people asking questions. Take one or two from an individual before moving on.
    

## Know Your Audience

*   **Leadership** - Focus on outcomes and metrics. "This saves $2 or 2 minutes per transaction."
    
*   **Engineers** - Show the happy path, then offer technical deep-dive. "Want to see how we handle error handling?"
    
*   **Customers** - Emphasize ease and reliability. "You'll never lose a sale again!"