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’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)
Readit News
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.
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:
1) what it is
2) what it means
3) an example
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.
I have a longer explanation at https://twitter.com/zckzck/status/1483330904571494400
(1) state the problem, (2) state the source of the problem, (3) state the solution, (4) state path to implementing the solution
Dead Comment
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.
How to not explain an idea: bombard the reader with endless gatekeeping.
https://neuroanthropology.net/2010/07/21/life-without-langua...
I don't have time for people explaining things in lectures, long essays, or novels about your idea or product.
I'll just get up and leave.
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".
Is this true? I agree with the rest of the advice but this sounds odd to me.