The issue is that "Product Owner" is a project management role for micro-managing an engineering team, and it has little to do with Product Management.
Product Management should output a clear vision of customer problem and solution philosophy, and a feature roadmap that gets there. Too often, the feature prioritization is handed down from above, leaving the PM with nothing to do. So they apply the idea of "prioritization" to components of the engineering work itself and spend all day "grooming tickets" instead of talking to customers.
This makes engineering managers worse at their jobs, because they use their PM as a crutch for figuring out how to deliver a feature completely and correctly. It also makes PMs worse at their jobs, because they spend all day doing SDLC project management and not even realizing that it's a totally different job from Product Management.
Doing a set of features in the _wrong_ order can increase the time to deliver by 300%.
Things like many-to-many relationships, data versioning, etc are easier to implement if they’re done earlier as opposed to done later, where they have to retrofit.
A non-technical PO having the authority to decide which features are done in which order is one of the biggest problems of scrum. Especially true in the first weeks/months of the project where critical infrastructure and architecture needs to be set up.
A PO can and often does undermine the developers’ ability by mandating them delivering the software in the least efficient way possible.
Good call. I tend to focus on the issues related to Product Owners dictating _what_ to build, but just as much or more damage can be done by messing up the _order_ in which it gets built.
The issue is that "Product Owner" is a project management role for micro-managing an engineering team, and it has little to do with Product Management.
Product Management should output a clear vision of customer problem and solution philosophy, and a feature roadmap that gets there. Too often, the feature prioritization is handed down from above, leaving the PM with nothing to do. So they apply the idea of "prioritization" to components of the engineering work itself and spend all day "grooming tickets" instead of talking to customers.
This makes engineering managers worse at their jobs, because they use their PM as a crutch for figuring out how to deliver a feature completely and correctly. It also makes PMs worse at their jobs, because they spend all day doing SDLC project management and not even realizing that it's a totally different job from Product Management.
In software engineering, ORDER MATTERS.
Let me say it again four more times:
ORDER MATTERS.
ORDER MATTERS.
ORDER MATTERS.
ORDER MATTERS.
Doing a set of features in the _wrong_ order can increase the time to deliver by 300%.
Things like many-to-many relationships, data versioning, etc are easier to implement if they’re done earlier as opposed to done later, where they have to retrofit.
A non-technical PO having the authority to decide which features are done in which order is one of the biggest problems of scrum. Especially true in the first weeks/months of the project where critical infrastructure and architecture needs to be set up.
A PO can and often does undermine the developers’ ability by mandating them delivering the software in the least efficient way possible.
Good call. I tend to focus on the issues related to Product Owners dictating _what_ to build, but just as much or more damage can be done by messing up the _order_ in which it gets built.