Engineers are not good with people

One of the rules of the LeSS framework is “The Product Owner shouldn’t work alone on Product Backlog refinement; he is supported by the multiple Teams working directly with customers/users and other stakeholders”, I think there is overall agreement that teams that know and understand their customers can do a better job in delighting them and also demonstrate higher level of responsibility and motivation towards satisfying the customer.

Still, to some organizations getting the teams to work directly with the customer sound not only counterintuitive but also virtually unachievable.
I hear statements such as “developers are not skilled to communicate directly with customers” or “our customer doesn’t want to be contacted for questions”. While those arguments make sense to some, I find that they are based on a set of assumptions which I disagree with.

Let’s examine those two assumptions

1. “Developers are not skilled to communicate directly with customers”

How come? Who is skilled to do that? What superpowers does this person have that team members do not?
From the teams I have witnessed, most team members are able to speak, hear and even write – which are, as far as I am concerned, the basic skills required to communicate with others.
Often the missing skill of team members is to understand some basic ground rules regarding what can and cannot be said to a customer in a given situation, or what are some of the cultural aspects that we need to be aware of.
But we are talking about highly qualified, smart and talented software developers (yes. Testers are also developers), don’t you think that this kind of knowledge is something they can comprehend? They are dealing with complex algorithms and logic, math, programming languages and more.
So, please do teach them what they need to know, mentor them and help them acquire the necessary skills that will enable them to help the organization delight the customer.

2. “Our customer doesn’t want to be contacted for questions”

I often hear that “Customers don’t like it when being asked for clarifications about their needs” – Let’s use a metaphor to explain why this statement is not a fact but an assumption (that is often wrong).
Imagine you are at a restaurant, you look at the menu and find something that you like. When the waiter comes you order it and I bet the next thing you expect to happen is that the dish will be served to your table, and what really happens surprises you, the chef approaches your table leans over and asks “I noticed you ordered the Tuna steak dish with vegetables, is there any specific vegetable you prefer? How do you want the vegetables cooked? How salty or spicy do you like your food?”.
Now, return to the real world (SNAP!)
Regardless of the answers, in your imagination, is the fact the Chef came to your table annoying? Do you feel anything wrong with this situation?
I don’t know about you, but in my imagination I am delighted! I think: “Wow, this chef is really interested in me having a good experience that matches my needs”. Why does this dynamic doesn’t apply when developing a software product? I think it applies. In my experience many customers would really like to be more involved but don’t realize that the option exists. Have you ever asked your customers if they want to be in the loop of product clarification and refinement?

All I am suggesting is to consider this option deeply and when it seems hard, try to identify what are the reasons for it being hard and find a way to make it easier.

May the force be with you,



Share on print
Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on email