As someone on the implementation side I have a sour taste for Sales and Sales Engineers. Always selling features we do not have or things we cannot do. Then they mock it up and leave and I have to break the news to the customer.
I'm also on the implementation side (sometimes referred to as professional services), and two immediate thoughts jump to mind:
1) Unless you're a practice manager directly responsible for maintaining a targeted book-to-bill ratio or other quota metric (which usually entails account and long-term customer relationship management), your management should not be throwing you under the bus and exposing you to break that news to the customer. Nothing destroys a booking pipeline faster than customers with mismanaged expectations.
2) This type of behaviour from Sales teams is usually indicative of misaligned incentives. A concrete example of this type of situation could be company in an early "hyper-growth" phase where they only comp on new bookings, and don't comp Sales on contract renewals.
(It's often the same middle management that omits to let the dev team know the system is supposed to work on IE8 until the client complains.)
Sales commmonly direct their sour taste towards the developers...
* Business function: If you're customer facing, most [project|practice|field|support]managers should be sticking their nose into day-to-day projects, especially when a bad message needs to be delivered (e.g. the product we sold you will fall short of your expectations). This is not only because the customer will be incensed, but because there may also be commercial repercussions (e.g. SLA penalties) that you may not be aware of in umbrella master [service|support|license] agreements.
* Deal/budget size: Typically, the larger a manager's deal or budget, the more headcount they have. And the more headcount on a project|team|division, the more intermediate managers there will be to layer the manager in question. Hence, if the deal size is rather large, in most cases managers will not get involved on a day-to-day basis, but should be available for escalations (presuming an account management role for larger deal sizes). If the deal size is usually smaller, more than likely the manager will be more involved (e.g. as a project manager).
* Org size: BDC - not usually. Startup - usually yes.
Also, some (most) places do not have very good lines of communication between sales and R&D, while others do. I'm lucky to be in a place where I can submit a PR on Github if I need something yesterday, or can file feature requests / fixes that will get looked at within the week.
My view is generally that the relationship with a customer is where you make most of your money over 5+ years, selling them an opportunity once by promising the moon and delivering a paper plate is in no one's interest. Lots of sales people act that way but that's not going generally going to be your leaders.
Sales Engineers in particular don't want to sell something dishonestly - it opens the company up to risk and it hurts their credibility, particularly if you sell multiple products.
There are a few reasons I can think of:
1. The technical people that run the current implementation didn't put their requirements into the sales process.
2. Some of those features really don't matter to the business and were fodder.
3. The requirements were listed, but not accurately or with enough depth.
4. The Sales team didn't have enough knowledge (or training) to know the difference - or inaccurate documentation.
5. It was roadmapped close enough to implementation and including delays to go ahead anyway.
6. The competitor claims to have this feature but theirs is broken also, so it's a race to who can sell broken stuff faster - because nobody can truly do it.
The people and the companies that support this exist certainly - just not for very long.
Oh, hey VMware! What's up?