10 Ways To Explain Things More Effectively By Calvin Sun

In the course of your work, you may sometimes need to explain technical concepts to your customers. Having them understand you is important not only for technical reasons, but also to ensure customer satisfaction. The ability to explain things clearly and effectively can help you in your career, as well. Here are a few tips to help make your explanations understandable and useful.

#1: Keep in mind others' point of view

You've probably seen the famous illusion that looks like either a young woman or an old woman. Two people can look at that same picture, and they can have opposite views of what they're seeing. Keep this idea in mind when explaining a concept. Something that might be perfectly understandable to you might be incomprehensible to someone else. Don't be the person customers complain about as using "geek speak."

2: Listen and respond to questions

It's easy to become annoyed when someone is asking questions. However, try to resist that reaction. A better attitude is to be happy that the other person is interested enough to ask questions. To minimize confusion and misunderstanding, try to paraphrase or summarize a question before you answer it. This step is particularly important if you're in a group setting, and you've just taken a question from someone in the audience. Repeating the question for the entire group helps everyone better understand your answer.

#3: Avoid talking over people's head

When you explain things to people, do their eyes glaze over? Chances are it's because you're talking over their head. Symptoms of such behavior include the use of jargon and acronyms. Remember, the people you're talking to probably lack your specialized knowledge, so you should use readily understandable terms.

The same goes for acronyms. They're important, but if you use them, define them in "longhand," followed by the acronyms in (parentheses), so that everyone's clear. Doing so avoids the scenario of situation normal, all fouled up (SNAFU).

Even within IT, the same acronym can mean different things. For example, both "active server page" and "application service provider" have the acronym ASP. A story from the Vietnam War era further illustrates this point. A young woman brought her boyfriend home to meet her father, a retired military officer. The woman was nervous because the boyfriend was a conscientious objector. When the father asked the young man to talk about himself, the latter replied, nervously, that he was a CO. The father clapped the young man on the back and congratulated him, thinking the latter was a commanding officer.

#4: Avoid talking down to people

Avoid the other extreme as well. Don't insult people by assuming that they're only as intelligent as a three-year-old. An attendee at one of my communications training classes described it aptly as "Barney communications."

Greek mythology has references to two monsters, Scylla and Charybdis, who sat on opposite sides of a narrow strait of water. If a ship sailed too close to Scylla, it was destroyed and the sailors eaten up. If the ship sailed too close to Charybdis, it was destroyed by a whirlpool that Charybdis created. The ship had to go right between them to survive. Follow that same principle with your customers: Make your explanations neither too complicated or too simple.

#5: Ask questions to determine people's understanding

The people you're talking to shouldn't be the only ones asking questions. You should be asking questions as well, to make sure they understand. Your questions can be open ended, which gives people a chance to provide detailed information, or they can be closed ended, which generally calls for a simple yes/no response. In either case, asking questions tells people that you're interested that they understand.
#6: Focus on benefits, not features

What's the difference? A feature is some inherent property of an object. A benefit, on the other hand, is a way the feature helps a person. For example, one of the features of a Styrofoam cup, because of the material used, is insulation. Someone who's planning a party probably doesn't care how the cup provides insulation. That person is more interested in the fact that such a cup keeps hot things hot and cold things cold.

In the same way, try to focus on benefits of technology rather than features of technology. This distinction becomes more important the higher the level of the person you're talking to. The CFO probably has little need to know about the specific commands and steps involved in setting up database mirroring. That person will want to know, however, that such a practice reduces the chances of data loss.
#7: Use analogies to make concepts clearer

An analogy involves explaining an unfamiliar concept in terms of a familiar one. For example, in drawing an analogy between a firewall and a bank teller, you could say that people don't just go directly into a bank and take money out. They go to the teller and identify themselves; the teller makes sure they have enough money; and then the teller gives them the money. Similarly, a firewall ensures that people who want access to a system really are permitted to have that access.

When choosing an example for an analogy, first figure out the general principle you're trying to explain. Then, choose something from real life that illustrates that principle. Say, for example, that you're trying to explain memory leaks. Suppose you conclude that the principle involved is that of taking without giving back completely. An example/analogy might be the consequences of pouring a cup of pancake batter into successive measuring cups, or the consequences of lending money to your brother-in-law.
#8: Compare new concepts to familiar ones

Another illustrative technique is to use a familiar or existing product as a comparison. If you're explaining a new release of a software product, the comparison is easy. Simply discuss the additional capabilities it has over the previous one or how key features are different. If the person hearing your explanation is also an IT person and is familiar with different or older technology, try explaining in those terms if you can. For example, when explaining thin clients, consider a comparison to the old 3270-type terminals that IBM once used for connection to mainframes.
#9: Use the concepts of subsets and supersets

Brooklyn is a subset of New York City, because all of it is a part of that city. Conversely, New York City is a superset of Brooklyn, because the former contains, in addition to all of the latter, other boroughs as well. These concepts are helpful in describing, for example, a "lite" versus a "professional" version of a software product. If the latter does everything the former does, plus more, it truly is a superset of the former, and the former is a subset of the latter. Be careful, though: If the "lite" version does even one thing that's missing from the professional version, there's no longer a subset/superset relationship.
#10: Confirm that your explanation makes sense

Once you've finished explaining your point or answering a question, ask a final question yourself. Make sure the people who heard your explanation truly did understand it. Consider asking them to give you the explanation in their own words, just to double-check.
About the Author

Calvin Sun works with organizations in the areas of customer service, communications, and leadership. His Web site is http://www.calvinsun.com and his e-mail address is csun@calvinsun.com.

GOD BLESS AMERICA

God bless america

View more presentations from gugacalifornia.

A classic example of the prisoner's dilemma...

The prisoner's dilemma is a fundamental problem in game theory that demonstrates why two people might not cooperate even if it is in both their best interests to do so. It was originally framed by Merrill Flood and Melvin Dresher working at RAND in 1950. Albert W. Tucker formalized the game with prison sentence payoffs and gave it the "prisoner's dilemma" name (Poundstone, 1992).

A classic example of the prisoner's dilemma (PD) is presented as follows:

Two suspects are arrested by the police. The police have insufficient evidence for a conviction, and, having separated the prisoners, visit each of them to offer the same deal. If one testifies for the prosecution against the other (defects) and the other remains silent (cooperates), the defector goes free and the silent accomplice receives the full 10-year sentence. If both remain silent, both prisoners are sentenced to only six months in jail for a minor charge. If each betrays the other, each receives a five-year sentence. Each prisoner must choose to betray the other or to remain silent. Each one is assured that the other would not know about the betrayal before the end of the investigation. How should the prisoners act?

If we assume that each player cares only about minimizing his or her own time in jail, then the prisoner's dilemma forms a non-zero-sum game in which two players may each either cooperate with or defect from (betray) the other player. In this game, as in most game theory, the only concern of each individual player (prisoner) is maximizing his or her own payoff, without any concern for the other player's payoff. The unique equilibrium for this game is a Pareto-suboptimal solution, that is, rational choice leads the two players to both play defect, even though each player's individual reward would be greater if they both played cooperatively.

In the classic form of this game, cooperating is strictly dominated by defecting, so that the only possible equilibrium for the game is for all players to defect. No matter what the other player does, one player will always gain a greater payoff by playing defect. Since in any situation playing defect is more beneficial than cooperating, all rational players will play defect, all things being equal.

In the iterated prisoner's dilemma, the game is played repeatedly. Thus each player has an opportunity to punish the other player for previous non-cooperative play. If the number of steps is known by both players in advance, economic theory says that the two players should defect again and again, no matter how many times the game is played. However, this analysis fails to predict the behavior of human players in a real iterated prisoners dilemma situation, and it also fails to predict the optimum algorithm when computer programs play in a tournament. Only when the players play an indefinite or random number of times can cooperation be an equilibrium, technically a subgame perfect equilibrium meaning that both players defecting always remains an equilibrium and there are many other equilibrium outcomes. In this case, the incentive to defect can be overcome by the threat of punishment.

In casual usage, the label "prisoner's dilemma" may be applied to situations not strictly matching the formal criteria of the classic or iterative games, for instance, those in which two entities could gain important benefits from cooperating or suffer from the failure to do so, but find it merely difficult or expensive, not necessarily impossible, to coordinate their activities to achieve cooperation.

Strategy for the classical prisoner's dilemma

The classical prisoner's dilemma can be summarized thus:

Prisoner B Stays Silent Prisoner B Betrays
Prisoner A Stays Silent Each serves 6 months Prisoner A: 10 years
Prisoner B: goes free
Prisoner A Betrays Prisoner A: goes free
Prisoner B: 10 years Each serves 5 years