Just Answer the Question
"Just answer the question."
When you read that phrase you probably picture yourself scolding someone who's being evasive in answering your question- or remember times when others have scolded you for beating around the bush. But this week I encountered a situation at my job that reminded me it's actually good advice to practice yourself. ...Okay, and to scold others with, too. 😉
The situation this week was that a new customer who'd just bought product "S" from us asked if there's an integration between S and its biggest competitor, "T". Well, the simple answer is no. We don't offer an integration with T, and T's maker doesn't offer an integration with us.
When the customer's question came in by email, my two colleagues who sold our product S to this customer started panicking. "This could be a show stopper," the account manager lamented. "I might have time tomorrow to try installing T and see if I can figure out how to make something work," the sales engineer offered. "But I'd have to rearrange my schedule."
"Guys," I countered, "Let's just answer the question first, and go from there."
They were confused. Verbally they were chasing their tails. They were still panicking about what the question might mean.
I agree it's important to consider what a question means. Plenty of times a person asks a question as part of an agenda. Sometimes that agenda is fairly evident based on exactly how the person asks their question, or other things they've said recently, or whatever else you know about the person. When you know there's an agenda behind a question you've got to anticipate what the real question is while answering the opening question.
But sometimes there is no agenda. Or there is an agenda, but it's totally not obvious which of two (or more!) opposite ways it could go. Assume incorrectly and you could derail the conversation or insult the other person. In such cases I believe it's important to start with a simple, factual answer. Answer the question first, then determine what needs to be done next based on the response.
I wrote the customer a reply like this:
Hi [customer name],
We do not offer an integration between S and T, and the other vendor does not either. I'd like to understand more about the business needs you're looking to address by combining the two products. Please give me a call at (xxx) xxx-xxxx so we can discuss.
The customer phoned me within minutes. We chatted for about 15 minutes and I learned several things, all of them good. The first was that my giving a simple, factual answer fast was really important because the guy was under pressure from his own manager to pass an answer up to his VP asap. If I'd ducked the question for a day or two while trying to build a science fair project, like the sales engineer wanted to do, I'd have failed the customer right there.
Second, "No" turned out to be a perfectly reasonable answer. I spent a few minutes explaining why such a integration would be technically difficult to accomplish. Basically, the two products serve some overlapping goals but they have conflicting back-end implementations that would step all over each other if they were put together. The customer was a technical guy and understood this very well. He understood it and he thanked me for giving him the context.
Third, I learned that it wasn't even a high-stakes question. The customer has 30 people using product T, compared to 600+ for our product S. Their execs plan to force the hold-outs sticking with T to move to S eventually. My counterpart was just looking to see if there was a way to bridge them sooner and reduce the administrative overhead (read: whining).
Fourth, I offered him an alternative solution. It meets only half of his desires, but the good news is that it's an "straight out of the box" solution. It doesn't entail weeks of effort just to arrive at a Frankenstein's monster of an IT system that's too brittle to suport.
It was a win all the way around. Remember to just answer the question!
When you read that phrase you probably picture yourself scolding someone who's being evasive in answering your question- or remember times when others have scolded you for beating around the bush. But this week I encountered a situation at my job that reminded me it's actually good advice to practice yourself. ...Okay, and to scold others with, too. 😉
The situation this week was that a new customer who'd just bought product "S" from us asked if there's an integration between S and its biggest competitor, "T". Well, the simple answer is no. We don't offer an integration with T, and T's maker doesn't offer an integration with us.
When the customer's question came in by email, my two colleagues who sold our product S to this customer started panicking. "This could be a show stopper," the account manager lamented. "I might have time tomorrow to try installing T and see if I can figure out how to make something work," the sales engineer offered. "But I'd have to rearrange my schedule."
"Guys," I countered, "Let's just answer the question first, and go from there."
They were confused. Verbally they were chasing their tails. They were still panicking about what the question might mean.
I agree it's important to consider what a question means. Plenty of times a person asks a question as part of an agenda. Sometimes that agenda is fairly evident based on exactly how the person asks their question, or other things they've said recently, or whatever else you know about the person. When you know there's an agenda behind a question you've got to anticipate what the real question is while answering the opening question.
But sometimes there is no agenda. Or there is an agenda, but it's totally not obvious which of two (or more!) opposite ways it could go. Assume incorrectly and you could derail the conversation or insult the other person. In such cases I believe it's important to start with a simple, factual answer. Answer the question first, then determine what needs to be done next based on the response.
I wrote the customer a reply like this:
Hi [customer name],
We do not offer an integration between S and T, and the other vendor does not either. I'd like to understand more about the business needs you're looking to address by combining the two products. Please give me a call at (xxx) xxx-xxxx so we can discuss.
The customer phoned me within minutes. We chatted for about 15 minutes and I learned several things, all of them good. The first was that my giving a simple, factual answer fast was really important because the guy was under pressure from his own manager to pass an answer up to his VP asap. If I'd ducked the question for a day or two while trying to build a science fair project, like the sales engineer wanted to do, I'd have failed the customer right there.
Second, "No" turned out to be a perfectly reasonable answer. I spent a few minutes explaining why such a integration would be technically difficult to accomplish. Basically, the two products serve some overlapping goals but they have conflicting back-end implementations that would step all over each other if they were put together. The customer was a technical guy and understood this very well. He understood it and he thanked me for giving him the context.
Third, I learned that it wasn't even a high-stakes question. The customer has 30 people using product T, compared to 600+ for our product S. Their execs plan to force the hold-outs sticking with T to move to S eventually. My counterpart was just looking to see if there was a way to bridge them sooner and reduce the administrative overhead (read: whining).
Fourth, I offered him an alternative solution. It meets only half of his desires, but the good news is that it's an "straight out of the box" solution. It doesn't entail weeks of effort just to arrive at a Frankenstein's monster of an IT system that's too brittle to suport.
It was a win all the way around. Remember to just answer the question!