Example of saying “yes, but” to customers…

Per some recent comments and posts (here and here) on discussing responsiveness to customers, Henning Kagermann related a story on a call that I had completely forgotten about.  I’m certain that it has been told publicly before, but I’ve disguised it a bit just in case…

In the early 1990’s, SAP was approached by a delegation of firms w/r/t industry-specific improvements to R/2.  They had a list of demands that they wanted to see implemented in R/2.  Fair enough.  That industry was perhaps the core of SAP’s success to that time, so why not do it?  Except that SAP was in the midst of developing its next generation product, R/3.  We also wanted to expand our footprint to other industries and markets.  There was no way we could do R/3 and satisfy much of that list of demands in the current product.

If you know anything about the history and success of SAP, you can guess the answer.  We chose to spend the preponderance of our efforts on R/3.  While some of the key demands were satisfied, most were deferred in favor of ensuring that R/3 got to market.

This example illustrates the challenge well.  Most of the time you should listen to your customers so you can satisfy and delight them.  But listening for too well for too long can mean that you wake up one day and find that you’ve become a no-growth “legacy” business.  Sometimes you need to say “yes, but.”

More on saying “no” to customers, stakeholders, etc.

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.

Continue reading

Saying “No” the right way

A colleague of mine, Schalk Klee, has a couple of posts of interest (Schalk’s blog is here).  I had forgotten to link to his original post on saying “No” as a PM (here), so his follow up post on when and how to say “No” (here) was an appreciated reminder.  Schalk highlights the balance that must be struck:

We all know that good scope management and customer focus are both critical success factors for value adding projects and in a professional service environment there is always the sales focus as well.  How do I balance this?

This is where I believe the art of making a deal comes into play.  This is a skill that a “good” project manager has to develop.  How do I give my client what they want without putting myself into a worse position?  Creative thinking, negotiation tactics and customer focus all need to be combined. 

Deal-making and negotiation skills are not emphasized enough in most PM career paths; frankly, I could stand brushing up on them myself!

%d bloggers like this: