Yes, this is what my co-workers refer to as an if-statement.
Apologies to William James' apocryphal quote.
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.
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.
Code is generally the easy part once you know exactly what you're doing.
Not least because it's really the product designer and product owner's job to make this kind of chart.