A prospect asks for a capability your product genuinely does not have. How do you respond?

Answer the question first

The instinct is to soften, redirect, or bury the answer in qualification. Do not. Technical buyers are usually evaluating several vendors and have already heard evasion, so a clear "no, not today" spends a small amount of capital and buys a large amount of credibility. The candidate who deflects reads as either uninformed about their own product or willing to mislead, and both are worse than the gap itself.

Say it plainly and immediately, then keep going: "No — we do not support that today. Let me ask you about the requirement behind it, because there may be a path."

Then find the outcome behind the request

Prospects ask for features but need outcomes, and the gap between the two is where most of these situations resolve. A request for a specific capability is often a description of how their current tool happens to solve a problem, not a description of the problem.

So probe: what are you trying to accomplish with it, what happens today without it, who uses it and how often, and is this a hard requirement or a preference. Two useful discoveries come out of this regularly. Sometimes the underlying need is met a different way in your product, and once you understand the outcome you can demonstrate that rather than argue about the feature. Other times the requirement turns out to be inherited from a legacy process nobody has revisited, and the prospect themselves concludes it is not essential.

Be careful not to make this feel like avoidance. Because you already answered the question honestly, the probing reads as problem-solving. If you had probed instead of answering, it would read as a dodge.

Offer the nearest credible path

Rank your options by how much you can actually stand behind:

It is solvable in-product today, differently. The strongest outcome. Demonstrate it rather than describing it, and be honest about where it is clunkier than what they asked for.

It is solvable with integration or configuration. Name the specific mechanism — an API, a webhook, an export — and be explicit about who builds and maintains it, because an unowned integration is a renewal risk you are creating for yourself.

A partner or a services engagement covers it. Viable, but say what it costs and who is accountable.

It is on the roadmap. Only say this if it is genuinely committed and you are permitted to share it, and even then attach the caveat that roadmaps move. Never quote a date you did not get from the person who owns the release.

It is not on the roadmap. Say so. "This is not something we plan to build" is a legitimate answer, and pairing it with a clear statement of what you are investing in often reframes the whole evaluation usefully.

The trap: implied commitments

This is what the question is really testing. The failure mode is not saying "yes we will build it" — most people know not to do that. It is the softer version: "that is definitely something we are looking at," "I would expect that in the next few releases," "let me see what I can do." The prospect hears a commitment, it goes into their internal business case, and the reckoning arrives at implementation or renewal when it does not exist. You will not be in the room for that conversation, but your company will.

Two habits protect against it. Use the phrase "not available today, and I will confirm in writing what is and is not planned," which resets expectations without closing the door. And follow up in writing yourself, the same day, restating the gap and the agreed path — the written record is what stops a verbal maybe from becoming a remembered promise.

If your own sales lead starts implying a commitment in the room, do not contradict them in front of the prospect. Let it pass, then correct it in the written follow-up, which you are sending anyway, and raise it with them directly afterwards. Interviewers for presales roles are specifically listening for whether you can manage that tension without either misleading the customer or undermining your colleague.

When the competitor has it

Concede the specific point and move the frame to the whole evaluation: "Yes, they do have that. Here is how we would handle that requirement, and here is where I would expect us to be stronger for your use case." Never disparage the competitor's implementation unless you know it concretely, because a technical buyer who has seen the demo will catch you and you will lose the room.

When to walk

Sometimes the honest answer is that this is not a fit. If the missing capability is central to their core workflow, has no viable path, and is a stated hard requirement, saying so early is better business than a long evaluation you lose at the end or, worse, a sale that becomes a failed implementation and a reference you cannot use. Candidates who volunteer qualifying out as an option — with a clear statement of the criteria for it — stand out, because it demonstrates commercial judgement rather than just technical answers.