Module 4: The Demo That Closes · FDE Course

A pilot that works technically can still fail the demo. An FDE demo is not a product demo. It is a trust-building exercise that has to answer one question in the stakeholder's mind: can I rely on this team and this approach to solve my real problem? This module covers the structure of demos that build trust, how to handle live questions without over-committing, and the critical difference between informing and committing.

What Makes an FDE Demo Different

A traditional product demo shows what a product can do in its best-case scenario: clean data, ideal inputs, expected outputs. The goal is to create excitement and reduce objections. The salesperson controls the script, uses pre-prepared data, and rehearses every transition.

An FDE demo shows what was built with the customer's actual data, including the cases where it struggled. The goal is not to reduce objections but to demonstrate honest competence: "We built this, it works on your data, here is where it performs well, here is where it needs tuning, here is what we propose to do about the gaps." Stakeholders who have been burned by polished vendor demos often respond better to this kind of honesty than to a perfect presentation.

The trust equation Trust = competence + honesty. A demo that shows only the wins and hides the failures earns half the trust. A demo that shows where the system struggled and proposes a clear path to improvement earns the other half.

The Five-Step Trust Arc

The most effective FDE demos follow a consistent structure regardless of the specific use case:

Restate the problem in the customer's language

Open by describing the problem as the customer described it during discovery, using their terminology. This signals that you were listening and that the pilot was built for their specific context, not a generic use case.

Show the approach before the output

Walk through how the system works before showing what it produces. A stakeholder who understands the approach can evaluate the output critically. A stakeholder who only sees the output has no basis for trust.

Demo on data the stakeholder recognizes

Use the customer's own data, if possible the specific documents or cases the stakeholder cares about. The moment a stakeholder sees their own data processed correctly is the trust inflection point of every demo.

Name the failures honestly and explain them

Show at least one case where the system struggled. Explain why. Then explain what would be required to address it. This is the step most presenters skip, and it is the step that builds the most trust with technically sophisticated stakeholders.

Propose a specific next step

End with a clear, specific, and bounded next step: "We propose a two-week second phase to address the edge cases we identified, using the additional sample data your team will provide." This gives the stakeholder a decision to make, not an open question.

Showing Process, Not Just Output

Enterprise AI stakeholders are increasingly skeptical of black boxes. A system that produces an answer without showing its reasoning is harder to trust than one that shows its work. During an FDE demo, showing process means walking through the intermediate steps: what data was retrieved, what the prompt looked like, what the model reasoned, and where the output came from.

This is not just a trust-building technique. It is also practically useful. When a stakeholder sees a wrong answer and can inspect the reasoning chain, they can often identify the source of the error themselves: the wrong document was retrieved, or the prompt was ambiguous on a specific case. This turns a failure from an embarrassment into a collaborative debugging session, which is a much better outcome for the relationship.

Fig 4 · Black Box vs. Process Demo

Handling "Can You Do X?" Live

Every FDE demo produces the moment someone in the room says "can you do X?" where X is something outside the pilot scope. This question is dangerous because it arrives in real time, the FDE knows the answer may technically be yes, and saying yes feels collaborative and responsive. The problem is that "yes" in that moment is a scope commitment made without any scoping process.

The correct response is a phrase variant of: "That is a good question and I want to give you an honest answer rather than a quick one. Let me note it down, look at what would be required, and come back with a realistic assessment before the end of the week." This response does several things simultaneously. It treats the question seriously. It avoids a commitment you cannot fulfill. It sets a specific follow-up timeframe. And it keeps the demo moving.

What happens when an FDE says yes to too many "can you do X?" questions? ▼

The engagement expands beyond what can be delivered in the agreed timeline and budget. The FDE ends up in a classic enterprise consulting trap: the scope is now defined by a series of hallway conversations and demo-room commitments rather than the signed scoping document. When the engagement ends without delivering on those informal commitments, the customer feels misled even if everything in the original scope was delivered. Say yes only after a scoping conversation, never in the demo room.

Inform vs. Commit

Every FDE demo serves one of two purposes. An inform demo shares findings: this is what we built, this is how it performs, this is what we learned. It does not require the customer to make a decision. It advances the relationship by demonstrating progress. An commit demo asks the customer to make a specific decision: approve a next phase, allocate additional resources, sign off on productization.

FDEs who do not distinguish between these two demo types often run commit demos when they should be running inform demos. A stakeholder who was not expecting to make a decision in a meeting often reacts badly to being asked for one. The correct sequence is usually: inform demo first, let the stakeholder process, then schedule a commit conversation separately.

Text · Demo Script Outline (inform format)

FDE DEMO SCRIPT — INFORM FORMAT

[2 min] Problem restatement
"At the start of this engagement, you described the problem as..."
"Our goal for the pilot was to demonstrate that we could..."

[5 min] Approach walkthrough
"The pilot has three components. The first is..."
"When a user asks a question, here is what happens step by step..."

[8 min] Live demonstration on customer data
"I am going to use the [specific document set] you provided..."
"Watch what happens when I run [representative query]..."
"Here is the intermediate reasoning the system produced..."

[5 min] Honest performance review
"On these [N] cases, the system performed well..."
"On these [M] cases, we saw [specific issue]..."
"The root cause is [specific technical reason]..."
"The path to fixing it is [specific approach]..."

[5 min] Proposed next step
"Based on what we have seen today, we propose..."
"This would take [time] and require [specific input from your team]..."
"We will follow up with a written proposal by [specific date]..."

[Questions]
For any 'can you do X?' questions:
"Good question. Let me note that and give you a proper answer
rather than a quick one. I will follow up by [specific date]."

Try this

Think of a demo you have watched or given that did not go well. Map it to the five-step trust arc. Which step was skipped or poorly executed? Most failed demos fall into two categories: they skipped step two (showed output without showing the approach) or they skipped step four (hid the failures). Which pattern describes the demo you are thinking of?