Welcome to my Social Blog
About 5 years ago, I had a major disagreement with a pillar customer, a local office of a MNC.
I wanted them to move to the cloud. They refused and couldn't be more precise why other than claiming, "Security".
I was at their office, pointing at a building outside their windows and said,
"Bank {X} has moved their servers to the cloud. And they are more regulated than your industry. What security concerns do you have that's more stringent than a bank?"
They couldn't answer then. This year, they have changed their mind.
Why?
My customers have recently seen their counterparts in other country offices move to the cloud, so they are more comfortable now.
The existing on-prem servers we had (yes, they won that argument from 5 years ago) have started to break down.
Seems a waste of time on hindsight, right?
Ideal Customer Doesn't Exist 99% of the Time
The simple lesson I draw is this:
If my customers are super savvy, they wouldn't hire me. So they should be somewhat "dumb".
By "dumb", I mean unsavvy or ignorant. Not stupid.
Like we are all "dumb" to our doctors when we are sick because they are the medical experts, not us.
But, sometimes that ignorance can be counterproductive.
Which is why the ideal customer should be so "dumb" they need you, but not that "dumb" to block you from doing your job well.
Sadly, most of your real-life customers will NOT be in this category.
Reject Customers Whose Ignorance Blocks Your Effectiveness. Not Efficiency
How much "dumbness" or ignorance should you accept from your customers since they are seldom perfect?
Of course, you would still recommend the most effective and efficient course of action because you want to help them save costs.
But when they resist, allow them their way even if the results means a drop in efficiency but not effectiveness. As long as you can still do an effective job for them, so be it.
Only when you're blocked from doing an effective job altogether, do you reject such prospects.
In my example, I had to find workarounds and use some hybrid cloud/on-prem solution. Every time I deploy changes, it was painful for me.
But, I could still be effective and they were (and still are) happy!
What If It Impacts Your Cost Structure?
There will be cases where it's more costly for you to deliver an effective service while accommodating the "dumb" constraints.
What you should do is implement a "dumb" tax.
Say, "I charge ${X} usually. But, if you insist on this constraint, I can still do it at ${X + Y} instead".
${Y} is that "dumb" tax.
Most times, they are happy to pay. If not, you now can walk away.
In conclusion,
NEVER drop your standards in effectiveness
ALLOW drops in efficiency due to customer requests
but ALWAYS charge them a "dumb" tax for it
My gratitude to @ModusEffectivus @PigballerinaYan for reading drafts of this