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.
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.
- the site took 23 seconds (!) to load
- all content is hidden below the fold, with just some kind of animation visible. I assumed for a long time that the page was not loading. Nope - it's just not visible until (if) the reader scrolls down
- after a couple of refreshes, the user is treated to a modal imploring them to sign up for a newsletter: "You love us.
You really love us!" no I don't
- there is also an email form at the bottom begging for subscriptions. There is a JS dismiss button that doesn't work
Actually, considering the above, I am not sure anyone should take Braze's advice about hiring product managers.
Also in most of those companies the marketing team doesn't talk with the product team, as a result the marketing content has nothing to do with the actual product
Looks like they do direct sales which makes things like loading the website and "below the fold" significantly less important. Their focus is on lead generation so they can get sales folks talking directly to whoever the buyer persona at the company.
Source: I'm a PM at mid-size enterprise software company with 6 1/2 years experience.
The way the site is made, if it feels like "just marketing hype", it does contribute (I agree with not-so-much-relevance) to the opinion I form on the company and/or the product (not unlike as it was the case once for the business card, from the way it is printed, the material, the titles given to the person before you, etc. you can derive some indicators).
Biggest issue I've seen in different companies with hiring pm is not really about choosing them but more about empowering and trusting them when they start working.
If you assess them on being a product manager, and then ask them to do project management stuff it is a lost of time
Regarding empowerment/trust: those factors are definitely critical to PMs' success, but I'd also argue that finding folks who can thrive with this independence is itself important. We've had success with defining clear areas of ownership within our product, within which PMs have substantial autonomy.
Regarding project management: I couldn't agree more. But at the same time project management does need to get done, and PMs are often well positioned to help. I generally feel that PMs should be accountable to making sure that effective project management is in place for the teams they work with, whether by partnering with designers/engineers to set up efficient processes or hiring/designating dedicated project managers (but not necessarily directly project managing themselves).
Similarly, the questions that each interviewer is being asked to dig into are good, but many of them are fairly self-evident. Of course the design team wants to ensure the PM can work well with designers, but what I love to learn from other companies is how they assess that. Some teams do homework, others do design exercises during the interview and others have the candidate talk through what's well- and poorly-designed about an app they use.
I'd definitely be interested in a follow up that gets further into how interviewers assess the relevant questions.
I'll throw in a mildly shameless (but relevant) plug for a book I just finished about interviewing for PM jobs: https://www.amazon.com/dp/B07TCRCG69. It's focused on how a candidate can succeed, but it goes through the interview process and some detailed questions that I have seen as a candidate and asked as an interviewer.
Agreed on your point. I didn't go into a ton of depth about the details of the interview, but fwiw this is always addressed in depth during the course of the product case, and touched upon during phone screens.