Just, Why… People?

cartoon5929Have you ever had that annoying conversation with someone where it took you having to ask several questions before you could get a simple explanation as to “why”? Those who are around young kids a lot are usually on the other end of that conversation with a seemingly endless stream of “why’s” when trying to communicate. As SE’s our primary job function is to communicate information to others. We all tend to be pretty good at telling customers the who, when, what, how of the problem or solution, but far fewer of us are adept at the why portion. And as you probably already intuitively know, the why is often the most interesting element of communication.

Let’s look at three examples to understand to see what I mean.

Why do I need this solution?

A common trap for seasoned SEs is that they understand the problem so well that they instinctively think the customer understands the problem as well as they do. So they “don’t waste the customers time” and instead jump into the product. The customer, happy to just get to the technical “meat” of the meeting, responds favorably, and no one thinks to probe deeper to really uncover all of the use cases and intricacies of the customer’s business processes and situation.

The problem isn’t that customers are unwilling to have a discussion around the business problem, it’s that you (or rep) aren’t challenging the customer’s assumptions. And if you aren’t challenging assumptions, they really aren’t learning anything about their business or trade. And when that happens, your only value is your knowledge about the product. Instead, your job is to know much more about your niche than your customer, and thus you should be in a position to coach. This should be self evident in the fact that you work on solving this one problem all day long over and over with other customers. There is no way your customer will be able to match that depth nor should they. Tell them why your other customers found your solution so uniquely compelling.

Why doesn’t the product do xyz?

I always love the opportunity to bring product management into my meetings. I always learn something new I didn’t know. Most people believe their greatest power lies in their intimate product knowledge or in their control over the roadmap.

I disagree.

The two things they can do better than I can do as an SE is demonstrate a knowledge of the market as a whole. They work daily to out-strategize the competition. And because of this knowledge, they are in the best position out of anyone to understand why a product functions the way it does, or why a particular trade-off was made. So whereas I might have to tap dance around why we don’t support that database version, they can tell the customer the reason we don’t support it is because they decided to prioritize this big feature that these large customers of ours were really pushing for which should help other customers as well. Customers get angry when your company makes seemingly stupid technology decisions. When you have someone that can illuminate the bigger picture on which that decision was made, the customer usually comes to the same conclusion as the product manager, realizes it was a smart move, which actually increases the confidence the customer has in our team and solution. Your job as an SE is to pick up as many of these anecdotes as possible and have them ready around your product rough spots.

Why am I experiencing this issue?

This question has caused me some grief as I’ve been working with startups for quite some time. Where I get into trouble is when I’m going through a POC and I encounter a bug–especially if it is clearly something that should have been caught in QA. Sometimes I will get a support answer back akin to “we are aware of the issue and it will be fixed in the next release”. If you would pass along an answer like that to a customer, then please let me know if you’re looking for a job and I’ll connect you with my competition.

If you’re a customer and you hear something like that, wouldn’t you think something like:

  • They must not have very good QA
  • They must not have any customers using this thing
  • I’m testing their beta code for them

So when I get an answer like that from support, I tend to drive them crazy getting to the why: Oh, so this customer is getting a conflict with this driver that is really old and only present in a minute portion of our install base and we caught it while beta testing with one of our large customers and we just posted it to knowledge base yesterday? That’s what I can communicate to my customer to ensure they maintain confidence in our release process.


I’m sure there are many more variations on this theme and I am just scratching the surface. The takeaway here is to act like seasoned parents do and provide the “why” before the child (or customer =) has the chance to ask.

Comments here.