How to Respond to “You're Missing a Feature We Need”: 3 Honest Answers
“You're missing a feature we need.”
The buyer found a gap in your product. Three ways to learn how much it really matters, offer a workaround, and avoid promising work you won't deliver.
Practice this objectionWhy buyers say it
Sometimes the feature really is needed and it's a genuine blocker. Far more often it's a line on a list: the buyer has their old tool, or a competitor, in their head, and compares features one by one instead of asking what they need to get their work done. People who build products tend to handle this objection badly in two opposite ways: promising to add it right away and then not doing it, or defending the choice not to have it in an engineer's tone. The buyer wants neither. They want to know whether they can do their job without it, and whether you're someone who tells the truth about the roadmap.
What it often means
- A feature-by-feature comparison with a competitor
- An old workflow they don't want to change
- A request from a coworker they need to be able to satisfy
Three answers that work
You're right, that's not there. Can you help me understand how you'd use it, in practice? How many times a week, and what happens if it's missing. Sometimes there's another way to get it done, sometimes it's a real blocker, and I want to know which case we're in.
Why it works: You admit the gap without hedging and shift the conversation from the feature to the need. Asking about frequency and consequence separates a habit from a necessity, and does it without second-guessing the buyer.
Today that gets done like this: [concrete workaround inside the product or with another tool]. It's not as clean as having it built in, I know. Want me to show you how [a similar customer] handles it, so you can judge whether that's acceptable for you?
Why it works: You offer a workable path now instead of a promise for later. Saying plainly that it's not perfect makes you credible, and showing how someone else does it turns an idea into something concrete to evaluate.
I'll tell you the truth about the roadmap: that feature [is planned for a time frame, or isn't on the list]. I'm not going to promise a date to get you to sign. If it's essential for you today, we might not be the right tool right now, and I'd rather be the one to say so.
Why it works: Roadmap transparency is rare and worth more than a feature. The buyer understands that what you say about everything else is true too, and if they go ahead, they do it without false expectations.
Avoid this one
No problem, we'll add it for you, we'll build it in the next few weeks.
Why not: A promise made during the sale and paid for afterward. If it doesn't ship on time, you lose the customer and their trust. If it does, you've let one customer set the roadmap for everyone. Features get promised when they're already being built, not to close a deal.
Example dialogue
BuyerThe course platform is great, but it doesn't do invoicing. We send a lot of invoices every month.
YouTrue, invoicing isn't built in. How do you handle it today? Do you do the invoices or does your accountant?
BuyerI do them in a separate program, then send them to the accountant.
YouThen you can keep doing that: the platform exports the list of enrolled students with amounts and dates to a file, and you import it into your invoicing program. It's not one click, but you don't retype anything. Want me to show you the export?
BuyerIf I don't have to retype amounts by hand, that works. Show me.
YouHere it is. And on built-in invoicing, the honest answer is [it's not planned for the coming months], so don't factor it into your decision.
Practice this objection
A simulated buyer says it to you out loud (or in writing), you answer, and you get a score plus the model answer. Free, no account, 2 minutes.
FAQ
How do I tell whether the missing feature is a real blocker or just a habit?
Ask how often they'd use it, who uses it, and what happens without it. If the answer is “every day, and we can't work without it,” it's a blocker. If it's “now and then” or “the old tool had it,” it's a habit, and a reasonable workaround is usually enough. Don't decide for the buyer: let them tell you how much it weighs.
Should I build the feature if several customers ask for it?
If many ask, for the same reason and with the same urgency, probably yes. Track every request with its context, not just the feature name. One request from a single customer, however big, is a signal, not a decision. And if you do build it, tell the people who asked: it's the best way to reopen a lost deal.
Can I say “it's coming” if it really is on the roadmap?
Yes, but without promising a date you don't control and without making it the reason to sign. Say what you're working on, what stage it's at, and that the decision should rest on what exists today. If it ships early, the buyer is happy; if it slips, they don't feel betrayed. Trust is built on cautious forecasts.