Don’t Ask the Client for the Answer

November 21st, 2011 by Mike Wilcox

When reading the title of this article you may immediately think that it seems obvious. You’re the commissioned expert, why would you be asking the client how to do your job? That’s precisely the point; I’m giving you the answer and not the problem. When given a solution the natural tendency is to take the easy way and simply… implement it. But what is the problem you’re addressing? And is that the right solution? Will it work? How would you even know? So maybe, it’s not so obvious. In fact I would argue that being provided the solution is much more common than being told the problem.
Bailing Water

Understanding this dynamic helps build better communication with the client. If the client asks that the button be moved to the left, and you respond it’s better on the right, you may insult them and their process. Their process may have been:

  • Recommendations from usability studies.
  • Consulting with expert button location professionals
  • Several all night meetings among team members who sweated over the button location

It’s likely none of these, and was probably that the client thought about it in his car on the way to work. But either way, the client had a process which incidentally left you out. How do you resolve this? Ask questions.

When presented with only a solution it becomes a riddle. This may put you in the position of having to reverse engineer their decision to get to the problem. Why do you want the button there? Is it because users aren’t clicking on it? Did a customer complain? Is it because your daughter is left handed?

For the most part, moving a button is easy and is probably the best solution to make the client happy. But what if it’s a complex solution like asking you to increase the buffer time on the video player? If I don’t ask questions, it may go down like this:

I spend a few hours increasing the buffer time from 2 seconds to 5 seconds (this took a long time because it auto-buffered before and there was no code to have a custom setting). The changes are tested and pushed to production. The client now asks for a 10 second buffer. The changes are pushed. The client then says this isn’t working, now customers are complaining that the video takes to long to load, and the buffer time isn’t even helping… on mobile phones. You reply, “Oh, well this code doesn’t affect mobile phones.” The customer replies “Oh, well, I need the videos to load faster on mobile phones.”

Getting the problem at the end of the process is obviously unproductive. All those changes were made was a waste of time and money, and it turns out they hurt the product while the real problem wasn’t addressed — which in this case may not have something completely different, like a video encoding problem.

Unfortunately we developers are often not the ones interfacing with the client. When a project manager tells me he needs a change, I get real frustrated when he can’t answer my questions. “But the client made the request, so I didn’t question it.” The truth is: we are not in the business of doing as we are told. We are in the business of making the client successful. Which may at times even be in spite of the client’s wishes. I’m not saying to be defiant, because sometimes the client may need to go through a learning process himself. Just make sure you have your change order prepared.

The Rookie Dilemma

What do you do if you are so low on the developer food chain that you simply are not allowed in the process and have to just do what you are told? Same thing — ask questions. If you’re not asking questions you’re not learning. But note there is a fine line between asking questions and questioning authority. “Moving the button to the left destroys the flow of the page — it looks stupid there!” is more professionally phrased as “Okay, although that would upset the flow of the page. Just so I know, why are we moving it?” If your questions are intelligent enough, you may trigger a new discussion with the client — and you may even be invited to the party. We’ve all started low on the totem pole at one or multiple times in our career. Asking good questions is just one way of making the climb.

Conclusion

Don’t give the client what they ask for — give them what they need. I’m not going Zen on you. It’s a simple matter that most of the time they don’t really know what they need, so they ask for the wrong thing. The most successful man I ever worked for once said “It’s easy to make the smart clients look smart. But the real money is in making stupid clients look smart.”

Be Sociable, Share!

Comments are closed.