One common problem when explaining ideas is that we often jump right into talking about the solution, and just assume prior knowledge of the problem we are talking about.
But since the audience probably doesn't know the problem as intimately as we do, this tends to make our explanation hard to understand - even if our solution is straightforward.
A simple trick I once learned is to structure the explanation into four parts, with one sentence for each part: (1) state the problem, (2) state the consequences of the problem, (3) state the solution, (4) state the consequences of the solution.
Since the explanation now automatically includes both the problem and the solution, it usually is both more compelling and easier to understand.
2 & 4 are so crucial. They represent what 1 & 2 mean. Otherwise you have just put an idea in the ether, floating like Forrest Gump's feather but without truly communicating it to anyone in particular. 2 & 4 are the attempt to connect the idea to something in the other person's mind. To make it resonate with them (think about the physical meaning of that word). Or as another commenter put it, "why is it useful?"
It's always possible that your idea with land with something by accident, but it will be by accident and it may not land with the person you intended it to.
A similar pattern I try to use frequently is this:
>A simple trick I once learned is to structure the explanation into four parts, with one sentence for each part: (1) state the problem, (2) state the consequences of the problem, (3) state the solution, (4) state the consequences of the solution.
That's a good structure! I have thought about it -- in the context of technical talks -- as Why/What/How. You start at a high level, and progressively zoom in. Why is the problem, What is the solution, and How is the technical details of the solution.
Aside from the text, the Telstra TV advertisement he linked to is a classic. I remember seeing it when it was broadcast in Australia years ago and it was funny then, and now as a parent of a curious kid I resonates in a different way. Reminds me a little of how Calvin’s Dad in ‘Calvin and Hobbes’ would invent answers to his son’s questions (how do they figure out the load limit for a bridge? what is the theory of relativity?).
In terms of technical solutions relevant to this community, I have often found that people understand, but they don't see why a given thing is useful, so they say: I don't understand. In fact it may be necessary to explain the preceding bad ideas in terms of how they were supposed to be useful but weren't, and even how usefulness was bypassed in favor of some irresistible (and misguided) idea of virtue. Either way, understanding begins with "Why I would ever use this?" It's sort of obvious but routinely forgotten.
A lot of interesting ideas in this for sure, but at various points when reading it I was thinking "I bet the people who have to implement what you're selling are not going to be happy" :)
The problem with reducing products or services to simple ideas that can be communicated enticingly, is that it necessarily glosses over details that get left to the implementors.
So the product/campaign gets sold, the idea people move on and someone has to explain to the customer that the widget that prevents floods, doesn't actually work like that.
I’ve found that many companies have outsourced that role to youtube and blogs. The manufacturer/ developer provides a bare minimum of instructions, and I end up finding the actual how-to and troubleshooting guides from helpful users online.
I hadn't thought to call it gatekeeping, but this annoyed me too. People should say, "This is how I am going to use this word right now while I explain this," and not, "To understand what I'm explaining you first need to realize that the correct use of this word in this one limited way I'm using it right now."
I've noticed a LOT of discussion on HN around this theme in the past week -- that so much trouble happens when people disagree on what words mean and refuse to be more specific. This is a good example of one way this kind of thing starts, which is that someone tries to dictate the meanings of words and categories to advantage of their own beliefs relative to the beliefs they oppose. You see this everywhere from politics to business to debates over whether hot dogs count as sandwiches or not.
I've encountered this going back to the beginning of my career with basic software engineering terminology. Different experts have different definitions of terms like "unit test" or "user story," and they think the differences are important, for good reasons, so they promote their own definitions. Some software engineer learns one expert's definitions and they become impossible to talk to because they keep correcting you about what words mean. They don't understand that there are differing expert opinions, and that the experts who promote the definitions they use are reasonable people who converse and debate with other experts who use different definitions. But when I say "in the past I've found it useful to think about it this way" they just say "but that's not a unit test" or "that's not a user story" and I say "I think in these circumstances this is the kind of user story that serves us best to succeed on this project, for these reasons" and they just say "but that's not a user story because a user story has to..." and the conversation goes nowhere.
I learned way too late in my career that just because your company's self-appointed authority on some software engineering concept makes it sound pedantic and useless doesn't mean it is. Chase it down to the source, and you'll likely find a thoughtful and nuanced take on it.
I’m reminded of this fascinating piece, which discusses the approaches taken by a woman attempting to teach language to a deaf man who, at 23, had lived his entire life languageless.
It really depends on who you are relative to the person with the idea.
Are you a prospective customer? I agree with you.
Are you a student? You're paying for the opportunity to listen, so you probably should.
Are you a product leader? It's your job to listen.
Furthermore, "showing" is not always feasible for an idea that is sufficiently complex or expensive to implement, and maybe impossible for ideas that are too early to fully articulate.
All to say, nothing can be reduced to overly simplistic solutions like "just use this definition of idea", or "just show me".
> 12. Apply the Blink test
I can’t recall a client buying an over-explained idea. People either get it and want it or or they aren’t and they don’t. Within seconds. Make a fast impact.
Is this true? I agree with the rest of the advice but this sounds odd to me.
There's certainly a class of enterprise salesperson that's done very well out of IT projects with buzzword-centric explanations the client thinks they should get "leveraging the synergies of AI-driven Big Data Cloud Blockchain" because they've heard the words in all the right reports and these are definitely cutting-edge, blue-sky thinking people. (Sure, there's a for dummies explanation that it's a database with some analysis tools buried in there, and they told the salesperson the business problem that needs a database, but the mumbo-jumbo is the pitch for why its a better way of solving a business problem than a regular database)
I got confused with the author’s definition for the word ‘idea’, and decided to check the etymology. I found it quite fascinating!
late 14c., "archetype, concept of a thing in the mind of God,"
<…>
Meaning "mental image or picture" is from 1610s (the Greek word for it was ennoia, originally "act of thinking"), as is the sense "concept of something to be done; concept of what ought to be, differing from what is observed." Sense of "result of thinking" first recorded 1640s.
But since the audience probably doesn't know the problem as intimately as we do, this tends to make our explanation hard to understand - even if our solution is straightforward.
A simple trick I once learned is to structure the explanation into four parts, with one sentence for each part: (1) state the problem, (2) state the consequences of the problem, (3) state the solution, (4) state the consequences of the solution.
Since the explanation now automatically includes both the problem and the solution, it usually is both more compelling and easier to understand.