This is not about how it translates into code. I see a lot of value in this diagram when compared to the half-assed "requirements" most PMs put in their JIRA tickets.
That is my takeaway: PMs and non-developers - you must think through the entire workflow. When you don't, your engineers will and will either pepper you with questions that you are not prepared for or they will decide for you.
As an engineer, I consider fleshing out incomplete workflows to be one of the largest parts of my job. I've found the technique of saying "hey, the specification doesn't mention what to do in this situation, based on X/Y/Z elsewhere in the specification / this other similar feature, I'm operating under the assumption that it should work like <description of your best guess>. Let me know if that's mistaken". Then I make sure I have a commit of the state of the code, and start building based on the stated assumption.
A large fraction of the time, the PM just goes "that is correct", and the spec / ticket / whatever gets updated. When the answer is not "that is correct", you do lose out on whatever work you've done since sending that message, but writing code you eventually throw away isn't the end of the world. Also "that is not correct" responses often highlight areas where either the developer misunderstood what the PM was envisioning or the PM has a misunderstanding of what the system can do or how their proposed feature interacts with something else.
For this to work, you need:
1. Some variety of asynchronous channel that the developer can push stuff into at whatever frequency they want, and that the PM periodically catches up on entirely.
2. The developer to have a working understanding of how existing systems work and the system as a whole, from the business level.
3. The flexibility to modify specifications between the initial conception and implementation.
If you have all of those things, the PM doesn't necessarily need to think through the entire workflow beforehand -- it's nice if they can do that, but you can still ship working features without that and sometimes that is the pragmatic way to do it.
If you've thought about the entire workflow, all edge cases and the spec is 100% complete then you've written code, it's just a matter of whether humans or machines will compile it.
I find myself creating a lot of these diagrams to share with PMs (along with sequence diagrams, system architecture diagrams, decision tables, etc.).
Systematically articulating all of these different conditions isn't necessarily the strong suit of a PM, but they're generally quite capable of understanding and providing input to such documents.
I mean, the chart is still useful to have, and it'd be a couple of methods probably had I written it. But it's not a huge state space, and most of the transitions are fairly reasonable.
Which they never do to a satisfactory level (in my experience). So it still falls on the developer to do it properly, then PO just copies it for their presentations.
