A Product managers job is to police the backlog flow
A backlog being the repository of ‘stuff’ that needs to be done/built on a project can suffer from being a dumping ground for any half baked concept that may, or may not be of benefit to the end user.
I get a sinking feeling when a project reaches the point where the team is comfortable enough to take ownership of the project tools, and goes mad. Perhaps this is a natural part of the human condition, similar to the one that makes up thinks that another whiskey, or 100km enduro race is ever a good idea. We can end with a bloated backlog that is full of work that will disrupt the projects progress without adding value.
This is where a product manager can really shine. Their role in this scenario is to measure the value of items entering the backlog – eg. Does this item potentially represent to the end user. I’m not asking them to be omnipotent, the (for example) Technical architect, Business Analyst and User Researcher are invaluable domain experts for judging value.
In a traditional agile project using story points, and assuming the team is mature enough to have an agreed velocity, and that we’re reasonably estimating the size of backlog items, the product manager can then throttle the items moving into development, by value to the project and at a pace that team is working at. IE. not overwhelming them.
I’m describing a scenario here that uses lots of agile processes, and needs them to be mid-project - when the team are confident of their velocity. In less certain project stages (or projects), prioritisation according to potential outcome value is a reliable tool again within the Product manager remit.
