Conversation Patterns for Software Professionals. Part 6

How to convince your client/supervisor/team to your ideas? – this is one of the most common questions that come up during my work with teams. In this article you will learn effective techniques that will help you propose solutions that you think are better than those suggested by your client. We will also decide if it is really about convincing. (You may find useful to look into previous parts of the series: Part1, Part2, Part3, Part4, Part5).

Take a look at the excerpt from a conversation in the table below.

Table 1. A conversation about a certain button.

The client asked a question that virtually any software professional knows – Can you do anything more? In this article we are more interested in the reaction of the software professional who asks a fairly large number of questions specifying the business expectations. It appears that this is a very rational action. Nonetheless, if you take a closer look at the reaction of the client who withdraws from the conversation, you may start to have doubts.

Asking a lot of detailed questions (I know cases where the number of questions in a single e-mail dangerously approached one hundred) of a non-technical person such as a client is perceived as aggressive behavior. Just like that! Think about your last visit to a car mechanic, an electrician – or more dramatically – a doctor. How do you feel when a specialist communicates a diagnosis to you using a large number of incomprehensible words that sound like this: blah blah-blah-blah-blah three thousand? Pause for a moment and contemplate this uneasy feeling of total helplessness and dependence from a specialist.

Do you know what I mean by saying that asking the client about a number of technical issues is perceived as aggressive behavior? The members of your team are another matter. You can ask thousands of technical questions of them and it will still be a quality conversation. They are prepared to answer such questions and have the necessary knowledge. The client, however, does not have this knowledge.

I sometimes notice that asking many questions is used by teams as a tactic to say “no” or to shift the deadlines. The first technique of this article is: If you want to say “no”, say “no”. If you want to say “later” say “later”. Saying “no” is being assertive. This may not please the client and trigger a fierce discussion or tough negotiations. The plus of saying “no” is that we know where the moot point is and we can start looking for solutions. Saying “no” in an indirect way, that is, by asking a lot of questions is aggressive and it directs the attention to some entirely irrelevant details. This way, it certainly does not add business value.

You might now wonder how – since I urge you not to ask a large number of technical questions – you should propose an alternative (and in your opinion – better) solution to your client? It all boils down to the purpose of asking such questions. If you want to clarify something, you ask different questions than when you want to move the deadline. Secondly – and this is my focus in this article – suggest alternatives and ask technical questions, but at the right time.

Discover the need

In the articles ConversationPatterns for Software Professionals Part 1 and Part 2 I wrote in detail about what needs are, how to recognize them and how to extract them. See Table 2 for the most important information about the needs.

Table 2. Discovering business needs in a nutshell.

First, discover and name the client’s need, then go on to suggesting alternatives – this is the main principle of talking with clients. Figure 1 illustrates this pattern of action.

Figure 1. Suggesting alternative solutions.

The first step is determining the position of the client, that is, answering the question “What does the client declare as wanted”? The second step is discovering the client’s needs hidden behind his position. According to Table 2 these may be benefits to achieve or problems to be solved. Next, name the main need which should be: specific, connected with the business of the client and motivating.

My observations indicate that, normally, we tend to propose alternative solutions immediately after identifying the position of the client. This most often leads to a conflict. Not in the sense of an argument, but in the sense of forming polarized positions and throwing arguments at each other.

The third step is a bit difficult. It is a moment at which you need to define the criteria for meeting the need, i.e. the criteria of solving the problem or achieving the benefit. Criteria are nothing but acceptance tests for the need. In other words, they show how the client will know that the need has been satisfied. Only after naming the needs and defining acceptance criteria does the right moment to propose an alternative and more appropriate solution to the client come.

Sometimes it happens that even after naming needs and defining acceptance criteria the client does not agree to the solution you have suggested. It only means that there are still some criteria that you have not recognized. Simply ask: What else, apart from <<KNOWN CRITERIA>>, has to happen to achieve/avoid <<NEED>>?

Table 3 illustrates a conversation about an “extra button” presented at the beginning, which has been managed according to the pattern of suggesting alternative solutions illustrated in Table 2.

Table 3. A conversation about a certain button.

How do you think – is this article talking about convincing? Technically speaking, the software professional has changed the client’s mind, so he “convinced” him. Note, however, that this has been associated with the identification and understanding of the client’s needs – and not with providing the right number of arguments. Arguments are helpful in confirming the already convinced people in their decisions. In contrast, discovering the needs and defining the criteria is necessary to find a solution beneficial for, both, the client and you.

About the Author

Michał Bartyzel – I have been dealing with the topic of the efficiency of the development teams for ten years so far. I am working on improving both the architecture of the applications and its refactoring, as well as on improving the cooperation between the so-called business and the development teams. So far, I have conducted more than five hundred training and consulting days with the best development teams in Poland. I have come to a conclusion that linguistic skills are the key to Software Craftsamanship. This applies to, both, the ​​cooperation with business and the developer’s job, which I show in the trainings that I design and dedicate to refactoring, working with code and architecture. Many techniques that I have developed so far are presented here. I also share some new techniques that I am currently working on during numerous conferences, on my blog and in the Programista magazine.