Pawel Brodzinski had a good comment (here) on my post about saying “no” the right way (here), which links to his post laying out his full perspective on the customer is always right principle. I replied to his comment — agreeing with the principle, but cautioning on its application — which I’ve posted below:
Sometimes it is about saying no — or as the Japanese say “Yes, but.” There are times when we don’t take business, especially when we are being “forced” to do so. But if we aren’t taking their money, is that customer really a customer? IMO, no, at least not for that topic.
Of course, I agree that the customer is always right — which makes it critical to be choosy about one’s customers. But the application of that principle is tricky. PMs who allow scope creep to happen on their projects often justify it with a customer service rationale — “the users asked us to build it.” But are the users really the customer of the project? Aren’t the executives who chartered the project and the company they represent the customer? Too many IT staff and PMs are very confused about who is the “real” customer.
Back to your example [from Pawel’s comment]: when presented with such an opportunity or change request, we can certainly say “yes we can build functionality X.” But there is almost always a trade off that needs to highlighted, at least in the typical enterprise project or program The release will have to be pushed, or the functionality will need to be delivered in a future release, or we’ll need more resources, or we’ll have to assume more risk, or there’s a platform dependency, etc.
In other words, there are choices that the customer — the economic buyer in our terms — needs to make based on his/her strategy and where this project/program fits in. I believe that PMs need to be able to illuminate and influence these choices so you can get to “win/win” where ever possible.