How to answer a question

As technical experts, sales engineers are asked questions all day long. Via phone, email, web conference or in person your typical sales engineer gets bombarded with questions from all directions.

To the layman, answering a question is easy… you just reply with the answer. As it turns out, there is an art to fielding questions and most people never learn how to do this really well.

The most important part about answering a question happens before you say the first word in your reply.

If you want to answer a question correctly, it’s critically important to make sure that you understand exactly what is being asked.

Not fully understanding the question before replying is a common problem among sales engineers. Sometime this happens when the sales engineer is thinking about his reply rather than listening closely to the question. There are two great techniques that can help you in these situations:

1. Repeat the question back to the other person to make sure you are on the same page. For example “So, are you asking if this same query string will work if we decide to run our query against Oracle instead of MS SQL Server?”

2. Ask a clarifying question. For example, “I’m not sure I follow you here… can you give me an example?”

Each of these techniques serves two purposes: they ensure that you understand the question and they buy you some time so that you can devise an answer. This is far better than closing your ears halfway through the question so you can ponder the answer in silence.

Another challenge…

Another challenge some sales engineers face is providing far too much information in their answers. The problem was described to me once as:

The customer asked “what time is it?” and you told him how to build a watch.

A brief answer that gets directly to the point is superior to an answer that provides so much detail that the listener forgets the original question. Answer the question directly and don’t volunteer to explain all of the supporting layers unless asked.

If you are concerned that short, concise answers are not sufficient you can always follow up your reply with a verification question, such as “Did that answer the question?” or “Would you like more detail on this?”

Surprisingly, sometimes the most challenging questions are simple yes or no questions.

Here’s my strategy for handling yes or no questions:

• If the answer is “yes” then say so as strongly as possible, repeating the question afterward. For example, “Yes, we can definitely sync over the air to both iPhones and Android.”

• If the answer is “no” then dig into the question a bit. For example, years ago a customer asked me if he could use ActiveX controls in a Java application he wanted to develop with my company’s programming tool. The answer is “no”, so I asked him “What problem are you trying to solve by doing that?” His answer, “I just want to know that I can extend the set of UI controls that ship with the product.” That’s a completely different problem than the one he originally posed, one where I could honestly tell him “Yes, you can definitely do that in our product using Java components.”

  Be absolutely sure you understand the thinking behind the question before you are ready to throw in the towel.

• If the answer really is no, I personally hate to say “no” during a presentation to a group of people because overtly negative answers can put a dark cloud over the rest of the meeting. (I’ll cover the tricky dynamics of group presentations in another post.) In these situations, I prefer to answer with a positive statement that still gets the message across. So, if I’m asked “Do you support Sybase?” and we don’t my answer would be “We currently support Oracle, MySQL and MS SQL Server. Our database support policy is heavily influenced by customer feedback and I would be happy to submit a Sybase feature request for you.” I think that’s a better answer than merely saying “No, we don’t support Sybase.”

  In other words, this is one situation where a little bit of extra information in your answer is a good thing.

One final note about replying to questions. Nobody expects you to have the answer to everything. If you don’t know the answer, don’t shoot from the hip and hope for the best. Take detailed notes on the question and provide an accurate answer via a follow-up email. You can’t play this card too many times in one discussion before you start to lose your technical credibility, but if you use it once or twice most prospects and customers will appreciate your commitment to getting them the right answer.