We’re at a trade show booth. A prospective client (“C”) is peering curiously at a vendor computer screen, is posing questions to two vendor software sales engineers (“V”). We join the conversation about 10 minutes in, as the prospective client asks:

C: “So, how do you handle data feeds from multiple systems?”

V: “Well, [and I’m using nonsense text just to shorten the story a bit] we lorem ipsum dolor sit amet, consectetur adipiscing elit.”

C: “Interesting… How does the software determine how to distribute those feeds?”

V: “Ah, It’s completely customizable, and blandit ante id diam imperdiet vehicular.”

C: “Hmmm. Do you provide notifications when that happens?

V: “Yes, again, it’s customizable but aliquam vel magna cursus,nec, tincidunt urna.”

C: “And what information do you then share with the XYZ users?”

V: “We CAN do that in one of two ways depending vehicula neque vel sapien vulputate.”

Pause…. The software engineers are thinking, “Oh, goodie, we have a live one here, this is going GREAT, we’re able to do everything she’s asked about! Oh, this would be SUCH a great project…”

The prospective client looked up: “Well, your software looks interesting, and it provides some incremental capabilities we don’t have in our new systems release…….. but I’m not sure that’s enough to warrant more discussion.”

Sag….. Oh, you should have SEEN the expressions on the two software engineers’ faces. Their jaws dropped.

Yes, wow, that stung! And: It was a TRAP!!! The two software engineers had run enthusiastically headlong right into it. Since I was a mere trade show bystander , it wasn’t my place to head them off and, …HAD THEY ASKED…

And that’s the point. The two engineers should have asked!  Instead, they assumed that the prospective client’s questions reflected her interests – that she was asking for information and screening for features and capabilities she wanted to acquire.

Turns out, NOT! She was asking questions to SCREEN OUT based on what she already had.

Note to self: When prospective clients are asking questions, there’s a good chance that the questions they’re asking aren’t really the questions they’re trying to answer and, taken at face value, they don’t signal much about their concerns or motivations.

Rather than answering their questions as asked, consider first asking clarifying questions, the better to understand the real issues, for example:

Prospective client: “So, how do you handle data feeds from multiple systems?”

Software engineer (before answering the question directly): “Yes, that’s an important question. So, help me understand your environment, then. Which multiple systems are generating and feeding data to which other systems? … How is that working now? … What challenges are you experiencing based on that approach? … How do your teams currently address those challenges? …What thoughts have you had to this point about a solution? ”

THEN… return to the original question: “You asked, a moment ago, how we handle data feeds. Well, based on what you’ve shared, I have a couple of thoughts and a few other questions….”

That way, we can focus on their concerns or the questions they’re REALLY trying to answer rather than the questions they chose to gather data.