Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Conversation Patterns for Software Professionals. Part 6

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.


Software Professional

Can you add another button to generate a partial report on this screen?



What data should it be? What to show if there is no data to display? Have you thought about the consequences of aggregating partial data? This may require serious refactoring?

OK... Maybe I will think it over first...


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.

problem to be solved

expected benefit

the need is…

auxiliary questions

I want to avoid…

I want to achieve…


How will you know that...?
What exactly?
How? In what way? What will make you...?
Who? Where? When? With whom? How much? How far?
Give an example...

Why is it important?
What would happen if you did not get it?
What made you want to...?
What is difficult in it?
What can you lose?
What do you want to protect yourself from?
What are you trying to avoid?

What for?
What will it give to you?
How much/what can you gain?
What is the purpose of...?
What happens when you get it?
What will be possible then?
What new or different will it bring?
What advantage can you thus achieve?

Connected with business

How is it related to your work/your business?
How is it related to your business objectives?

The client says:

I do not want to... too slowly not intuitive
The problem is...
That's impossible, because ...
It is difficult, because...
I am afraid that…

The client says:

I really care about...
As a result, I will be able to...
It will make… possible

This will mean that...
The profit if it is...
I'm glad, because it will...
It will be…


What will be the consequences if you avoid it?
What will be the consequences if you achieve it?
If you were now forced to come to terms with one problem, which

one would you choose?
If you were now able to achieve only one of the benefits, which

one would you choose?
If you were now forced to resign from one of the benefits, which

one would you choose?

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.


Software Professional


Can you add another button to generate a partial report on this screen?


The client declares his/her initial position. The software professional would like to offer a solution which is, in his opinion, better, but...


What for do you need this report? What would you like to achieve in your job with this report?

...he first focuses on discovering the need that encourages the client to request this functionality.

The software professional asks about the expected benefits, and the client…


I do not want to wait for the sales charts until the end of the month.



...responds with a problem which he/she is trying to avoid. It happens. Generally, people will not respond to the questions. Rather, they will talk about what they know.
If you asked a question about the benefit and the client told about problems, follow the client.


So the problem here is the waiting for the sales charts for a long time?

The software professional names the need – “waiting for the sales charts for a long time”.





What are the sales charts you need the most?

The software professional wants to formulate acceptance criteria for the need discovered, i.e. he wants to know how the client will recognize that the problem has been solved.

I want the sales to key clients.




If you get an email from us with these charts, will it be OK? Can we forget about this extra button then?

Having the criterion in the form of “sales to key clients” the software professional suggests an alternative solution to the client, but…

Well, no. Because with this button I could have the charts whenever I want, while the email makes me dependent from you.


it turns out that the client is not accepting it. This means that there are still some undefined acceptance criteria that…


Tell me how often you need to view the charts with the sales to key clients if once at the end of the month is too rarely.

…have to be clarified.

At least once every two weeks.


Indeed. Another criterion is the frequency of viewing reports.


Ok, so if you get an email with these charts every 2 weeks, will it be enough for you?

Once again, the software professional proposes an alternative solution considering all acceptance criteria that have been defined so far.

I think so. At least for now.


Bingo! Just in case, the client adds that this is a solution “for now”. Well, the business is changing J

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.

Rate this Article