I agree with a lot of this, but disagree with the final conclusion that Product shouldn't define what is going to be built. Everything listed in TFA is something a good PM and a product-minded engineer collaborate and iterate on. At the end of the day, I think the article is really concluding that "bad Product Managers shouldn't define what is built."
The actual issue with Scrum is that APMs and others who identify as "Product Owners" often aren't trained or equipped to be good at actual product management, because they are focused on a fake set of JIRA-focused responsibilities. A "Product Owner" is really a software development project manager who uses a ticketing system to micro-manage engineering work.
The result is that scrum POs are bad Product Managers. Their role has little to do with understanding user needs, establishing and communicating a vision of a product's philosophy, or assessing the success of a feature once it's out in customer hands.
Scrum ends up wrong on two fronts:
* It has no idea how work is prioritized (much of the actual work of product management), and
* It thinks that "priorities" are a well-ordered list of discrete development tasks rather than features, and assigns much of the engineer's role to the PO.
It's as if Scrum defined a new role called "chief financial owner" who is responsible for making sure the columns are aligned in the annual financial statements, and then the job market was flooded with thousands of people with two years of experience saying "I'm a CFO" and we got hundreds of think pieces about why all these companies were having trouble managing cash.
The actual issue with Scrum is that APMs and others who identify as "Product Owners" often aren't trained or equipped to be good at actual product management, because they are focused on a fake set of JIRA-focused responsibilities. A "Product Owner" is really a software development project manager who uses a ticketing system to micro-manage engineering work.
The result is that scrum POs are bad Product Managers. Their role has little to do with understanding user needs, establishing and communicating a vision of a product's philosophy, or assessing the success of a feature once it's out in customer hands.
Scrum ends up wrong on two fronts:
* It has no idea how work is prioritized (much of the actual work of product management), and
* It thinks that "priorities" are a well-ordered list of discrete development tasks rather than features, and assigns much of the engineer's role to the PO.
It's as if Scrum defined a new role called "chief financial owner" who is responsible for making sure the columns are aligned in the annual financial statements, and then the job market was flooded with thousands of people with two years of experience saying "I'm a CFO" and we got hundreds of think pieces about why all these companies were having trouble managing cash.