How do you convince a client that he is wrong? That was the question that I got from someone in the audience the last time I spoke at a conference.
My first thought was: Ah, an age-old question.
If you work in the service industry and thus have to deal with clients or customers, this question has no doubt crossed your mind. I’ve personally been in dozens of situations where what the client was asking didn’t really make any sense.
And sometimes it’s not even the person that I’m directly speaking to. For example, a few weeks ago, I was told “…actually, this histogram HAS to be here because my boss says he wants it there.” Well then, there isn’t much we can do about that, is there?
One of the posters that is hanging in our office is this one from The Oatmeal:
Of course, this poster has taken it to the extreme. However, these types of situations happen from time to time and learning how to deal with them is a critical component of client relations.
So, how do you convince a client that he is wrong? Before you can do that, there are two things you need to consider.
1. Wrong about what?
Simply saying that the client is wrong is, well, wrong.
Every time the client asks you for something, they are actually giving you a requirement that consists of at least three components. He might be wrong about one or two of those, but most likely not all three. And that’s the important part.
As you may already know, a key step in software design and development is creating user stories. Every user story has four components: title, persona, action, and benefit. For now, let’s leave the title out of the discussion (as we are not discussing user stories literally), and so we’re left with three components.
An example of a user story is: as a project manager, I want to see how much time is spent on each task so that I’ll know what is slowing us down.
This is a very clear, well-formatted user story. It represents a requirement for a developer or a designer.
A similar requirement can be stated as: as a project manager, I want each team member to write down for me how much time is spent on each task so that I’ll know what is slowing us down.
The end goal is the same, but the way we get there is now quite different. And this time, it doesn’t seem to make a whole lot of sense because team members will waste a lot of time reporting like this, instead of making the process automated.
If you heard the latter requirement, you might think “This is wrong, we shouldn’t do it like that. I have to convince this client that they are wrong!”
So the first step is realizing what exactly he is wrong about – and in this case it was: how to achieve the goal. There’s nothing wrong with the goal itself, nor with the persona in question (the project manager really needs this). Based on my experience, it is usually the how part that the client is wrong about.
2. Trust
The second thing to consider is trust.
When the client asks you to do something, at that moment he doesn’t believe he is wrong. If he knew what he was asking were wrong, he would have asked you something else instead, something he believed was right. If you want to convince him to change his mind, he has to trust you.
The most important thing for a client at this moment is actually the end goal. He is suggesting to you how to get there, believing it’s the best way. So if you want to tweak the route, you need to make sure the final destination will remain the same.
Spend some time making sure he knows that you understand what he really wants. Explain in your own words how you see the goal, what the benefit will be if it is achieved, how we will know it is achieved, etc. Understand the goal and make sure the client sees that.
Next, don’t just discard his how. Instead, show a simulation of what would happen if we did take this route. Explain how this approach does get him closer to what he wants but also point out the weaknesses of this approach. (I’m assuming there are some weaknesses, otherwise the client wouldn’t be wrong).
Remember, no one likes to be wrong about something, but if there are downsides to the plan, make sure they don’t remain hidden.
This is now where your suggestion comes in, as you explain that you know how to solve those downsides. Tell the client your solution. After all, that is your field of expertise. He is an expert in his business (and as such merited to suggest the goals), but you are an expert in your field: designing the tools to achieve those goals.
Explain how your solution would still get him where he wants to be in the end, but also it would have far less serious downsides along the way. If you faced this situation before, so you already have some valuable experience, point that out as well (but be sure to keep in mind there might be an NDA restricting you from discussing details of that past project).
If the client trusts what you are saying, he will see there’s nothing to lose, and even more so, there are things to gain. It’s now more likely that he will tell you to do it the way you’re suggesting it. And the best part is, you never had to explicitly tell him that he was wrong.
Conclusion
Many of us have asked ourselves How do I convince a client he is wrong? And yet, this question itself is wrong. It’s too simplistic; it doesn’t allow you to see that what the client is saying has many layers.
Once you realize that, you don’t have to convince the clients they are wrong. You just have to convince them you are right. Take what’s good in their requirement and build on that. If they trust you, they will let you do it your way.
Featured image was taken from The Oatmeal poster included above
