Example of a bad pm who needs to directly invoke their power to make decisions: "This portion of the page is loading too slowly. Cache the thumbnails and make the autoscaling for its microservice more sensitive to fluctuations. I'll talk to the design team and have them lower the resolution of the images."
Example of a good pm who does not need to directly invoke their power to make decisions: "Page loading speed is a pretty big concern for our customers and I don't think this part of the page is loading fast enough. What options do we have to make this load faster? What specifically is preventing it from loading quickly in its current state?"
PMs do not need to figure out the "how to do", they need to figure out the "what to do" weighted by importance and feasibility. The other stakeholders are the ones that figure out how. Or at least that's the way I think it should be. Also I really agree with what you said about data driven decision making
Think about it in practice: you want to make a good camera. The engineers say they will approach things a certain way, the designers say they will produce a certain design, the PM says ok that sounds good, here is the roadmap and the strategy for this. You end up with a product that simply doesn't push the envelope, and has no cohesion. It's basically the equivalent of silos churning through their backlog. I think it's an underwhelming, underachieving view of product development, where no one grows.
That said, it also implies that the ownership of design is entirely on the design side, and engineering on the engineering side. That’s fine from the a decision making and accountability perspective, because it does empower experts to make their decisions. But the description of the process here is that it’s a silo. There is no expectation that the PM has coding skills, or design skills. There is no expectation of dialogue, only that they are a stakeholder that the teams will be happy to work with. Without empowering the PM (as well as the designers) to have a say on the engineering (and inversely), you’re going to end up with decisions that are made in silos. You just get a local maximum from your teams.
Similarly, none of the questions seem to be about metrics. Can the PM figure out where users will come from? How they will convert? What’s a good expectation? What are things to monitor? How would you translate those goals in a pitch for a feature? How would problems with metrics turn into items in the backlog?
The process as described paints the PM as a kind of super stakeholder, but doesn’t actually empower them with any sort of business, design or engineering weight. It could be that those items are covered in the interview, but the fact that they’re not articulated in the article does raise questions.