Mis-reading an advice from 37signals

I am reading this post published on 37signal blog. And I start wondering how different it may be read inside a company. Ask a developer and a marketting/sales to read it. The message will be completely screwed. On both sides. And I am trying to figure it out why...
The next paragraph will sound pretty much as the originating question: in all the companies I have worked on, I've seen requests for product roadmaps and product roadmaps everywhere (even in the client offices). Even before having the opportunity to take a look at the domain the project was targetting. And in a way I've explained this to myself: the management, marketting, sales cannot sit around, doing nothing till the project is out. They have work to do as the developer has. I haven't been involved in the marketting or sales field, but I can imagine that there is lot of work to be done by the time the product is launched. And they need to plan ahead, to have something to base their decissions on. And all this is not meant to put pressure on the development; is just for being able to deal with the clients and bring money to the company.
But there it can be a problem. The moment they start making promises to the clients, and making these promises become a pressure for the developers. At this moment, it looks like the 2 departments are not part of the same company. It looks like at this moment, these departments are in competition and are trying to place the ball in the others yard. Both team are forgetting that they must follow the same goal: success. Success means satisfying the client. And satisfying a client does not mean only to deliver in time. It means also to deliver the quality and experience they expect.
Some of the projects I have worked on required me to develop a relation with the client. While doing this I have always tried to let the client know that: a fixed delivery date expressed in the form: "you will have this done in 68.27 days from now on" will never work (not that it is somebody's fault) and if we collaborate during the process and he is aware of where we are at each point than we can deliver a system that will have better chances to meet their expectations. And the good news about this approach was that all the clients I have worked with have agreed. I am probably part of the few developers that can say that they never worked inside a failing project; indeed in terms of "68.27 days delivery" we have failed a few times, but we never failed the client.
Moving on the developer side, the story can be seen from a completely new perspective. A developer usually hates deadlines. Why? Because dealines are limitting his possibilities, are making him become pragmatic (most of the time) and even worse, may require him to do compromises. He sometimes forgets that the system is not designed/build for himself, but for a client that might know better what he wants. A developer likes to play and try. This is definitely not bad... as long as you know that you follow your goal. And the goal is to meet client expectations... and client expectations do not mean the coolest technology, but rather the functionality, quality and "right moment".
Indeed, there is no silver bullet for delivering successful projects. But the whole experience during the project can change. The client may become more satisfied by having a better product, the sales/marketting/developer may work more relaxed. In fact in all this project deal, the client and the company are a team. They need to work together to deliver success.