I clicked on this expecting it to be yet another reductive view point over-indexed on one particular aspect of a narrowly defined role, however I was pleasantly surprised that it does a pretty good job highlighting the nuance and context that plays into making good product decisions.
A lot of people (maybe most people?) want a playbook and roadmap for how to do their job. For a PM it might be: identify a problem based on data or customer feedback, conduct user research, ideate with design, get input from external stakeholders, build with engineering, run an A/B test and rollout successful variant. All of these things may be necessary activities in different contexts, but it's also very easy to lose the forest for the trees. The bigger and more complex a company gets, the easier it is to get lost in the process and over-index on the wrong details. I can't count the number of times I've heard lip-service played to "being data-driven" as an excuse to avoid tackling the bigger but less quantifiable problems of how a product is failing to meets its customers' high-level needs.
A lot of people (maybe most people?) want a playbook and roadmap for how to do their job. For a PM it might be: identify a problem based on data or customer feedback, conduct user research, ideate with design, get input from external stakeholders, build with engineering, run an A/B test and rollout successful variant. All of these things may be necessary activities in different contexts, but it's also very easy to lose the forest for the trees. The bigger and more complex a company gets, the easier it is to get lost in the process and over-index on the wrong details. I can't count the number of times I've heard lip-service played to "being data-driven" as an excuse to avoid tackling the bigger but less quantifiable problems of how a product is failing to meets its customers' high-level needs.