Product people will not. So we have the inglorious situation of 2 sets of diagrams and notes on the translation between them. If the problem was easy to solve, it wouldn't be something you can express in a sentence, while simultaneously asserting how easy it is.

Some people do not adequately constrain the problem while others overly constrain it, conceptually.

BPMN was created for product people. UML use case diagrams were created for product people.

I don't see the argument why product people don't need to learn this. They work in a software organization, they build software, they should be expected to know the diagrams pertinent to them.

Use Case Diagrams are only one small part of UML, usually the part people learn, but it's way bigger than that.

And the infamous stick figure diagrams are even only a small part of Use Case analysis and design themselves within UML.

> I don't see the argument why product people don't need to learn this.

They need to, but in my experience, they simply don't want to. They want to get the credit for the product, but they want to wave their arm and just have its features appear without actually specifying them.

I understand because it is hard, exacting work. But as it is specificity just gets pushed from product people down to the lowest-level person responsible for implementation.

Honestly ALL diagrams are a dead end, any system where there is no single source of truth will be a big hassle to maintain and therefore will not be updated which makes the whole thing useless.

The only which I can see working as it has already proven itself for certain tasks is something like the blueprints from the unreal engine but where each node represents something big enough to warrant its own node without any no low level details like variables, conditionals, loops etc. Otherwise you end up with literally spaghetti code.

This is an excellent point. You need to pull all the information about a system in a single place so that then you can choose what level of abstraction or deep dive into the details you need.

Projects like Multiplayer.app are in their early days, but I can see the potential of focusing on concentrating this info and automating the maintenance of docs and diagrams.