Hacker News new | past | comments | ask | show | jobs | submit login

Honestly this process needs improving. It’s quite fine as an overall principle: it wants to make sure the PM understands product, as well as has a sense of the trifecta of design, technology and business thinking. It’s roughly based on the process Facebook has, which is nice. That’s the basics of the job, and they’re covered here.

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.




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


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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: