3 ms·

I would argue that a good PM doesn't need to be directly empowered, because by defining and communicating requirements clearly to stakeholder teams, the right p

I would argue that a good PM doesn't need to be directly empowered, because by defining and communicating requirements clearly to stakeholder teams, the right path forward becomes self-evident. I do think you need domain knowledge to be able to fully figure out what your requirements are, how realistic certain paths are over others, but I disagree that you need to be directly empowered to overrule engineering or design decisions. 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

leshokunin 7y ago
That's the prevalent opinion about PM, and I used to adhere to it. I don't think it works in practice. Design informs technology. Business informs design. All those things affect each other to make a good product. You can't do that if teams can't just say no to each other. It's important that they can. Having a say in things doesn't mean that teams need to fight each other and undermine decision making. It means they can convey what they think would be neat, and try to think outside the box to meet each other's needs. 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.

leshokunin 7y ago

That's the prevalent opinion about PM, and I used to adhere to it. I don't think it works in practice. Design informs technology. Business informs design. All those things affect each other to make a good product. You can't do that if teams can't just say no to each other. It's important that they can. Having a say in things doesn't mean that teams need to fight each other and undermine decision making. It means they can convey what they think would be neat, and try to think outside the box to meet each other's needs. 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.