> 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.
You may consider "product owner" a term, but I take these two words at face value.
Product owner is the person who can make decisions on product features and the development priorities.
Whether they actually arrange the backlog or fire orders or participate in aparté meetings with analysts who then pass the outcomes into the backlog is not essential.
Yes, and i have seen teams working entirely without a formal backlog of user stories. Some use a large wall chart, some use a User Story Map without any kind of Scrum of Kanban process... in some teams this also works.
well, this seems detrimental to a discussion because as far as I know the term "product owner" was coined by SCRUM and has therefore a defined meaning other than say Product Manager...
The guide is says pretty much what i say. "How this is done may vary widely across organizations, Scrum Teams, and individuals."
OTOH, The humane, real-world understanding of the word "product" and the word "owner" coming together should prime over whatever definition there is, because none reads definitions except for the purpose of an argument ;-)
No, i'm not even sure if you're arguing here in good faith. The next sentence after the one you cited clearly states with examples:
"The Product Owner is also accountable for effective Product Backlog management"
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.
There’s no justification for it to exist. It’s like saying every bus needs a steerer and a gas pedal pusher. This is worse than a single driver, but hey it creates another job
DB specialists are make-work too, unless you are working at AWS or some other massive provider. Architect is also make-work. Someone who makes technical decisions and orders engineers around but doesn't code. LMAO.
I worked at a large telco, between prod and dev and test we had a couple of hundred oracle dbs running, plus probably that again in vendor supplied odd custom stuff.
DB Specialists were essential.
We also had an architect who was trying his best to keep track of everything, design the future and attempt to keep in all almost sane. It was a ginormous mess. Without him it would have been utter chaos.
The value of any given role depends on the org and context and situation
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.