This is part of an ongoing startup advice series where I answer (anonymized!) questions from readers, like a written version of Smart Bear Live. To get your question answered, email me at asmartbear -at- shortmail -dot- com.
Frustrated Engineer writes:
I’ve been writing code for ten years, recently promoted to a position where I have to talk to our non-technical customers.
They want to use our software or customize things in ways that are technically impossible, but I don’t know how to communicate this to them. They don’t even know how little they know about software, so how do I basically tell them “You can’t understand this. You have to trust me” without sounding like a prick?
I like a doctor analogy.
The doctor says you have a rare liver disease and you’ll need to treat it with a dangerous cocktail of drugs. How do you evaluate whether the doctor is right?
For almost all of us, the answer is: You can’t.
You can’t ask for details, because you’ll get a torrent of nomenclature that’s greek to you (much of which really is Greek, or Latin), body parts you never knew existed, drug names you can’t spell with interactions you’ve never heard of, and references to studies you can’t read.
Even if she explained these details, you can’t evaluate the context — which of those things is dangerous, or unusual? Which are easy or hard to treat? Which are easy to deal with in isolation but complex when they interact? What other things isn’t she saying because in her expert mental process she takes them for granted?
You might try to evaluate the doctor herself, rather than her diagnosis, but here too your lack of expertise leaves you helpless. You can’t grill the doctor on medical knowledge — even incompetent ones know far more than you and can easily overwhelm you with terminology and information. You can’t ask for references because of course she’ll hand you good ones.
In the end there’s nothing you can do, because this is a field that takes years to master, in both education and real-world experience, the complexities and context of which cannot be satisfactorily transmitted to even an intelligent layman.
You’re going to have to trust your doctor.
That’s what it’s like talking to the architect of a software product containing a million lines of code. It’s not that the customer is “stupid,” nor that given enough time, training, and explanation, couldn’t eventually understand it all fully. But sometimes the customer just has to trust the vendor.
One way around this with doctors is to get a second opinion. You still can’t make the call, but at least you can get another expert on the case. Of course if the experts differ, you’re still stuck. Maybe a third opinion? And even then they might choose the wrong course.
The problem with software is that other experts don’t know the intricacies of the software product in question. They don’t know what’s in those millions of lines of code, or the trade-offs made by that product’s creators. The vendor might indeed be incompetent, or shrouding themselves in terminology to avoid helping the customer, and a second opinion isn’t an option. That’s unfortunate.
That’s why this comes down to trusting your software vendor, just like your trust your doctor. If you don’t, no one can help you, because you don’t believe what they say and yet cannot evaluate what they say. If that’s case, sounds like you need a new vendor.
So, as the vendor yourself, I would say (and in fact have said) all of the above. Put yourself out there. Make this a moment where you build trust.
All good business is built on that — trust, which is then not abused.
Add your advice to the discussion section!
27 responses to “How do you tell a non-technical person that they can’t understand?”
Technology sufficiently advanced is indistinguishable from magic….
He should chillax – if he can master explaining things difficult to understand then he’ll have a job long after his core technology is as quaint as the punch cards in my filing cabinet or the Wordstar manual (with SS 8″ disks!) on my bookshelf.
-XC
Sometimes it’s also helpful to explain that using a piece of software (or changing software) often involves changing the way you do business – and that’s usually a good thing!
It’s common for customers to buy or evaluate a piece of software and then ask to make it do exactly what they used to do. Part of the dance is to communicate to them why the new way OF WORKING is better (for example, because x number of customers achieved these tangible results when they made the switch). But you still need to explain what that new way of working means for them – how their lives change.
If you want to get slightly geeky about it, consider that your software solves a certain problem in a certain way. They were presumably solving that problem in a different way before – or not solving it, but at least addressing a related problem at a higher level of abstraction. Focus on THEIR problems that your software DOES address, but recognize that you might need to go up a level of abstraction to explain it (e.g., not “our software makes custom invoices that integrate with any accounting system” but “our software helps you maintain your great brand image when you ask your customers for money”)
Great post. As a non-technical “business” guy immersed in a technical role day in and day out, the only thing I would add is that the the technical professional often maintains just as many, if not more, frame-errors in their thinking, communication and doing. The difference of course is that the technical professional often requires empirical proof of error, whereas the non-technical can often be talked off a ledge with right, ready reason. Whereas generalizations abound here, suffice it to say that technical professionals have a greater propensity to make perfect the enemy of good… and this is often detrimental to any collaborative effort, technical or not.
PS Wanna set the over/under on the number of comments about the absence of a cartoon?
Unless the customer is trying to break the laws of physics or is asking for a feature, user experience or user interaction that is completely unheard of, the correct answer is that you *can* deliver what they want – given enough time and money. :)
The way I’ve approached this situation with clients in the past is to get some high-level requirements from them and then work up a suitable cost and schedule to meet their need. Once you show them the actual cost and time commitment required to deliver their desired feature…and they’ve recovered from the shock…they may ask what they can get for $X…or they may be more willing to listen.
My basic going in position with clients and vendors alike has been “Don’t tell me what you can’t do. Tell me what you can.”
Good luck.
Jason’s spot on – trust is key. There’s a study showing that doctors who get sued the least are not necessarily those with the best training or the most experience, but rather those with the best bedside manner. If you can build trust and a good relationship with your clients, they’re probably going to be happy with you even if you can’t deliver every little thing they want.
You also might try focusing on business goals rather than features. If they ask for XYZ that’s technically impossible, ask them why they want this feature, what they’re trying to achieve with it. Then you can propose a different option ABC that is technologically feasible and solves their business problems.
Great point about doctors and lawsuits.
That carries over to tech support as well. We know (we even have data!) that when we deliver honest, fast, knowledgable tech support at WP Engine, people cancel less and/or are willing to put up with other problems.
We don’t *want* to have problems of course, but it’s just good business to deliver good service.
Ha, I just found the link to the study about doctors and lawsuits! Couldn’t find it this morning: http://www.nytimes.com/1994/11/25/us/studies-show-that-rude-doctors-are-more-likely-to-face-lawsuit.html
Love this: “A doctor can’t get away with being a technical whiz and an interpersonal jerk,” said Dr. Sidney M. Wolfe. And neither can programmers.
I absolutely agree, the study was in “Blink” by Malcolm Gladwell. Trust is imperative in any relationship, so one where potentially thousands of pounds is changing hands must be built on it.
I was the business end of a software company, and I was in some position right in the middle, where I knew more than average related to software and coding, but not enough to understand everything.
Sometimes I would have to make VERY simple comparations to explain why we couldn’t do something. For example I would talk about recipes and ingredients, and how you couldn’t mix some of them. I know it sounds lame, but it helped me explain and have our clients satisfied with our response.
One of the keys to building that level of trust is being extremely up-front when you’re wrong, when you’ve made a mistake, or the product has a shortcoming for their use case.
Obviously, not always possible, like if you’re attempting to have a “just trust me!” moment with a client you’ve never interacted with before. (Or, perhaps you haven’t just made any mistakes that pertain to this client before!)
Then, when attempting to evaluate whether or not you’re BS’ing them, your client can be confident that you’re telling the truth – because they know from experience that you’re willing to tell the truth, even when it’s inconvenient for you.
“The problem with software is that other experts don’t know the intricacies of the software product in question.”
This is also very true in medicine, hence specialization into different branches of medicine.
Also, quite often no-one at all knows enough about the intricate workings of the human body to explain exactly why a treatment works. It just happens to work (and has been shown to in clinical trials), so we use it until the next best thing comes along.
I find that I am almost always able to explain to the customer in terms that they can understand. They won’t get it if I say that the templating library we are using for page generation is incapable of passing structured data. But they DO understand if I say that we built our own tools for drawing the pages, and those tools don’t have any way for us to loop through all the “customers” to show all the detail about each one on the same page. I’ll add that it would be possible to extend the tools to support that, but it would take a couple of months, so I normally wouldn’t consider it on this 2-week project.
Seriously, if you explain the underlying reasons and avoid technical jargon, reasonably bright people without technical background can usually understand what you are trying to say.
I agree with Michael and disagree with Jason.
If I cannot explain to someone who is generally reasonably intelligent something from my area of expertise then most likely it is me who is stupid (or shall I say lack certain communication skills) not the other person.
That BTW applies to doctors as well.
Nope. This answer is simply ‘more of the same’, and colludes with the mystery engineer’s skewed worldview. The ONLY correct answer is: ‘What does the customer REALLY want?’
When a customer asks for something impossible, improbable, stupid, senseless, they’re communicating only a sliver of what they actually mean. It takes a skilled engineer to find out what they’re actually after. And generally, it’s NOT impossible or improbable or stupid or senseless.
Remember, the customer knows he or she is communicating with a geek genius. And this causes this customer to feel more than a little tongue-tied, over-awed, frustrated. Your job is to find common language, and to ease the truth out.
Treat every ‘impossible’ request as an opportunity to say, ‘If I’m hearing you right, and understanding you right when you say X, the underlying issue you’d like solved is Y, and the real outcome you’d like is Z? Have I heard you correctly?’
“It takes a skilled engineer to find out what they’re actually after.”
I disagree. Needs analysis is something that doesn’t necessarily require technical skills at all, as evidenced by the fact that it is part of the classic sales process. They do frequently help though. Still, the rest of your advice is sound. One should dig and probe, and try to find the root cause of their needs.
Yup. You’re pointing to this being a communication task, not an engineering task. I agree fully.
Work for a few years in tech support, you’ll learn how to explain technical concepts to non-technical people very quickly. Or you’ll get fired I suppose.
Naw, this is claptrap. That is a terrible, patronising and deeply flawed way to tell a customer that something isn’t possible. I don’t care that it might be true, it’s rubbish customer service. You should at least attempt an explanation.
Why? Here’s how even the analogy falls apart: I’m married to a doctor. And she has no problem whatsoever explaining things to me. I may have to look half of the words up on wikipedia afterwards but I am a MUCH happier person to have been taught rather than given a brush-off.
I fucking hate vendors who say “we can’t do that”. Quite frequently it turns out I (or someone in my team) can make their product do that anyway.
Nonsense. I routinely manage technical experts outside my own area of speciality, and I am almost always able to gain at least a strong sense of their competence and accuracy.
Ask a lot of questions, and pay attention to how they answer them. Are they smugly self-confident and dismissive, or do they treat your questions seriously? Are they willing and able to explain obscure concepts in watered-down ways that make sense to you, the person who is paying for their services?
Only AFTER your “expert” passes these tests do you have any basis to trust him or her. Trust is not blindly given: it must be earned.
“Build trust!”
This is the real main subject/concusion of this article! And it’s so damn true!
Building trust is a major priority, getting less and less trust, means you have to decrease your hourly rate and your services’ prices more and more, until the point most of your customers will be the worst around: cheap, demanding, and always not trusting you as a good vendor.
Thanks for taking your time to share this wisdom pearl and to make me think again.
And so ugly to admit that trust is so hard to build.
It requires good coded webapps, but also a huge marketing effort.
It’s so much stuff for a microprenur who dreams/attempts to do everything on his own.
Very simply put in my opinion…if you don’t have the skill or should I say ability to explain technology at a level of non technical folk you yourself are in the wrong position. You skill set is probably better suited behind a keyboard in a backoffice. Nothing against you,your probably great at writing code but you may have an inability to sell, explain our bridge the gap with customers and tech.
Sent from iPhone
Spot on Jason….spot on!!!
LOL. Take the blue pill and when that causes your left arm to swell to twice its size, take the red pill to counter the effects and so on. As if both medicine and tech are not already filled with sharlatans who need to be weeded out. I like your pieces but with this, we agree to disagree :)
This is defective thinking. If you’re charged with having to interact with people (customers, patients, clients, etc) and there’s a serious gap of understanding it’s up to YOU, the professional, to bridge that gap. That YOU can’t, or feel so arrogant as to not “want” to do this is not an excuse. Although a great many excuses might be made, in the end, if you want the other person to trust what you’re saying you’re going to have to be able to grasp how to build that trust. And that’s not going to come by just playing the ‘trust me’ game. It’s only going to come when you understand their perspective and translate your specialized knowledge to meet it. If you can’t do this then you really have no business interacting with them. Dressing up the fact that you’re calling them stupid is, well, stupid. And your bottom line will eventually show just how stupid a plan it is.
Ask the right questions, and get back fairly decent answers, then construct a proposal from that and tell them that is what’s going to happen or they can go somewhere else.
Helpful suggestions – For my two cents , others need a IRS SS-8 , my wife used a template document here
http://goo.gl/QPq16jMy children wanted IRS 433-D a few weeks ago and were told about a website with a huge forms library . If others need to fill out IRS 433-D too , here’s
http://goo.gl/uZDOZt