Teams often work this way in practice. The product owner has ultimate responsibility for choice and priority of stories, but like any competent leader, they will exercise that responsibility on the advice of their team.

If the team's programmers are "product-minded" [1], then the PO will be getting lots of input from them, and in a healthy team will be going along with most of it - the PO is in a "first among equals" kind of position. If the programmers are not like that (junior, new to the domain, just not built that way), then the PO will make the product decisions without them (but still with the support of a product designer, hopefully!).

There's an excellent leadership principle in the UK armed forces (and i'm sure elsewhere) that a leader must consult their subordinates before making a decision, but that once a decision made, subordinates must go along with it. The PM - programmer relationship around prioritization is an example of that.

[1] https://blog.pragmaticengineer.com/the-product-minded-engine...

It isn't black and white like that. The team always has a voice and can express it at any time. Communication is always key and that is the whole point of developers pointing stories. They could just call a story 8 points and the PM would never get it into the backlog. =)

Right, but that is different than the PM asking the development team what we should do this iteration.

The PM is the conduit between the business needs and the developers. The PM and the lead team dev decides the backlog. Devs just pick the next story from the queue, but of course they have input on things as well and can convey this in any of the meetings or directly with the core dev or PM.

Yes they can coney things, but it isn’t by default. Having conduits, etc. is a waterfall approach.

There are lots of devs who have a personality that benefit from having a leader (PM).

Also when you are doing the 101st CRUD type function in an app, you probably cannot be that enthusiastic about managing yourself either.

How can this state of affairs where developers grind out CRUD features and complain about how bored they are be stable? The identifying feature of areas where automation would be profitable is human boredom, and this is something where developers are the ones bored. Why hasn't all of the repetition in CRUD stuff been dealt with by now?

CRUD has been automated a long time ago. It's trivial to create forms with 120 fields based on scaffolding and automate the DB access with an ORM. It is time intensive to actually make software that is better than the paper equivalent. The scaffold puts everything on one page so you split it up into 10. You still have to interact with other systems to autofill form fields. Implement app specific access controls (only users in the same department can see each others forms, only X can actually edit). Implement the actual workflow (ask for digital signature from superior, send email, send end result to SAP or whatever).

Saying this is saying like "why do we need architects to design houses if all of them are just four walls and a roof?" Software engineering is not that different from mechanical or civil engineering or whatever other kinds of it. However you automate any design process, you'll still need engineers to properly utilize that automation, customize, verify, maintain (oversee manufacturing or software deployment) and fix problems.