Product Owners Are Not Backlog Managers

> I don't know why the job postings make the backlog the focus of what they're looking for.

Because the delivery team is actually expecting a workable product backlog and you're responsible to deliver within your role as a product owner among other duties. If you wanna do something else, then let it be, but the term product owner has a specific meaning within the scrum framework.

I dislike this type of thinking. Thinking the job will get done by somebody else because it isn’t “your job” is a disaster for everyone. Sometimes you have to play a certain role depending on the dynamics of your team(s).

Product people should read more books like “Build What Matters” or “Escape The Build Trap”. They are much more practical.

The way I've seen it actually work (and I have been both PM and PO at the same time) is that the PO gets epics and possibly stories from the PM or director, and is responsible for fitting the most important epics into the next sprints.

Yes, it includes bs like being able to on the fly answer or estimate, when will this ticket from two months ago. And if you don't give an answer right away you're "not as on top of things as I would like".

PO is a garbage role. And in practice it is focused on backlogs and standups and sprint planning.

Usually PO is there for the non technical PM to not have to talk to engineering.

> I don't know why the job postings make the backlog the focus of what they're looking for. I can only imagine that hiring managers and recruiters have a very poor understanding of product management, reducing it to the mere management of open issues in the backlog.

It's not just hiring managers and recruiters. A large number of senior leaders in organizations have a very poor understanding of product management as far as I can tell.

Feature factories are much easier to implement/understand and fit more neatly into traditional structures.

In my experience, POs are a glorified middle man with an unclear role that acts like a mini CEO and just stands in between developers and the outside world.

In their most useful, the best they can do is stay away and not bother the devs and learn as much about the product and how it works so they can appear useful in sessions with outside stakeholders. In their least useful they are a broken phone and nothing more than a ticket pusher and micromanager.

I believe how this job was created, was that some business types wanted to have full control and overview over what the devs are doing, so they created a position where they can embed one of their own, to give them a piece of mind that one of them is in control of what devs are doing. The job requires lots of talking, status reports, and ticket creation. It's basically a receptionist but with made up significance and influence disproportionate to experience or reason.

The PO is basically inversion of control: let's select the guy with the least hand on experience of building something, least hands on experience in the problems of the product, and make them call all the shots on what gets built and when, ignoring the devs, cause how they can possibly know, they are code monkeys.

Product owner is a stupid concept. It’s make work.