Even as someone who uses CQRS/ES on a daily basis, I don't expect most engineers to know them, just like I wouldn't expect a lot of engineers to know "currying".

Tech is a big field, it has a ridiculous amount of vocab. Unlike Doctors, we didn't standardize heavily.

The medical field is big too. The point is that it's your responsibility to learn things, not expect every piece of jargon to be explained to you.

I think you missed op's point. They weren't seeking an explanation, they were pointing out the initial sales pitch was too jargon dense as to be meaningless. The initial sales pitch might as well be in ancient Greek for your average engineer.

That doesn't make sense. Of course it's meaningless if you don't know the jargon.

The op says the product devs should "put in effort" otherwise the op will "skip over it and move on". This is backwards because it's up to you to learn things you don't know.

As a professional of course I try to keep up with industry standard terms and jargon. My point still stands because it's not about my lack of knowledge.

My point is that your elevator pitch, and what's on the landing page of your website, shouldn't tell me what cool buzzwords you use in your tech stack. Potential users / customers generally don't care. They care about how it benefits them.

> It's on you to know those concepts so you can understand these terms.

It's not if you want me as a customer. I don't have the time to look into the literally thousands of projects out there asking for my attention and then to learn the jargon to see if the project perhaps meets one of my current needs. Usually it doesn't. So if you want my attention, tell me how it benefits me. It's not going to hurt me to skip over it. A smaller project that gets no attention will just eventually die. So small projects / startups need to make their value proposition very clear if they want to stand out from the crowd. That's why incubators like Y Combinator insist you spend the time to get your elevator pitch right.

> Would you read technical descriptions that a doctor would be familiar with and complain that they don't explain all the basics for you?

If I were a busy doctor, I would want to start with the one liner "treats depression faster than other drugs in its class and with fewer side effects". Now I'm interested enough to read the tech details and why.

Bad: React is an ES 2015 JS framework that uses JSX along with Babel and Webpack to create a virtual DOM along with efficient tree diff algorithms to prevent unnecessary renders.

Who cares? It sounds like a bunch of bragging about implementation.

Good (from their landing page): React makes it painless to create interactive UIs. Design simple views for each state in your application, and React will efficiently update and render just the right components when your data changes.

Now I know how it benefits me. Almost zero jargon, and what jargon they use is very basic.

I hope that helps you understand where I'm coming from. Which is an attempt to help startups and small projects get their one-liner / elevator pitch right. Get it right, and then I'll be interested in how you implement it.