Demo Specialist

Demo Specialist

Strategic expertise for delivering product demonstrations that convert prospects into customers.

Philosophy

A demo isn't a feature tour. It's a story about your prospect's future told through your product.

The best product demos: 1. Start with their problem — Not your solution 2. Show, don't tell — Features are boring; outcomes are compelling 3. Match the audience — Executives need different things than end-users 4. Create urgency — Show the cost of inaction 5. End with a clear next step — Never let momentum die

How This Skill Works

When invoked, apply the guidelines in rules/ organized by:

• structure-* — Demo flow, storytelling arc, timing
• audience-* — Stakeholder mapping, persona-based demos
• technique-* — Live demo execution, objection handling
• environment-* — Demo prep, sandbox vs live, technical setup
• followup-* — Post-demo actions, next steps

Core Frameworks

The Demo Hierarchy of Needs

                ┌─────────────────┐
                │   CONVICTION    │  ← "I need this NOW"
                │   (Urgency)     │
                ├─────────────────┤
                │    VISION       │  ← "I see how this transforms us"
                │   (Future)      │
                ├─────────────────┤
                │   RELEVANCE     │  ← "This solves MY problem"
                │  (Personalized) │
                ├─────────────────┤
                │   CREDIBILITY   │  ← "This actually works"
                │   (Proof)       │
                └─────────────────┘

Demo Structure Arc

┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│  HOOK    │───▶│ PROBLEM  │───▶│ SOLUTION │───▶│  PROOF   │───▶│  CLOSE   │
│  (2 min) │    │  (5 min) │    │ (15 min) │    │  (5 min) │    │  (3 min) │
└──────────┘    └──────────┘    └──────────┘    └──────────┘    └──────────┘
     │               │               │               │               │
  Attention      Pain point       Core value      Social proof   Next step
  + agenda      validation      demonstration    + ROI case     + timeline

Stakeholder Demo Matrix

The SHOW Framework

• Situation — Confirm their current state
• Hurdle — Highlight the specific challenge
• Outcome — Paint the future with your solution
• Wow — Demonstrate the "aha moment"

Demo Types

Environment Strategy

Anti-Patterns

• Feature dumping — Showing everything instead of what matters
• No discovery — Demoing before understanding their needs
• One-size-fits-all — Same demo for every audience
• Demo theater — Overly scripted, no room for questions
• Technical rabbit holes — Getting lost in implementation details
• No next step — Ending without a clear action
• Ignoring the room — Not reading reactions and adjusting
• Over-promising — Showing roadmap items as current features

1. Demo Structure (structure)

Impact: CRITICAL Description: Foundational demo architecture — storytelling arc, timing, flow, and transitions. The skeleton that everything else hangs on.

2. Audience Strategy (audience)

Impact: CRITICAL Description: Stakeholder mapping, persona-based customization, and multi-stakeholder demo orchestration. Know who you're talking to.

3. Demo Technique (technique)

Impact: HIGH Description: Live execution skills — pacing, narration, handling questions, objection management, and recovery from mistakes.

4. Environment Preparation (environment)

Impact: HIGH Description: Demo environment setup, data preparation, technical readiness, and backup plans. Never let infrastructure kill a deal.

5. Follow-up & Conversion (followup)

Impact: MEDIUM-HIGH Description: Post-demo actions, next step frameworks, recap communications, and momentum maintenance.

Integrating Discovery into Demos

Impact: CRITICAL

A demo without discovery is a feature tour. A demo built on discovery is a customized solution presentation. The connection between what you learned and what you show is where demos become deals.

The Discovery-to-Demo Pipeline

DISCOVERY                    DEMO INTEGRATION
─────────────────────────────────────────────────────
Pain points          →       Demo flow priorities
Current process      →       "Before vs After" framing
Success metrics      →       ROI/proof point selection
Stakeholder concerns →       Objection preemption
Timeline/urgency     →       Close approach
Competition          →       Differentiation emphasis

Pre-Demo Discovery Review

Before every demo, answer these:

QUALIFICATION
□ Why are they looking? (Trigger event)
□ Why now? (Urgency/timeline)
□ What's the cost of inaction?
□ Who's involved in the decision?
□ What's the budget situation?

PROBLEM
□ What's the specific pain? (Not generic)
□ Who feels it most? (Person and role)
□ How are they solving it today?
□ What have they tried that failed?

SUCCESS
□ What does success look like to them?
□ What metrics would they track?
□ What's their realistic timeline?

COMPETITION
□ Who else are they evaluating?
□ What do they like about alternatives?
□ What concerns them about alternatives?

Mapping Discovery to Demo Flow

Create your demo script based on discovery:

Discovery Callbacks During Demo

Reference what you learned constantly:

OPENING CALLBACK:
"Based on our conversation with [AE], I understand
you're dealing with [specific problem]. Today I want
to show you exactly how we solve that."

MID-DEMO CALLBACK:
"This is what [Name] mentioned — your team currently
spends [time] doing [task]. Watch what happens now..."

PROOF CALLBACK:
"You mentioned [competitor concern]. Here's what
[similar customer] found when they compared..."

CLOSE CALLBACK:
"You said [success criteria]. Based on what you've
seen, does this look like it delivers that?"

When Discovery Is Incomplete

Signs you don't have enough:

• You don't know the specific problem
• You can't name specific stakeholders
• You don't know their current process
• You don't understand the urgency

Mid-demo discovery techniques:

OPENING DISCOVERY:
"Before I jump in, I want to make sure I'm showing
you the right things. Can you tell me more about
[specific area]?"

CONFIRMING ASSUMPTIONS:
"I'm assuming [assumption]. Is that right, or is
there something I should adjust?"

MICRO-DISCOVERY:
"How would this typically work in your environment?"
"Who on your team would use this most?"
"What would success look like for this specific workflow?"

Building the Custom Demo Narrative

The Narrative Formula:

"We understand [company] is dealing with [problem]..."
(Prove you did your homework)

"...which is costing you [quantified impact]..."
(Create urgency)

"...because [root cause]."
(Show understanding)

"What we're going to show you today is how [outcome]..."
(Promise the transformation)

"...specifically focused on [their use cases]."
(Prove customization)

Example:

"We understand Acme Corp is dealing with deployment
cycles that take 4 hours of engineering time, about
80 hours a month total — that's half an FTE.

And from what Sarah shared, the bigger issue isn't
just time — it's the production incidents that come
from manual errors in the current process.

What we're going to show you today is how Acme's
deployment process becomes 15 minutes with zero
manual steps, specifically focused on your Kubernetes
environment and the Salesforce integration you need."

Discovery Gap Handling

When they reveal new information mid-demo:

The Pivot Script:

"Actually, based on what you just shared, let me
adjust. [Original plan] is still relevant, but let
me first show you [new priority] since that's more
critical to your decision."

Pre-Demo Questions to Ask

If you didn't do discovery, do it now:

OPENING (2 minutes)

"Before I show you the product, I want to make sure
I'm focusing on what matters most. Can I ask a few
quick questions?"

1. "What's driving your evaluation right now?"
2. "What does your current process look like for [use case]?"
3. "If this demo is successful, what happens next?"
4. "Is there anything specific you need to see today?"

Stakeholder-Specific Discovery Integration

For each stakeholder type, connect differently:

The Discovery Validation Loop

During demo, validate what you learned:

ASSUMPTION: "They said deployment takes 4 hours"

VALIDATION: "Sarah mentioned deployment takes about
4 hours currently. Is that still accurate? Has
anything changed?"

POSSIBLE RESPONSES:
- "Yes, exactly right" → Continue as planned
- "Actually, it's worse now" → Emphasize more
- "We've improved it somewhat" → Adjust framing
- "Different people experience differently" → Explore

Building Discovery into Your Demo System

Post-demo discovery documentation:

□ What new information did I learn?
□ What assumptions were validated?
□ What assumptions were wrong?
□ What questions remain unanswered?
□ What objections need addressing?
□ What should the next conversation explore?

Feed back to discovery process:

Anti-Patterns

• Generic demo despite discovery — Wasting the intelligence you gathered
• No discovery callbacks — Not proving you listened
• Assuming discovery is complete — Things change
• Not adapting mid-demo — Rigid despite new information
• Over-relying on AE notes — Not confirming with attendees
• Discovery without integration — Great questions, same demo
• Skipping discovery entirely — Feature tour mode
• Not documenting new learnings — Losing deal intelligence

Stakeholder Mapping and Multi-Stakeholder Demos

Impact: CRITICAL

Enterprise deals have 6-10 stakeholders. Your demo must speak to all of them — often simultaneously. Map the room before you enter it.

Stakeholder Archetypes

Pre-Demo Stakeholder Research

For each attendee, know:

┌─────────────────────────────────────────────────────────┐
│ NAME:          [Full name and pronunciation]           │
│ TITLE:         [Role and department]                   │
│ ARCHETYPE:     [Economic/Champion/Technical/User/etc.] │
│ CARE ABOUT:    [Top 2-3 priorities]                    │
│ SUCCESS LOOKS: [What would make this demo a win?]      │
│ POTENTIAL OBJECTION: [What might they push back on?]   │
│ RELATIONSHIP:  [Who do they influence/report to?]      │
│ LINKEDIN:      [Recent posts, shared connections]      │
└─────────────────────────────────────────────────────────┘

Multi-Stakeholder Demo Structure

The Challenge: Different stakeholders need different things at different depths.

The Solution: Layered demo with explicit handoffs.

┌────────────────────────────────────────────────────────┐
│  EXECUTIVE LAYER (First 10 min)                       │
│  - Business outcomes, metrics, strategic value        │
│  - "Here's the 30,000-foot view of impact"           │
│  - Executives can drop after this if needed           │
├────────────────────────────────────────────────────────┤
│  OPERATIONAL LAYER (Middle 15 min)                    │
│  - Workflows, collaboration, day-to-day use          │
│  - Managers and power users most engaged here         │
├────────────────────────────────────────────────────────┤
│  TECHNICAL LAYER (Final 10 min or separate call)      │
│  - Integration, security, implementation              │
│  - IT/Dev team deep-dive                              │
└────────────────────────────────────────────────────────┘

Room Reading Techniques

Watch for:

Managing the Multi-Stakeholder Dynamic

Technique 1: Explicit Layering

"I'm going to structure this in three parts. First,
I'll show the strategic value — Sarah and Mike, this
is where I'd love your input. Then we'll go into the
operational workflow — Tom, I know you flagged some
specific scenarios. Finally, we'll touch on technical
integration — Jane, save your questions for that section
or jump in anytime."

Technique 2: Named Callbacks

"This is what I was describing earlier, Mike, when
you asked about scaling across regions..."

"Sarah, remember you mentioned the CFO wants weekly
reports? This is that exact scenario..."

Technique 3: Stakeholder Spotlights

After showing a workflow, ask specific stakeholders:

"Tom, does this match how your team would actually use this?"
"Jane, any technical concerns with what you've seen so far?"
"Mike, does this address the compliance requirement you mentioned?"

Handling Stakeholder Conflict

When stakeholders have competing priorities:

The RACI for Demo Success

Stakeholder-Specific "Aha" Moments

Plan one "aha moment" for each key stakeholder:

Power Dynamics Mapping

                    ┌─────────────┐
                    │ ECONOMIC    │
                    │ BUYER       │
                    └──────┬──────┘
                           │
              ┌────────────┼────────────┐
              │            │            │
        ┌─────▼─────┐ ┌────▼────┐ ┌─────▼─────┐
        │ CHAMPION  │ │ BLOCKER │ │ TECHNICAL │
        │           │ │         │ │ EVALUATOR │
        └─────┬─────┘ └────┬────┘ └─────┬─────┘
              │            │            │
              └────────────┼────────────┘
                           │
                    ┌──────▼──────┐
                    │  END USERS  │
                    └─────────────┘

Influence flows upward. Win the bottom, use champions
to influence the top. Neutralize blockers.

Anti-Patterns

• Presenting to the most senior person only — Ignoring the room
• Treating all stakeholders equally — Not prioritizing
• Not knowing the room — Going in blind
• Ignoring the quiet ones — They may be the real decision maker
• Letting one person dominate — Not managing the dynamic
• Same pitch to everyone — One-size-fits-all messaging
• Missing the coach — Not identifying your internal ally

Tailoring Demos to Audience and Use Case

Impact: CRITICAL

Generic demos lose deals. Every demo should feel like it was built specifically for the prospect sitting in front of you.

The Personalization Hierarchy

Pre-Demo Discovery Checklist

Must know before any demo:

COMPANY CONTEXT
□ Industry and vertical
□ Company size (employees, revenue)
□ Growth stage (startup, scaling, enterprise)
□ Tech stack (if relevant)
□ Competitors they've evaluated

PROBLEM CONTEXT
□ Specific pain points (from discovery call)
□ Current solution/process
□ Why they're looking now (trigger event)
□ Cost of current problem (quantified if possible)
□ Timeline and urgency

STAKEHOLDER CONTEXT
□ Who will be on the call
□ Their roles and responsibilities
□ What each person cares about
□ Who's the champion, who's skeptical
□ Decision-making process

SUCCESS CRITERIA
□ What would make this demo successful?
□ What are the must-have capabilities?
□ What are the dealbreakers?
□ What's the next step if demo goes well?

Vertical-Specific Demo Strategies

Use Case Mapping

Step 1: Identify their top 3 use cases

From discovery: "We need to solve..."
1. [Primary use case] — This is why they took the meeting
2. [Secondary use case] — Nice to have
3. [Future use case] — Expansion opportunity

Step 2: Map to your demo flow

Primary use case:    60% of demo time
Secondary use case:  25% of demo time
Future use case:     10% (tease for expansion)
Buffer/questions:    5%

Step 3: Create custom demo script

For each use case:

CONTEXT:     "[At Company], when your team needs to [task]..."
CURRENT:     "Right now, that means [their painful process]..."
SHOW:        "[Demonstrate the workflow]"
OUTCOME:     "Now your team can [benefit], which means [value]"
PROOF:       "[Similar customer] saw [specific metric] improvement"

Personalization Techniques

1. Use Their Language

2. Reference Their Context

Good:

"I was looking at [Company]'s recent product launch —
congratulations on the Series B, by the way — and I
thought about how this feature would help you scale
your sales team without adding headcount."

Bad:

"So this is our pipeline management feature. Companies
use this to track their sales."

3. Use Realistic Scenarios

The Personalization Minimum

Even with limited prep time, always do:

1. Company name/logo — In the demo environment if possible 2. Industry context — One reference to their vertical 3. Discovery callback — "You mentioned [specific thing]..." 4. Role relevance — Speak to who's actually in the room 5. Relevant metric — One number that matters to them

Demo Environment Personalization

Adapting in Real-Time

When you discover new information during demo:

"That's interesting — you mentioned [new info]. Let me
actually adjust what I was going to show you. This is
more relevant..."

Signals to adapt:

Industry-Specific Compliance Considerations

Anti-Patterns

• No discovery reference — Never mentioning their specific situation
• Wrong vertical context — Healthcare examples for finance prospect
• Outdated research — Referencing their old product/situation
• Over-personalization — Seeming like you stalked them
• Generic demo data — "Acme Corp" when you could use their context
• Assumption without confirmation — "I assume you do X..." without checking
• One-size-fits-all script — Reading same thing to every audience

Demo Environment Preparation

Impact: HIGH

A flawless demo environment is invisible. A broken one destroys credibility. Invest the preparation time — the best demo content can't survive a crashing environment.

Environment Types Comparison

The Demo Environment Checklist

24 Hours Before:

ENVIRONMENT
□ Demo instance is accessible and stable
□ All features to be shown are working
□ Data is current, realistic, and appropriate
□ No embarrassing content (test data, inappropriate names)
□ Correct branding/customer logo if personalized
□ Backup environment ready

ACCOUNTS
□ Demo user account works
□ Password known and saved
□ MFA configured and accessible
□ Correct permission levels set

INTEGRATIONS
□ All integrations connected and active
□ Test data flowing correctly
□ No stale/broken connections

TECHNICAL
□ Browser cleared of sensitive tabs/bookmarks
□ Browser extensions disabled
□ Notifications disabled (all apps)
□ Do Not Disturb enabled
□ Bandwidth tested

1 Hour Before:

FINAL CHECKS
□ Full run-through completed
□ Environment responds quickly
□ All screens load correctly
□ Data hasn't changed unexpectedly
□ Backup video/screenshots accessible
□ Notes and script ready

MACHINE PREP
□ Unnecessary applications closed
□ Desktop cleared or hidden
□ Resolution set correctly
□ Audio/video tested (if remote)
□ Backup power/internet ready

Demo Data Strategy

The "Goldilocks" Principle:

• Not too sparse (looks unused)
• Not too dense (overwhelming)
• Just right (realistic, relevant)

Data Volume by Demo Type:

Data Quality Checklist:

□ Names are realistic (not "Test User 1")
□ Company names are appropriate (not competitors)
□ Numbers make sense (not $999,999,999)
□ Dates are current (not 2019 timestamps)
□ Status distributions are realistic
□ No PII or sensitive data
□ No inside jokes or inappropriate content

Scenario Pre-Loading

Pre-stage these for common demo flows:

Live vs Sandbox Decision Matrix

Choose PRODUCTION when:
□ Product is very stable
□ Demo is straightforward
□ Performance matters
□ Customer wants "real" feel
□ Data doesn't need customization

Choose SANDBOX when:
□ Showing new/beta features
□ Complex multi-step workflows
□ Customer-specific configuration needed
□ Risk tolerance is low
□ Need full control over data

Backup Strategy

Three layers of backup:

LAYER 1: LIVE RECOVERY
- Second browser/tab with same demo
- Know how to quickly restart

LAYER 2: BACKUP ENVIRONMENT
- Separate sandbox instance
- Pre-authenticated and ready

LAYER 3: OFFLINE BACKUP
- Screenshots of key flows
- Video recording of demo path
- Slide deck with embedded images

Backup Asset Checklist:

Remote Demo Technical Setup

Video Conferencing Checklist:

VISUAL
□ Lighting on face (not behind)
□ Camera at eye level
□ Background professional or virtual
□ Dressed appropriately (full outfit)

AUDIO
□ Good microphone (not laptop mic)
□ Headphones (no echo)
□ Quiet environment
□ Backup phone dial-in ready

SCREEN SHARING
□ Know how to share specific window vs full screen
□ Share only what needed
□ Resolution appropriate for viewing
□ Multiple monitors configured correctly

Screen Resolution Guidance:

The Demo Dry Run

Mandatory dry run elements:

TIMING
□ Complete demo fits in allotted time
□ Identify sections that run long
□ Know what to cut if needed

FLOW
□ Transitions are smooth
□ Navigation is efficient
□ No dead ends or confusion

TECHNICAL
□ Every click works
□ Every screen loads
□ Every integration functions

CONTENT
□ Data looks correct
□ Messaging is sharp
□ Objection responses ready

Environment Recovery Protocols

Scenario: Page won't load

1. Try refresh (once)
2. Open backup tab
3. If still failing, switch to backup environment
4. If all else fails, switch to screenshots/video
5. Narrate: "Let me show you this another way..."

Scenario: Feature errors

1. Try once more with different input
2. Note the error, don't dwell
3. Switch to adjacent feature
4. Promise to follow up: "Let me get you the recording of this working correctly"

Scenario: Internet drops

1. Phone hotspot (pre-configured)
2. Dial in to meeting audio
3. Verbal description while reconnecting
4. Have participant share their view if possible

Environment Maintenance Schedule

Anti-Patterns

• "It usually works" — Not testing before demo
• Stale data — 2-year-old timestamps
• Test pollution — "Test user 123" visible
• No backup plan — Single point of failure
• Over-engineering — 2 hours of prep for 15-min demo
• Notification pop-up — Slack messages during demo
• Wrong account — Personal account vs demo account
• Assuming it works — Not doing dry run

Remote vs In-Person Demo Techniques

Impact: HIGH

Remote and in-person demos require fundamentally different approaches. What works in a conference room often fails over Zoom, and vice versa.

Key Differences at a Glance

Remote Demo Best Practices

The Remote Attention Challenge:

ATTENTION CURVE (REMOTE)

High  │    *
      │   * *
      │  *   *     *
      │ *     *   * *
      │*       * *   *
Low   │        *       * * * * *
      └─────────────────────────────
      0    5    10   15   20   25   30
                    Minutes

Solution: Re-engage every 5-7 minutes

Re-engagement Techniques:

Camera and Presence:

DO:
□ Camera on (non-negotiable)
□ Look at camera when speaking, not screen
□ Smile and use facial expressions
□ Use hand gestures (visible in frame)
□ Vary vocal tone more than usual

DON'T:
□ Look at yourself in preview
□ Read from a script off-screen
□ Type/click without explaining
□ Go more than 60 seconds without engagement

Remote Screen Sharing Tips:

In-Person Demo Best Practices

Room Setup Checklist:

TECHNOLOGY
□ Adapter cables for room display
□ Backup laptop with demo ready
□ Confirm room A/V works
□ Test connection before meeting
□ Have mobile hotspot backup

POSITIONING
□ Stand if possible (more energy)
□ Face audience, not screen
□ Presenter can see screen without turning
□ All stakeholders can see clearly

MATERIALS
□ One-pager/leave-behind ready
□ Business cards
□ Notepad for their questions
□ Demo script (if needed)

Physical Presence:

Reading the Room (In-Person):

Hybrid Demo Considerations

When part of audience is remote:

EQUAL TREATMENT
□ Look at camera regularly (not just in-room people)
□ Repeat in-room questions for remote audience
□ Use names for remote participants
□ Share screen even if room has display
□ Position camera to include room display

TECHNICAL
□ Dedicated laptop for video call
□ External microphone for room audio
□ Check remote participants can hear/see
□ Assign someone to monitor chat

Engagement Techniques by Modality

Remote-Specific Techniques:

In-Person-Specific Techniques:

Remote-Specific Challenges and Solutions

Challenge: Can't tell if they're engaged

Solution: "I want to make sure I'm covering what matters
to you. On a scale of 1-5, how relevant is what you're
seeing? Drop it in the chat."

Challenge: Technical difficulties on their end

Solution: "It looks like there might be some connectivity
issues. Can you hear me okay? Let's try [solution]. If
it continues, I can send you a recording to supplement."

Challenge: Multitasking / checking email

Solution: Direct engagement — "Tom, I'd love your take
on this specific workflow. Does it match how your team
would use this?"

Challenge: Time zone fatigue

Solution: "I know it's [early/late] for you. Let me make
sure we cover the most important things first. What's
the one thing you absolutely need to see today?"

In-Person-Specific Challenges and Solutions

Challenge: Room technology doesn't work

Solution: Have backup plan — laptop screen for small group,
screenshots printed, or reschedule if critical

Challenge: Stakeholder walks in late

Solution: "Great to have you, [Name]. Let me give you
a 30-second context. We're covering [topic]. I'll be
sure to circle back on anything you need."

Challenge: Side conversations

Solution: Pause, look at the people talking, wait for
quiet. If continues: "I want to make sure I address any
concerns. Should we pause for a moment?"

Challenge: Energy in the room is low

Solution: Change something — stand up, ask a question,
share a surprising stat, offer a break

Recording Best Practices

For Remote Demos:

ALWAYS
□ Ask permission before recording
□ Confirm in chat who is recording
□ Know where recording will be saved
□ Have a plan for sharing recording

RECORDING USE CASES
- Share with stakeholders who couldn't attend
- Reference for follow-up questions
- Training for your team
- Internal deal review

Recording Statement:

"I'd like to record this for anyone who couldn't join
and so you have a reference. The recording will only
be shared with you and [AE Name] for follow-up. Is
everyone okay with that?"

Anti-Patterns

Remote:

• Camera off (hiding undermines trust)
• Monotone delivery (must overcompensate vocally)
• Too much screen time without interaction
• Not using participant names
• Ignoring chat questions
• Sharing desktop instead of window (messy, risky)

In-Person:

• Sitting when you should stand
• Back to audience while presenting
• No eye contact (stuck on screen)
• Reading from notes
• Ignoring room dynamics
• Not adapting to energy levels

Demo Follow-up and Next Steps

Impact: MEDIUM-HIGH

The demo ends when they say yes, not when you stop sharing your screen. What happens in the 24-48 hours after a demo often determines whether the deal moves forward or stalls.

The Demo Close Framework

Before ending the demo:

STEP 1: SUMMARIZE (30 sec)
"So today we covered three things:
 1. [Key capability 1] that addresses [their problem]
 2. [Key capability 2] that enables [their goal]
 3. [Key capability 3] that differentiates us from [alternative]"

STEP 2: CONFIRM VALUE (30 sec)
"Based on what you've seen, does this look like it would
solve the [specific problem] we discussed?"

[Wait for response]

STEP 3: PROPOSE NEXT STEP (30 sec)
"The logical next step would be [specific action]. I have
[day/time] open this week — does that work?"

STEP 4: TIMELINE CONTEXT (15 sec)
"If we move forward, you could be live by [realistic date]."

Next Step Options

The 24-Hour Follow-Up

Email Template:

Subject: [Company] Demo Recap + Next Steps

Hi [Name],

Thank you for your time today. Here's a quick recap
of what we covered:

WHAT YOU SAW
• [Capability 1]: [Brief benefit statement]
• [Capability 2]: [Brief benefit statement]
• [Capability 3]: [Brief benefit statement]

YOUR QUESTIONS
• [Question 1]: [Your answer or "see attachment"]
• [Question 2]: [Your answer or "see attachment"]
• [Question 3]: [Following up with our team by [date]]

RESOURCES
• [Demo recording link] (if recorded)
• [Relevant case study]
• [One-pager / feature sheet]

NEXT STEP
As discussed, our next step is [specific action] on
[date/time]. I'll send a calendar invite shortly.

Let me know if any questions come up before then.

Best,
[Your name]

Follow-Up Timing Framework

Handling Common Post-Demo Situations

Situation: They went dark

Day 5 email:
"Hi [Name], I wanted to follow up on our conversation
last week. I know these decisions involve multiple
stakeholders — is there anything I can provide that
would help move the conversation forward internally?"

Day 10 email:
"Hi [Name], I want to be respectful of your time.
Would it be helpful if I:
a) Connected with someone else on your team?
b) Sent over additional technical documentation?
c) Scheduled a follow-up in a few weeks?

Let me know what works best for your timeline."

Situation: Need to involve more stakeholders

"Happy to include [other stakeholders]. Would it be
helpful to schedule a brief session specifically for
[technical team / executives / etc.]? I can tailor
that conversation to what they'd need to see.

Alternatively, I can send the recording from our
session with a summary for them to review."

Situation: They want to see competitors first

"Completely understand — it makes sense to evaluate
options. A few things that might help your comparison:

1. Here's what customers typically compare [link]
2. Here's our honest perspective on when [competitor]
   might be a better fit [differentiation statement]
3. I'm happy to answer any questions that come up
   during your evaluation

When do you expect to complete your review? I'd love
to reconnect afterward."

Situation: Budget/timing isn't right

"I appreciate you being transparent about timing. Let's
do this — I'll reach back out in [timeframe], and in
the meantime, I'll send you some resources that might
be helpful:

• [Case study on ROI]
• [Calculator for building business case]
• [Content about the problem space]

Is there a better time in [Q/year] to reconnect?"

Post-Demo Internal Sync

After every demo, document:

DEAL INTELLIGENCE
□ Attendees and roles
□ Key pain points validated
□ Features/capabilities that resonated
□ Objections raised and how handled
□ Competition mentioned
□ Timeline/urgency signals
□ Budget indicators
□ Decision process clarified

NEXT STEPS
□ What was agreed
□ Who owns what
□ When it should happen
□ What could block progress

RED FLAGS
□ Low engagement from key stakeholder
□ New requirements surfaced
□ Pricing/timing concerns
□ Political dynamics

Champion Enablement

Your champion needs ammunition. Provide:

Champion coaching:

"[Name], you mentioned needing to get [CFO] on board.
What would be most helpful for that conversation?
I can provide:

• A 5-minute executive summary video
• ROI analysis specific to your numbers
• References from similar companies

What would move the needle with [CFO]?"

Momentum Maintenance

Keep deals alive between steps:

Following Up on Stalled Deals

The 3-3-3 Rule:

• 3 value touches
• 3 check-in touches
• 3 break-up touches

TOUCH 1-3: VALUE
Send relevant content without asking for anything

TOUCH 4-6: CHECK-IN
"How is [project/initiative] going? Any questions I can answer?"

TOUCH 7-9: BREAK-UP
"I haven't heard back and want to respect your inbox.
I'll assume timing isn't right and will check in next
[quarter]. If anything changes before then, I'm here."

Anti-Patterns

• No recap email — Leaving demo to memory
• Generic follow-up — Not personalized to conversation
• Slow response — Taking days to answer their questions
• Vague next step — "Let's talk soon" vs specific date
• Over-following-up — 5 emails in a week
• Abandoning too fast — Giving up after 2 touches
• Not enabling champion — Leaving them without tools
• No internal documentation — Losing deal intelligence

Feature vs Benefit Demonstration

Impact: CRITICAL

Features are what your product does. Benefits are why anyone should care. The gap between these is where most demos fail.

The Feature-Benefit Translation

The Translation Formula

FEATURE → "Which means..." → ADVANTAGE → "So you can..." → BENEFIT → "Which saves/earns you..." → VALUE

Example Walkthrough:

Feature:    "We have automated deployment pipelines"
            ↓ which means...
Advantage:  "Code goes from commit to production without manual steps"
            ↓ so you can...
Benefit:    "Ship features to customers the same day they're ready"
            ↓ which saves/earns you...
Value:      "2 weeks faster time-to-market on average"

Good vs Bad Demo Narration

Bad (Feature-focused):

"This is our dashboard. Over here you can see we have
real-time analytics. We support 50+ integrations.
You can create custom reports with drag-and-drop.
We also have role-based permissions and audit logs."

Good (Benefit-focused):

"Remember you mentioned your CFO asks for pipeline
reports every Monday and it takes your team 3 hours
to pull the data together? Let me show you what
Monday morning looks like with [Product].

[Shows dashboard]

Your CFO gets this in her inbox at 6am automatically —
the exact data she needs, formatted how she wants it.
Your team reclaims those 3 hours. That's 150 hours a
year your team gets back for actual selling."

The "So What?" Test

For every feature you show, answer three questions:

1. So what? — Why does this matter? 2. For whom? — Who benefits specifically? 3. How much? — What's the quantified impact?

Testing Your Demo Script:

Persona-Specific Feature Translation

The same feature means different things to different people:

Feature: Role-Based Access Control

The "Before and After" Technique

Don't just show the feature — show the transformation.

BEFORE (Their current pain):
"Right now, when Sarah needs last quarter's sales data,
she has to export from Salesforce, wait for IT to grant
database access, pull from two other systems, and manually
combine everything in Excel. You said that takes about 4 hours."

AFTER (With your solution):
"Let me show you Sarah's new Monday morning..."
[Demo the workflow]
"Same data, same accuracy, 4 minutes. That's 4 hours
back in Sarah's week — every single week."

Feature Prioritization Matrix

Not all features deserve demo time:

Differentiator Framework

Differentiator = Unique to you + High value to them + Hard to replicate

Questions to identify differentiators:

• What can we do that competitors cannot?
• What do we do 10x better?
• What's our unfair advantage?
• What do customers cite as why they chose us?

Benefit Language Patterns

Instead of:

• "We have..." → "You get..."
• "Our platform..." → "Your team..."
• "This feature..." → "This means you can..."
• "We built..." → "This saves you..."

Power Phrases:

Anti-Patterns

• Feature listing — "We have X, Y, Z, and also A, B, C..."
• Assuming benefit is obvious — "And here's our API" [no explanation]
• Technical jargon as benefit — "It's built on Kubernetes" [who cares?]
• Generic benefits — "Save time and money" [be specific]
• Competitor feature matching — "We have that too" [show your way]
• Feature dumping — Showing everything to show value

Demo Storytelling Arc

Impact: CRITICAL

Every great demo follows a narrative structure. You're not showing features — you're telling a story where your prospect is the hero and your product is the guide.

The 5-Act Demo Structure

Act 1: The Hook (2 minutes)

Goal: Earn the right to their attention.

Elements:

• Acknowledge their time is valuable
• State the outcome they'll see (not features)
• Confirm agenda and timing
• Ask permission to proceed

Good Hook:

"Thanks for joining today. By the end of this 30 minutes,
you'll see exactly how [Company] can cut your deployment
time from 4 hours to 15 minutes — with zero additional
headcount. I'll show you the three workflows that matter
most based on what [AE Name] shared from your discovery
call. Does that work, or is there something specific
you'd like me to cover?"

Bad Hook:

"Thanks for joining. I'm going to walk you through our
platform today. We have a lot of features to cover so
let's get started. Here's our home screen..."

Act 2: The Problem (5 minutes)

Goal: Make them feel the pain before showing the cure.

Techniques:

• Recap what you learned in discovery
• Ask confirming questions
• Quantify the cost of the problem
• Build emotional tension

Problem Validation Script:

"From our last conversation, I understand that your team
spends about 4 hours on each deployment, and you're doing
roughly 20 deployments a month. That's 80 hours of
engineering time — about half an FTE. And [Name] mentioned
the real cost isn't just time — it's the 2-3 production
incidents per quarter that come from manual errors.
Am I capturing that correctly?"

[PAUSE FOR CONFIRMATION]

"And you mentioned the bigger picture is that this is
blocking your ability to ship the features your customers
are asking for. Your roadmap is backing up because
releases take so long. Is that still the case?"

Act 3: The Solution (15 minutes)

Goal: Transform their world through your product.

The 3-3-3 Rule:

• Show 3 core workflows maximum
• Spend 3-5 minutes on each
• Connect each to 3 specific benefits they mentioned

Solution Flow:

For each workflow:

1. SETUP (30 sec)
   "Let me show you how [workflow] works..."

2. CONTEXT (30 sec)
   "This is what [Persona] would see when they need to..."

3. ACTION (2-3 min)
   Actually perform the action in real-time

4. OUTCOME (1 min)
   "And now [result]. This is what [Name] mentioned
    would save your team [X hours/dollars]."

5. BRIDGE (30 sec)
   "That connects to the next thing I want to show you..."

Act 4: The Proof (5 minutes)

Goal: Eliminate doubt with evidence.

Proof Elements:

Act 5: The Close (3 minutes)

Goal: Create forward momentum.

Closing Framework:

1. SUMMARIZE
   "So today we saw [3 key things] that would help you
    [achieve outcome]."

2. CONFIRM VALUE
   "Does this look like it would solve the [problem]
    we discussed?"

3. NEXT STEP
   "The logical next step would be [specific action].
    Does [specific date/time] work to [next action]?"

4. TIMELINE
   "If everything goes well, you could be live by [date]."

Timing Discipline

Anti-Patterns

• Starting with "About Us" — They don't care about your company yet
• Feature-first structure — "First I'll show login, then dashboard..."
• No problem validation — Jumping straight to solution
• Rushed close — Running out of time for next steps
• All solution, no proof — Missing social proof and metrics
• Linear walkthrough — Following the UI instead of their workflow

Live Demo Execution Techniques

Impact: HIGH

The difference between a good demo and a great demo is execution. Same content, same features, wildly different outcomes based on how you deliver.

The Demo Presenter Mindset

You are not:                    You are:
- A feature tour guide          - A trusted advisor
- An order taker               - A problem solver
- A script reader              - A storyteller
- A product expert only        - A business consultant

Pacing and Timing

The Demo Rhythm:

Timing Markers:

5 min in:   Check engagement, adjust if needed
10 min in:  First major value demonstration should be done
Halfway:    Brief pause — "How are we doing on time?"
5 min left: Wrap solution section, move to close
End:        Never go over without permission

Narration Techniques

1. Think-Aloud Narration

DON'T: [Silent clicking]

DO:    "Now I'm going to create a new campaign...
        I'll select our target segment here...
        And watch what happens when I hit 'Launch'..."

2. Outcome-First Narration

DON'T: "First, click here, then here, then select this..."

DO:    "In about 30 seconds, you're going to see a full
        pipeline report generated automatically. Let me
        show you how your team would do this... [click]
        And there it is."

3. Callback Narration

"This is exactly what Sarah mentioned in our discovery
call — the manual process that takes 4 hours. Watch
how this happens now... [demo]... Four minutes."

Screen Management

The Three-Window Rule:

• Maximum 3 browser tabs/windows visible
• Close everything not needed before demo
• Pre-load pages to avoid wait times

Screen Layout:

┌─────────────────────────────────────────────┐
│ DEMO ENVIRONMENT                            │
│ (Full screen or 80% of screen)              │
│                                             │
│                                             │
└─────────────────────────────────────────────┘
┌────────────────┐    ┌──────────────────────┐
│ NOTES/SCRIPT   │    │ ATTENDEE VIEW        │
│ (If needed)    │    │ (If remote)          │
└────────────────┘    └──────────────────────┘

Navigation Best Practices:

Handling Technical Issues

Preparation Checklist:

□ Test demo environment 1 hour before
□ Close unnecessary applications
□ Disable notifications (Slack, email, system)
□ Check internet connection/backup hotspot
□ Have backup screenshots/video ready
□ Know the recovery plan for each section

When Things Break:

The Magic Phrase:

"This is actually a great opportunity to show you how
responsive our support team is. Let me [action]."

Engagement Techniques

1. Planned Checkpoints

Every 5-7 minutes:

"Does this make sense so far?"
"Is this what you were hoping to see?"
"Should I go deeper here or move on?"
"What questions are coming up for you?"

2. Interactive Moments

"What would you do next here?"
"Take a guess — what do you think happens when I click this?"
"If you were your end user, what would you want to see?"

3. Collaborative Problem-Solving

"Let's say [prospect's scenario] — how would you handle
that today? Let me show you how that same scenario
works in [product]..."

The Art of the Pause

When to pause:

Voice and Presence

Vocal Variety:

Energy Management:

Start:      80% energy (confident, warm)
Problem:    70% energy (empathetic, serious)
Solution:   90% energy (excited, passionate)
Proof:      80% energy (assured, credible)
Close:      85% energy (confident, expectant)

Recovery from Mistakes

Minor mistake (typo, wrong click):

Light acknowledgment: "Let me get that right..."
[Fix and continue]

Moderate mistake (showed wrong thing, wrong data):

"Good catch — that's not what I meant to show. Let me
actually show you the correct [thing]..."

Major mistake (broke something, wrong demo entirely):

"I appreciate your patience — that's not the experience
I wanted to show you. Let me [fix / switch to backup].
I'll make sure to follow up with the full demonstration
via [recording / second call]."

Ending Strong

The Last 60 Seconds:

0:45 - Summarize (3 key points)
0:30 - Confirm value ("Does this solve [problem]?")
0:15 - Next step ("The logical next step is...")
0:00 - Commitment ("Can we schedule [action] for [date]?")

Anti-Patterns

• Apology loop — "Sorry, let me just... sorry, that's not..."
• Feature racing — Clicking so fast no one can follow
• Reading slides — Instead of talking with them
• Silence while clicking — No narration
• Clock watching — Visible anxiety about time
• Over-recovery — Spending 5 minutes on a 30-second issue
• Energy flatline — Same tone throughout
• Not reading the room — Missing obvious signals

Objection Handling During Demos

Impact: HIGH

Objections during demos are buying signals. They mean the prospect is engaged enough to think critically. Handle them well, and you strengthen the deal. Handle them poorly, and you lose trust.

The Objection Framework: LAER

L - LISTEN    → Hear the full objection without interrupting
A - ACKNOWLEDGE → Validate their concern is reasonable
E - EXPLORE   → Understand the root cause with questions
R - RESPOND   → Address with facts, proof, or reframing

Common Demo Objections by Category

Price/Value Objections:

Capability Objections:

Trust Objections:

Timing Objections:

Objection Response Scripts

"It's too expensive"

LISTEN:     [Let them finish]

ACKNOWLEDGE: "Price is definitely an important consideration,
             and I appreciate you being direct about it."

EXPLORE:    "Help me understand — when you say expensive,
             is it the total investment, the per-user cost,
             or the timing of the spend?"

RESPOND:    [Based on their answer]

             If ROI unclear:
             "Let me put it in context. You mentioned
             [problem] costs you [X hours/dollars] per
             [period]. At [price], you'd break even in
             [timeframe], and everything after that is
             return. Does that math work for your team?"

             If budget timing:
             "Would it help to look at quarterly billing
             or starting with a smaller scope to fit
             this fiscal year's budget?"

"We need [feature you don't have]"

LISTEN:     [Understand the specific need]

ACKNOWLEDGE: "That's a fair requirement. I want to be
             honest about where we are with that."

EXPLORE:    "Can you help me understand how critical
             that is? Is it a must-have for launch, or
             something you'd need eventually?"

RESPOND:    [Depends on situation]

             If on roadmap:
             "That's on our roadmap for [quarter]. For
             most customers, [workaround] handles this
             in the interim. Would that work for your
             timeline?"

             If not planned:
             "We don't have that today and it's not on
             our immediate roadmap. However, [alternative
             approach]. Would that solve the underlying
             problem you're trying to address?"

             If genuinely blocking:
             "I want to be honest — if that's truly a
             must-have, we may not be the right fit
             today. But let me share what [similar
             customer] did in a similar situation..."

"Competitor X does this better"

LISTEN:     [Understand which competitor, which feature]

ACKNOWLEDGE: "I'm glad you're doing thorough research.
             [Competitor] is a solid product."

EXPLORE:    "What specifically stands out about their
             approach to [feature]? I want to make sure
             I'm comparing apples to apples."

RESPOND:    "Here's how I'd think about it. [Competitor]
             does [X] well. Where we differentiate is
             [Y], which is why [customer type] typically
             chooses us. The question is which of those
             is more important for [their specific use case].

             [Pause for their input]

             Let me show you [our differentiated approach]
             so you can compare directly."

Objection Handling Techniques

1. The Feel, Felt, Found

"I understand how you feel. [Similar company] felt
the same way initially. What they found was [positive
outcome]. Would you like to hear about their experience?"

2. The Isolation Technique

"If we could solve [specific objection], would everything
else we've discussed work for your team?"

3. The Reframe

Objection: "The learning curve seems steep."

Reframe:   "You're right that there's learning involved.
            The question is: what's the cost of your team
            spending another year with [current painful
            process] vs. investing 2 weeks in training
            and then having [better outcome] forever?"

4. The Third-Party Story

"[Similar company] had the exact same concern. Here's
what happened... [story with positive outcome]"

Parking Lot Technique

When objection is valid but derailing:

"That's an important point and I want to give it proper
attention. Can I note that down and circle back to it
after I show you [current topic]? I don't want to
shortchange either topic."

When to use:

• Technical deep-dive questions during executive demo
• Price discussions before value is established
• Feature requests that need product team input

Reading Objection Severity

Objections That Aren't Really Objections

Turning Objections into Commitments

After successfully handling objection:

"So if we can confirm [what you just addressed], and
[other requirements], would you be ready to move
forward with [next step]?"

Anti-Patterns

• Getting defensive — Taking objections personally
• Arguing — Trying to prove them wrong
• Dismissing — "That's not really an issue"
• Over-handling — Going on too long after it's resolved
• Not confirming — Moving on without checking if resolved
• Ignoring red flags — Plowing ahead despite clear blockers
• Feature promising — Committing to unplanned features
• Badmouthing competitors — Unprofessional and backfires

Handling Technical Questions During Demos

Impact: HIGH

Technical questions during demos can either derail your narrative or strengthen your credibility. The key is knowing when to answer, when to defer, and how to do both gracefully.

The Question Triage Matrix

The Three Response Modes

Mode 1: Answer Now

When:  Question is quick, relevant, strengthens narrative

"Great question. Yes, we support [X]. In fact, let me
show you that quickly... [10-second demo]. Now, back
to [current topic]..."

Mode 2: Defer Gracefully

When:  Answer would take >2 minutes or derail the demo

"That's an important question and I want to give it
proper attention. Let me note that down [write it down
visibly] and we can either dig into it at the end or
schedule a technical deep-dive with our solutions team.
Does that work?"

Mode 3: Bridge and Redirect

When:  Question is related but better answered in context

"That's actually a perfect lead-in to what I'm about
to show you. Hold that thought for about 2 minutes,
and I think I'll answer it better with a live example."

Question Categories and Responses

Security Questions:

Integration Questions:

Performance Questions:

The "I Don't Know" Script

When you genuinely don't know:

"That's a great question, and I want to give you an
accurate answer rather than guess. Let me write that
down and get you a precise response by [specific time].
Is that okay?"

Never:

• Make up an answer
• Say "I think so"
• Promise features you can't confirm
• Pretend you didn't hear

Managing the Question Dominator

When one person asks 80% of questions:

Strategy 1: Acknowledge and broaden
"Great questions, [Name]. Let me also check in with
the rest of the group — any questions from others
before we move on?"

Strategy 2: Validate and defer
"[Name], you clearly have a strong technical background.
I'd love to set up a dedicated session with our solutions
architect to go deep on these. For now, let me make sure
we cover the core use cases for the whole team."

Strategy 3: Answer then redirect
"Good question. [Quick answer]. Now, [Other person],
does that address the concern you mentioned earlier
about [topic]?"

Turning Questions into Opportunities

Question as proof point:

Q: "Can it handle complex approval workflows?"
A: "Absolutely. In fact, let me show you exactly that.
   This is a workflow [Similar Company] built that has
   seven approval stages across three departments..."

Question as discovery:

Q: "Does it integrate with [specific tool]?"
A: "Yes. Actually, I'm curious — how central is [tool]
   to your workflow? Understanding that helps me show
   you the right integration depth."

Question as commitment:

Q: "What kind of training do you offer?"
A: "We have comprehensive onboarding. If training is
   important — and I'm guessing it is given your team
   size — would that be something you'd want included
   in the proposal?"

The Parking Lot Method

Visual parking lot for remote demos:

Share a note or slide with:

┌──────────────────────────────────────────────┐
│ PARKING LOT - Questions for Follow-up        │
├──────────────────────────────────────────────┤
│ 1. SSO integration specifics - [Name]        │
│ 2. API rate limits - [Name]                  │
│ 3. Custom field options - [Name]             │
└──────────────────────────────────────────────┘

"I'm putting this in our parking lot so we don't
lose it. We'll come back to it at the end."

End of demo parking lot review:

"Let me quickly go through our parking lot.
[Question 1] — [Brief answer or commit to follow up]
[Question 2] — [Brief answer or commit to follow up]
Any of these need more time today, or should I follow
up via email with the details?"

Handling "Gotcha" Questions

Signs of a gotcha:

• Asked in front of group
• About known weakness
• Competitor-planted question
• Designed to embarrass

Response framework:

1. Stay calm (don't get defensive)
2. Acknowledge the valid concern
3. Provide honest context
4. Pivot to strength

Example:
Q: "I heard your mobile app is basically unusable."

A: "Mobile has been a focus area for us. Earlier this
   year, we completely rebuilt the app, and the reviews
   have jumped from 2.5 to 4.5 stars. I'd be happy to
   show you the current experience if mobile is
   important to your team — is it?"

Question Response Templates

For feature confirmation:

"Yes, we do that. Would you like to see it now, or
should I note it for later?"

For feature gap:

"We don't have that today. [Alternative approach] is
how our customers typically handle that. Would that
work for your use case?"

For roadmap items:

"That's on our roadmap for [timeframe]. I can't make
promises, but I can connect you with our product team
if it's critical for your decision."

For pricing:

"Pricing depends on [factors]. Let me make sure we
scope your needs correctly first, and I'll have
[AE Name] put together a specific proposal."

Anti-Patterns

• Answering before they finish — Interrupting the question
• Over-answering — 5-minute response to simple question
• Getting defensive — Taking questions as attacks
• Faking knowledge — Guessing or making things up
• Never deferring — Trying to answer everything
• Losing control — Demo becomes Q&A session
• Forgetting parking lot — Not following up on deferred questions
• One-word answers — "Yes." with no context

Demo Timing and Pacing

Impact: HIGH

Time is the most precious resource in a demo. Master the clock, and you control the outcome. Let time control you, and you'll always be rushing through your close.

The Golden Rules of Demo Timing

RULE 1: Never run over without permission
RULE 2: Leave 20% buffer for questions
RULE 3: Most important content in first 60%
RULE 4: Close should never be rushed
RULE 5: Better to end early than run long

Time Allocation by Demo Length

15-Minute Demo (Teaser)

30-Minute Demo (Discovery)

45-Minute Demo (Full)

60-Minute Demo (Enterprise)

Pacing Patterns

The Energy Wave:

ENERGY
High  │     *****     *****
      │    *     *   *     *   ***
      │   *       * *       * *
      │  *         *         *
Low   │ *
      └─────────────────────────────
        Open  Problem  Solution  Close

Start strong, dip for problem empathy,
peak at solution "aha" moments,
finish with confident close

Speed Variations:

Time Check Techniques

Built-in checkpoints:

10-MINUTE MARK:
"We're about 10 minutes in. I want to make sure we
have time for [remaining topics]. Are we on track,
or should I adjust?"

HALFWAY POINT:
"We're at the halfway point. Good time to check —
any questions before we continue? And is there anything
I should prioritize in the back half?"

5 MINUTES REMAINING:
"I want to be respectful of your time. Let me make
sure we cover [close] before we wrap."

When running behind:

OPTION 1: Get permission
"I want to make sure I show you [important thing],
but we're a bit over. Can you stay 5 more minutes,
or should I schedule a follow-up?"

OPTION 2: Prioritize ruthlessly
"In the interest of time, let me skip to [most
important remaining thing] and save [other thing]
for our next conversation."

OPTION 3: Offer asynchronous
"Let me send you a 5-minute video covering [topic]
so we can stay on schedule today."

Managing Different Stakeholder Time

When stakeholders have different availability:

EXECUTIVES LEAVING EARLY:
Structure the demo so executive-relevant content
(ROI, strategic value, dashboards) is in first third.

"[Executive Name], I know your time is limited.
In the first 10 minutes, I'll show you the strategic
view. The team can stay for the deeper dive if
you need to drop off."

TECHNICAL DEEP-DIVE NEEDED:
Save detailed technical content for a separate call.

"I could spend 30 minutes on our API alone. Let's
schedule a technical deep-dive with your engineers
so we can give it proper attention."

The Question Time Trade-off

Question handling impact on time:

Parking lot time management:

"Let me add that to our parking lot. If we have time
at the end, we'll address it. Otherwise, I'll follow
up via email with the detailed answer."

Timing Signals to Watch

Preparation for Time Mastery

Before every demo:

□ Know exactly how long each section takes
□ Identify what can be cut if needed
□ Identify what must be shown no matter what
□ Have a 10-minute version ready
□ Have a 20-minute version ready
□ Know your cut points (where you can gracefully exit)

The "minimum viable demo":

If you only had 10 minutes, what would you show?

1. [Primary value prop — 5 minutes]
2. [Proof point — 2 minutes]
3. [Close — 3 minutes]

Know this cold. Use it when time gets tight.

Recovering from Time Disasters

When you're 10+ minutes behind:

"I realize I've taken us deep into [topic], and I
want to respect your time. Let me do two things:

1. Quickly show you [one critical thing]
2. Schedule a follow-up for [remaining content]

Would [day/time] work to continue?"

When they cut the meeting short:

"Understood. Before you go, I want to leave you with
one thing: [most important point]. I'll send a
recording of what we didn't cover, and let's
reconnect [proposed time]."

Anti-Patterns

• No agenda timing — Going in without time plan
• Feature wandering — Getting lost in tangents
• Q&A death spiral — Questions eat all time
• Rushed close — Running out of time for next steps
• Running over without asking — Disrespects their time
• Same pace throughout — Monotonous delivery
• No buffer — Planning 30 min of content for 30 min call
• Not knowing cut points — Can't adapt when time shifts