How to Handle a Missing Feature During a Technical Evaluation

Every sales engineer eventually meets the question in its most uncomfortable form. The evaluation is going well, the buyer's architect has been quiet for most of the session, and then they ask whether the product supports something it does not. Everyone in the room turns to the SE, including the account executive, who is hoping for a yes. The answer given in the next thirty seconds will not decide the deal on its own, but it will shape how the architect interprets everything you say for the rest of the evaluation.

There are two instinctive reactions, and both are unhelpful. The first is to find a way to say yes: a vague reference to the API, a hint that professional services could build it, or a suggestion that it is coming soon. The second is to concede too much, apologising for the gap so thoroughly that a minor limitation starts to sound like a fundamental flaw. The better path sits between them, and it starts with understanding what the buyer actually asked for.

Clarify the Requirement Before You Answer It

Many missing features are really a particular implementation of an underlying need. A buyer asking whether the product supports a specific provisioning protocol may actually need departing employees to lose access automatically. A request for a CSV export may really be about feeding numbers into a finance reporting process that runs every month. Buyers describe the solution they have seen before, and your product may meet the need differently.

Asking a clarifying question is therefore not a stalling tactic, provided it is genuine. Questions like these usually open the conversation up without sounding evasive:

• "Can you tell me a bit about what you would use that for?"
• "Is that something you need today, or something you expect to need as you scale?"
• "How are you handling that with your current tooling?"
• "Is that a hard requirement from your security or compliance team, or more of a preference?"

The answers tell you how much the gap matters and whether any of the options below are realistic. They also show the architect that you are trying to understand their environment rather than defend your product. One caution applies. If the buyer confirms that they need exactly what they asked for, stop exploring alternatives. Continuing to reframe a requirement the customer has clearly stated is where clarification turns into evasion, and technical buyers notice the moment it happens.

Reframe the Requirement When the Underlying Need Is Met

When the clarifying questions reveal that the product does meet the need, just not in the way the buyer described, the right move is to show them. Something like: "We don't support that protocol directly, but if the goal is making sure access is removed when someone leaves, here is how customers handle that with our directory integration." Then demonstrate it if you can, because a working example carries far more weight than a description.

Reframing only works when it is honest about the difference. If your approach needs an extra step, has a delay the buyer's method would not, or relies on a component they do not currently run, say so. The architect is comparing your answer against the solution they had in mind, and they will find the gaps whether or not you mention them. Pointing them out yourself makes the reframe credible rather than slippery.

Offer a Workaround Only If It Is Supported

Sometimes the product cannot meet the need natively but can be made to meet it with some additional work: a script against the API, a webhook into another system, or a configuration pattern that is not part of the standard product. These can be perfectly legitimate answers. They can also create problems that surface long after the evaluation, particularly when the workaround exists mainly in the SE's head.

A useful test is whether the workaround would survive without you. Is it documented? Would your support team help a customer who ran into trouble with it? Will it keep working after the next product release? Who in the customer's organisation would maintain it? If the honest answers are no, no, probably, and nobody, the workaround is a liability rather than a solution, however elegant it looked in the demo.

When a workaround is supported, present it with its real cost. Explain what has to be built, who typically builds it, and what ongoing effort it involves. What damages trust is discovering during implementation that the "simple API call" mentioned in the evaluation turned into a small development project.

Bring In Product Management When the Gap Is Strategic

Some gaps deserve more than a response from the SE. If the missing capability is central to the buyer's decision, or if the same request keeps appearing across deals, it is worth involving product management. Doing so gives the buyer a clearer view of where the product is heading and gives the product team direct exposure to a requirement they may be underestimating. Brief the product manager beforehand on the specific requirement, the use case, and why it matters to the decision. Without that preparation, these calls tend to drift into a general roadmap presentation that does not address what the buyer asked.

Roadmap discussions need particular care. Architects have heard "it's on the roadmap" many times, and they have learned to treat it as a polite way of saying no. Be precise about the difference between something that is committed with a date, something that is planned but not scheduled, and something that has simply been discussed. If a customer is going to rely on a future capability, that dependency should be visible to everyone, including your own leadership, rather than implied in a meeting and forgotten afterwards.

Admit the Gap and Let the Buyer Judge Its Weight

Often the best answer is the simplest one: the product does not do that, and there is no workaround worth recommending. Saying so plainly, without excessive apology, is usually received better than SEs expect. Something like: "No, we don't support that today. Customers with a similar requirement tend to handle it in their data warehouse instead. How central is it to what you're trying to achieve?"

That final question matters. It hands the judgement back to the buyer, who is better placed than you to decide how much the gap weighs against everything else in the evaluation. Most technical evaluations involve gaps on every side, and experienced buyers are rarely looking for a product with none. They are looking for the product whose gaps they can live with, from a vendor whose answers they can trust. A clear no on a secondary requirement can do more for your position on the primary requirements than any amount of hedging.

If the gap turns out to be decisive, it is better to learn that now than after a lengthy proof of concept. At that point the conversation moves into the territory of whether the product is the right fit at all, which is a harder discussion but a more useful one for both sides.

When You Do Not Know the Answer

Sometimes the honest answer is that you are not sure. The product may support the capability in a configuration you have not used, or the answer may depend on details of the buyer's environment. In that case, say that you will confirm and give a specific time: "I'm not certain how that behaves with your identity provider. Let me check with our engineering team and come back to you by Thursday." Then do exactly that.

Follow up in writing. A short note that restates the requirement, gives the answer, and describes any options gives the architect something they can share internally and shows that the question was taken seriously. It also prevents the answer from being remembered more optimistically than you gave it.

What to Avoid Saying

A few responses reliably damage credibility with technical buyers. "We can do that" should never mean "we could build that", because the architect will eventually find out which one you meant. "Nobody has ever asked for that before" may be true, but it suggests the requirement is unusual rather than engaging with why the customer needs it. "That's coming soon" without a committed date sets an expectation you do not control. And any question that implies the buyer should not want what they asked for tends to go badly unless you have already earned the right to challenge their approach.

Conclusion

Handling a missing feature well comes down to a sequence rather than a script. Clarify what the buyer actually needs, reframe only when your product genuinely meets that need, offer workarounds only when they are supported, involve product management when the gap is strategic, and otherwise state the limitation plainly and let the buyer decide how much it matters. None of these options require you to pretend the product is something it is not.

The architect watching you answer is evaluating more than the feature. They are deciding whether your answers can be relied on when they matter, and a well-handled gap is one of the clearest opportunities you will get to show that they can.