Mid-demo, the prospect asks whether the product does something it does not. What do you say?

The reflex that costs the deal

The instinct under pressure is to soften. "Yes, with some configuration." "That is achievable." "We can absolutely support that." Each of those is heard as a yes and written down as a yes, and the person writing it down is frequently the one drafting the requirements matrix that becomes an appendix to the contract. Nothing you say in a demo stays a demo answer. It propagates into the evaluation scorecard, into the statement of work, and eventually into an implementation team's backlog, where the gap between "achievable" and "exists" is discovered by somebody who was not in the room and cannot renegotiate.

The commercial cost of a plain no is almost always smaller than presales people expect, and the cost of a soft yes is almost always larger. A no loses a feature. A discovered soft yes loses trust across every other claim you made, including the true ones, and in a competitive evaluation that is the thing you cannot recover.

Ask what the feature is for

A feature request in a demo is a proxy for something, and the something is what you need. Three questions do most of the work: what would they be doing with it, what happens today without it, and where the requirement came from. The answers separate cases that look identical when phrased as a feature.

Sometimes the requirement is real and the stated feature is one way to meet it, in which case your product may meet it differently and you have simply been asked the wrong question. Sometimes the requirement arrived as a line copied from the incumbent's datasheet or a competitor's RFP template, which means nobody in the room has a use for it and the honest answer costs nothing. Sometimes it is genuinely load-bearing and you have just learned that you may not be a fit, which is information worth having in week two rather than week ten. And sometimes the person asking is not the person who needs it, so the answer they carry back matters more than the answer you give.

Asking these questions is also the move that reads as senior. A sales engineer who answers the feature is a product encyclopaedia. One who asks what it is for is being trusted with the problem.

Three answers, and what each commits you to

What you say	What it commits	What you owe afterwards
"It does not do that today."	Nothing beyond accuracy	The reason it has not blocked other customers, if that is true
"Not natively. Here is how customers meet that requirement instead."	A path you can describe and cost	Confirmation from delivery that the path is real, in writing
"Yes — let me show you."	The demo you are about to give	Nothing, provided you actually show it

The second row is where most real answers sit, and it is also where the discipline is hardest. A workaround is only an answer if you can say who builds it, roughly what it takes, and whether anybody is running it in production. A workaround you have invented on the spot is a soft yes wearing different clothes.

The roadmap is not yours to commit

"It is on the roadmap" is the second reflex, and it carries a specific hazard: dates. A date you did not set is a date you cannot honour, and a customer who buys on a Q3 commitment and does not get it in Q3 becomes a renewal problem and sometimes a legal one. Most vendors have an internal rule about forward-looking statements for exactly this reason, and the rule exists because somebody broke it expensively.

What you can do is separate the two things the customer wants. They want to know whether the gap will close, and they want a mechanism if it does not. Say honestly whether it is on the roadmap without attaching a quarter, offer to get them in front of the product manager who can speak to sequencing, and — where the gap is genuinely decision-critical — route it to whoever in your organisation is authorised to make a written commitment. That is a real escalation path, not a deflection, and customers can tell the difference.

What happens to a gap nobody writes down

Here is the failure that recurs across deals and never appears in demo training. The gap is handled well in the room, everyone moves on, and it is never recorded anywhere. It does not reach the product team, so it never influences prioritisation and the next three deals hit it too. It does not reach the proposal, so the statement of work is silent and the customer's expectation stands unchallenged. And it does not reach the implementation team, who discover during onboarding that a capability the customer believes they bought was discussed and finessed nine months earlier by somebody who has since changed accounts.

So the answer to this question does not end when the demo does. Log the gap with the requirement behind it, not just the feature name, because the requirement is what product can act on. Make sure anything you positioned as a workaround appears in the proposal in the words you used out loud. If you promised to come back with an answer, come back with it inside the timeframe you named, including when the answer is still no — a returned no lands better than silence, and it is the cheapest credibility available in a competitive deal.

Do not lose the room to the tangent

One last mechanical point. A feature question arrives in the middle of a narrative you built for a reason, and the common error is to chase it, open four other screens, and never get back. Answer briefly, park the detail explicitly with a commitment to return to it, and pick the thread back up. "Short answer, no, and there is a way customers handle it that I would rather show you properly at the end than rush now — can I finish this flow first?" keeps both the honesty and the demo.

Anything you say in a demo becomes a requirement somebody else has to satisfy. Say no early, find out what the request was for, and write the gap down where product and the proposal will both see it.