But I can tell you something: a story about how I started to listen to the client. Don't get me wrong; I've been working with clients for a long time. But they have been of the same breed as I am - primarily software engineers. Communication is easy when you share a common language. But when you don't, you notice you have problem, but you may not realize that it is due to communication.
These clients of mine were engineers as well, but their domain knowledge was different from mine. They were truly specialists in their field, and understanding even a small fraction of their business had been challenging. A common course of action for software consultancies is to simplify the solution: you try to convince the client that the problem is due to their current software solution being too complex for the task at hand. They should have fewer views, simplified interfaces, better interactions, and so on. I tried that. It turned out that the actual system behind the UI was so complex that the features in the current solution were just about optimal. It was a tried and tested feature set, even though it seemed overly complex.
Lesson learned, no. 1: You really have to understand the client domain before you can propose a solution for a problem.
The source of Pekka's inspiration might come from here:
"Look man, you can listen to Jimi but you can't hear him. There's a difference man. Just because you're listening to him doesn't mean you're hearing him."
- Sidney Deane, White Men Can't Jump
Then I had a feeling that they were not telling me everything. Even though I was the web dude, why did not they tell me more about backend? And why they did not tell me about those important details in the very beginning? And why were they asking about these same web thingies over and over again; I had already told them about those...Eventually it turned out to be a matter of domains as well. As our domain knowledges were different, we did not know which things the other party would have needed to hear about.
The only way to overcome this is to ask more and to talk more. Don't be afraid to ask for reasoning and explanations: "Can you elaborate your thinking behind this clause?", "How did you come to this conclusion?" and so on. As long as you are unsatisfied with the answers you have got, you have not yet asked the right question.
Lesson learned, no. 2: Ask, ask and ask (even if it makes you feel stupid). Talk, talk and talk (even if you think you're talking about no-brainers).
Then I faced a dilemma: It seemed that the client was always right and I was wrong. Should I just stop thinking, go with the flow, and implement everything that was proposed? Fortunately, if that were the case, the client would have hired a robot and not a consultant. Listening to the other party is not about dismissing your own arguments, it's about understanding theirs. When you truly understand each other, you can count on each other, and your communication transforms into a search on how you should go forward together. If you reach that point, you're golden.
Lesson learned, no. 3: You progress the most by trusting and challenging each other.
Now back to the topic of this blog post about the day when I started to listen to the client. There really was a single day in March during which it occurred. Back then, I was quite frustrated from all our communication problems. But I decided that we need to get things sorted out, for the sake of our relationship and for the sake of the business needs of our client. No matter if it would take me weeks - even if I would not get any lines of code written during that time - I would start to listen. And so I did. I started sitting at the client's premises more often. I started being more open-minded in conversations. I started asking questions instead of pushing my own ideas forward all the time. And it paid off tremendously.
The biggest lesson learned was that listening is always a conscious decision. Remember to make that decision.