I, too, have experienced the problem of the business overpromising. I see it as baked into system: we seek perpetual growth, which we assume comes from perpetually-rising profit, which we assume comes from more sales, which we assume comes from more features. I don't believe in this worldview, but neither do I benefit much from pretending that my employer's sales force doesn't believe in it. If they do, then I find myself in the situation I describe in this article.
This worldview necessarily eventually makes the feature delivery system a bottleneck. If it didn't, then we would never have had books like _The Goal_. That sets the scene for my words here: in this situation, the business people and technical people think that they want different things, but they have a strong common goal: reducing the volatility in the cost of adding features, which we believe will help us get off the merry-go-round of overpromising and underdelivering. We do run the risk, however, of a new imbalance: maybe the business uses overpromising as a business model. (I guess that you mean this in particular.) This means that the business has made peace with burning out the feature delivery system and everyone who works in it. If you find yourself there, then I hope you can get out. I teach people how to do that.
I hope that once the business people and the technical people see this unexpected alignment, that they'll have better conversations about when to release features, and so on. Maybe we *can* release a feature before the programmers put their stamp of approval on it, as long as our customers understand the risk. The programmers can help the sales force understand the risk, and even work directly with the customer to find ways to mitigate the risk. I don't want programmers to become the bottleneck to releasing features! I'd like to avoid building up an inventory of features for which customers would gladly now pay money! (On average; we can think of exceptions to this rule, but I hope you get what I mean.)
I wouldn't call having a road map "the key". I see it as a tool to agree on what to expect, but like any plan, if we believe in it too strongly, then we end up building features after we've long forgot why we need to build them. I agree that we need a common understanding of where we want to go, and a road map can help with that, as long as we don't turn it into a five-year line-item-level plan. (It happens.)
This leads to a much more complicated discussion, and I don't think I can address it adequately in a comment text field. :)