The Three Skills of a Google Product Manager
One of the things I’ve picked up on over the course my career is just how much respect there is for Google Product Managers. I don’t disagree — some of my favorite PMs have worked there. On the other hand, many of the people I really respect haven’t. So what’s the difference between a Product Manager (PM) who worked at Google, and one who hasn’t?
I’ve been asking around. Last time I was in San Francisco, I had the chance to ask Ken Norton and he clarified it for me in a way that I wanted to share. This explanation aligns with what I’ve heard from other friends (internal and external perception) — but it was by far the best framing I’ve heard.
(0) Google helped standardize “Product Management.”
I’ve written about this before — but the origins of Product Management are nebulous. It stems from Brand Management and Program Management. Google was one of the companies in the valley who had an established discipline first. This means they set some of the standards for what we want the discipline to be. This isn’t really a difference now that it’s spread, but it is important context.
(1) Technical Respect
This has been talked about frequently, but Google is an Engineering-led culture. This means you can’t get things done if you don’t have the respect of Engineers. Having had a Google PM job for a significant chunk of time means you did figure out how to achieve this.
If you are somewhere that engineers “have” to do what you say, you haven’t achieved this.
Google does not scope projects to PM-experience. Even APMs are thrown into large areas. This is different from many companies who don’t want the “risk” of having a new PM own something large. This is also different from political companies where there isn’t enough work, so there’s political infighting to “own” things.
This resonates strongly with me — at Microsoft my first project was an app where you couldn’t do anything. You just clicked a link, and it showed you PowerPoint slides.*
When you have the privilege of owning a large area, you also have to be accountable for it. That means it has to either work — or that you dealt with the consequences when it didn’t.
Some organizations will say everyone is at fault when something goes wrong. At Google it’s more likely to be specifically the PM.
I’ve seen this happen in small teams where “we’re all in this together” and people don’t want to offend each other.
I think these are three great areas to evaluate a PM on, but the only way to learn them isn’t at Google. (And while you have a great shot of learning them at Google, I do know those who haven’t).
If you’re a PM and you haven’t mastered these three skills, it’s well worth figuring out how to change your role to include them.
* To be fair, the scope of this project was originally larger. Even so, my next project had far more PMs than were necessary. Too many PMs means a lot of time in meetings with other PMs, not enough time getting things done.