Forward Deployed Engineer 101: Demo and Stakeholder Communication (Showing Progress, Managing Expectations)

Demo and Stakeholder Communication (Showing Progress, Managing Expectations)

Demo and Stakeholder Communication: A Field-Ready Study Guide

What This Is
As a Forward Deployed Engineer (FDE), your job isn’t just to build—it’s to show progress, align expectations, and keep stakeholders (customers, PMs, executives) bought in while navigating real-world constraints (security, latency, legacy systems). Example: You’re deploying a fraud-detection model on-premise for a bank with strict air-gapped rules. The CISO demands a live demo in 48 hours, but your model’s inference API keeps failing due to missing dependencies. You need to: 1. Show progress (even if it’s messy) to avoid a "black box" panic.
2. Manage expectations (e.g., "We’ll demo the pipeline without real-time data first").
3. De-risk the demo (e.g., pre-load sample data, mock the API, or use a read-only replica).

Fail here, and the customer loses trust—even if your tech is flawless.

Key Terms & Concepts

• Demo Cadence: Pre-agreed schedule for showing progress (e.g., "Every Friday at 2 PM, we’ll demo the latest build"). Critical for long projects to avoid "surprise" feedback.
• Stakeholder Map: A living doc listing who cares about what (e.g., CISO = security, CFO = cost, end users = UX). Tools: Miro, Lucidchart, or a simple Markdown table.
• Ask vs. Infer: The customer says they need X (the "ask"), but the data/mission suggests Y (the "infer"). Example: A customer asks for a dashboard, but their real problem is slow data ingestion—fix the pipeline first.
• Demo Environment: A replica of the customer’s setup (or a sandbox) where you test demos before showing them. Tools: Terraform (for infra), Docker (for containers), or a VM snapshot.
• Pre-Mortem: A meeting before a demo/go-live to brainstorm "What could go wrong?" and mitigate risks. Example: "If the VPN drops, we’ll fall back to a local Jupyter notebook."
• Progress Metrics: Quantifiable proof of progress (e.g., "Model accuracy: 85% → 92%", "Pipeline latency: 10s → 2s"). Avoid vague updates like "We’re making progress."
• Scope Lock: A hard boundary on what’s in/out of a demo or sprint. Example: "This demo covers the data pipeline, not the UI—we’ll show that next week."
• Hotfix Drill: A pre-planned way to patch critical issues during a demo (e.g., "If the API fails, we’ll switch to a cached response"). Tools: kubectl rollout undo, git revert, or a backup VM.
• Customer Proxy: A technical contact on the customer’s side who can unblock you (e.g., "Ask Raj for the firewall rules"). Always identify this person early.
• ATO (Authorization to Operate): A security approval required for deployments in government/enterprise. Missing this = demo fails. Tools: NIST RMF, eMASS.
• ACO (Authority to Connect): Permission to plug into a customer’s network. Example: "We need an ACO to deploy our model on their classified network."
• IAM (Identity and Access Management): Who can access what. Example: "The demo user needs read-only IAM roles to the S3 bucket." Tools: AWS IAM, Okta, Active Directory.

Step-by-Step / Field Process

1. Pre-Demo: Plan and Rehearse

• Map stakeholders: Who’s attending? What’s their priority? (e.g., CISO = security, PM = timeline, end user = usability).
• Tool: Create a table in Notion/Google Docs with columns: Name, Role, Priority, Demo Focus.
• Define success: What’s the minimum viable demo? (e.g., "Show the pipeline ingesting data, not the full model output").
• Build the demo environment:
• Use Terraform to spin up a replica of the customer’s infra (or a sandbox).
• Pre-load sample data (e.g., aws s3 cp s3://demo-data/ ./data --recursive).
• Mock external dependencies (e.g., python -m http.server 8000 for a fake API).
• Rehearse:
• Run the demo exactly as you’ll show it (same network, same permissions).
• Time it (aim for 50% of the allotted time to leave room for Q&A).
• Record it (e.g., asciinema for CLI demos, OBS for GUI).

2. During the Demo: Control the Narrative

• Set the stage:
• "Today we’ll show X, not Y. Here’s what success looks like: [metric]."
• "If we hit a snag, we’ll [fallback plan]." (e.g., "switch to a cached response").
• Show progress, not perfection:
• "Here’s the raw output—it’s not pretty, but it proves the pipeline works."
• "This is a mockup of the UI; the real version will have [feature]."
• Manage expectations in real time:
• If something breaks: "This is a known issue we’re fixing—here’s the workaround."
• If asked for an unplanned feature: "That’s out of scope for today, but we’ll add it to the backlog."
• Engage stakeholders:
• Ask for feedback early: "Does this direction align with your goals?"
• Assign action items: "Can you confirm the firewall rules by EOD?"

3. Post-Demo: Follow Up and Document

• Send a recap within 24 hours:
• What was shown, what worked, what didn’t, next steps.
• Tool: Email template in Gmail or a Slack message with a Loom video.
• Update the stakeholder map:
• Who’s now a blocker? Who’s an advocate? Adjust your strategy.
• File tickets for follow-ups:
• "Demo showed we need to optimize the database query—here’s the Jira ticket."
• Debrief with your team:
• "What surprised the customer? What did they ignore? What’s their real priority?"

Common Mistakes

FDE Interview / War Story Insights

Interview Questions They’ll Ask

1. "You’re demoing a model to a customer, and they say, ‘This is too slow.’ The real issue is their 10-year-old database, but they blame your model. How do you respond?"
2. Answer: "I’d say, ‘Let’s test the bottleneck—can we run a query directly on your DB to compare?’ Then show the data: ‘The DB took 5s, our model took 0.5s.’" Why: Redirect to facts, not opinions.
3. "The customer demands a feature that wasn’t in the original scope. How do you handle it?"
4. Answer: "I’d ask, ‘What’s the business impact of this feature?’ If it’s critical, I’d propose a trade-off: ‘We can add this, but it’ll delay X by 2 weeks. Is that acceptable?’" Why: Scope creep kills projects—always tie changes to trade-offs.

War Stories (How to Frame Your Experience)

• The "Black Box" Demo: You’re showing a data pipeline, but the customer keeps asking, "Where’s the output?" You realize they expected a GUI, not a CLI. Lesson: Always confirm how they want to see progress (e.g., "Do you want to see the raw logs, or a summary dashboard?").
• The Security Surprise: You demo a model in the cloud, but the customer says, "We can’t use AWS—we need an on-prem solution." Lesson: Always ask about constraints before building (e.g., "What’s your deployment environment?").
• The Executive Escalation: The CFO attends your demo and says, "This looks like a science project. How does this save us money?" Lesson: Always tie demos to business metrics (e.g., "This model reduces fraud losses by 15%, saving $2M/year").

Quick Check Questions

1. You’re demoing a model to a customer, but their network blocks your API. What’s your first step?

2. Answer: Fall back to a pre-loaded dataset or a local mock API (e.g., python -m http.server). Explanation: Always have a backup plan for network issues.

3. The customer says, "This demo is useless—it doesn’t show real data." How do you respond?

4. Answer: "You’re right—let’s schedule a follow-up with real data. For today, we wanted to show the pipeline works end-to-end." Explanation: Acknowledge the feedback, then redirect to the demo’s purpose.

5. You’re on site, and the customer’s CISO says, "This demo violates our security policy." What do you do?

6. Answer: "Can you point me to the specific policy? We’ll adjust the demo to comply." Explanation: Never argue with security—ask for the rule and adapt.

Last-Minute Cram Sheet

1. Demo checklist: Rehearse in customer env → pre-load data → mock dependencies → record it.
2. Stakeholder map: Who’s in the room? What’s their priority? (CISO = security, PM = timeline, user = UX).
3. Scope lock: "This demo covers X, not Y. We’ll show Y next week."
4. Fallback plan: Always have a backup (cached data, screenshots, mock API).
5. Progress metrics: Show numbers (e.g., "Accuracy: 85% → 92%"), not vague updates.
6. ⚠️ Never demo in your dev environment—always use a replica of the customer’s setup.
7. ⚠️ Always confirm constraints first (e.g., "Can we use cloud? What’s your ATO process?").
8. ATO = Authorization to Operate (security approval for deployments).
9. ACO = Authority to Connect (permission to plug into their network).
10. IAM = Identity and Access Management (who can access what). Example: aws iam list-users.