As any really good sales person will tell you, you're missing the most important point in the sequence above, between items 3 and 4. You wasted an insurmountable amount of time describing the "What". Most tech speakers waste a very long time explaining the "How", with code examples, live coding, trying to convince you how easy it may be.
But they often forget to ask the question: "WHY the pen could be important for YOU". "YOU" being the audience. You're not connecting. You're lacking empathy. You're telling them, not persuading them. Telling and Persuading are worlds apart.
The WHY is the most important thing. And the difficult part in large audiences is that each person has a different "WHY" that needs a good answer.
Whenever I see a speaker/writer/evangelist giving too much time for imaterial stuff like "benchmarks", "performance", "hyper-modularized architectures", I see them missing a large portion of the audience. Because while they have legitimate reasons for worrying about those points - because they experienced it inside Unicorns like Netflix, Facebook or Twitter - I will argue that more than 95% of the audience population will never have those problems.
Therefore, you're trying to push a Lamborghini to people that not only can't afford it, but even if they could, it's not nearly at the top of their priority lists. Yes, the Lamborghini is obviously a fast and fine car. But WHY do I need it? WHY are you trying to push it to me? WHY is this pen even relevant to me?
Your priority is not my priority!
I see an interview as a talk for an audience of one. And I see a blog post as a talk for an audience I can't see. The structure is exactly the same.
But in a one-to-one interview we all have an extra very important advantage: you get to ask direct questions! Do you realize how important that is? In a talk with an audience you have to make assumptions on what they want to hear. In an interview you get to ask directly and give straightforward answers, closing the gap of assumptions.
The irony is that most people don't ask questions on interviews. It's so much easier to make assumptions: "everybody wants to hear what I like to hear, because I know better". This is the utmost lack of empathy. Let's say that you're a top engineer working on performance sensitive tech in your unicorn startup. You tried everything and decided to write key real-time components near the bare bone metal, in C. And now you give talks about how important it is that everybody starts everything in C.
Now, communication is an art. Requires research, study, practice. You must understand your mother language very well, the grammar, the many subtle phrase constructions that better convey the message. There are several "design patterns" when it comes to Argumentation Theory, many well known traps, fallacies you want to avoid. Everything to create a rock solid, simple to grasp, and difficult to refute, line of thought.
You don't want to be easily proven wrong. So each phrase you deliver is like a chess move: you must anticipate 10 different ways it can be refuted and have responses for each. Which is why you need to practice. Write, talk as much as possible, no matter the event. It's not about the size of the audience and your ego, it's the opportunity to get exposed to an audience with little risk. Only tackle a large audience once you're confident that you can defend your arguments. Calibrate your weapons before you use them. When you start tackling the WHY you may be provoking open wounds on the audience, so better be prepared.
But if you don't go for the WHYs, it's way worse: you're FORGETTABLE. You get applauses that the end, and after an hour no one remembers your name. What is the purpose of a speaker no one remembers later? Or a speaker that is funny and people remember the jokes, but can't remember the content of the talk? So they sympathize with the speaker, but the message is irrelevant. If you want to be an actor or comedian, that's fine. If you want to convince people of a certain point of view though, that's failure.
And the same goes for writing. You should've learned this in school. If you ever went through college and had to defend a thesis you SHOULD KNOW that the dissertation HAS to be divided in at least 3 sections: Introduction, Elaboration and Argumentation, and Conclusion. This is the WHAT, HOW, and WHY parts.
In a similar topic, if you're into Agile techniques. Do you remember the classic User Story structure? Most people find it super annoying. Every other Kanban-like tool forgets that: they just tell you "write here what you want". And most people just want to write the WHAT. Sometimes they write the HOW. But they feel lazy to think about the WHY.
As a X, I want Y, so that Z.
The 3rd section is elusive, but it's the ONLY section that matter. It's the WHY. Why do YOU want THAT particular feature? The WHY is the acceptance test. The Done Criteria. The only thing you should be looking for. We write what we THINK we want, not what actually NEEDS to be done. The User Story structure is yet another tool to bend your tiny reptile brain to use your more modern gray matter a bit more.
My goal is to bring attention to a point many speakers and blog writers are not doing: you're concentrating too much on the WHAT and the HOW alone and not exploring the audience's true concern: the WHY!
Again, whenever you see one of those cheap "my language is better than yours" theme and the argument is: "because in the benchmarks we can clearly see that it's 50% faster" or that "we can clearly see that it uses 50% less memory" or that "we can clearly see that it can run more concurrent processes at once". Those are ALL missing the point.
This is the HOW. It's fine.
But 95% of your audience will rarely empathize with those points. They will agree on a conscious level, but the subconscious will tell them the truth: "you don't have this problem." Most of the time their servers are idling, doing nothing. How good a 50% or a 200% performance gain will help them? It will not.
It's a major lack of empathy when a programmer, working on a big company, with many different teams colliding with big monoliths and legacy code decide that micro-services is the way to go. And now they "know" that if it's good for them, it ought to be good for everybody, right? Therefore, anyone doing differently are dorks.
They're not. Most of the other teams in the world may be small 3 to 5 people with projects that are yet to see the light of day. And here you have it: trying to implement your wonder over-architecture, and not getting any value back, because it delays their time to market.
Oh hey, their competition caught up, released first, they lost time to market, and all because they trusted your narrow sighted opinion, your lack of empathy with your audience. And this is the case when they listened to you. Most of them already forgot what you said, because it never touched their true concerns anyway.
And I am also to blame, I do this sometimes. In the beginning of my career I did it more, and the older I get the more careful I become on how I craft what I want to say. It's very difficult to see beyond our small routines. It's difficult to communicate with a larger and diverse audience. But if this is the role we chose to pursue, we must do better.
I hope this gave you some insights in how to structure your pitch in small to big talks or individual interviews or writing your blog post. It's all the same: WHAT, HOW, and least but not last, WHY!