Moving from VMware to Google was straightforward for me in many ways.
At VMware, I was working on the compute virtualization layer and built a product that ran Kubernetes containers in micro-VMs. At Google, I still work on the “virtualization” layer (called Borg) except now, its containers all the way down.
The major difference between the two roles is that at VMware, I was a traditional external customer facing PM, which meant that all of the features and products I shipped were for paying customers. At Google, my role is that of an internal platform PM. My customers are engineers at Google and there’s a lot of them.
In terms of scale, my scope for impact, even as an internal PM is massive. Why? Because almost every Google app and service that you use runs on this container platform. That was honestly the biggest motivator for me to take on the role, despite any reservations I initially had about an internal PM role. At the end of the day, as a PM I care about a) having engaged customers, b) a large scope of work, and c) the ability to have a ton of impact. My role at Google gives me all three.
That being said, I want to set aside my current role at the moment. My friend Harshal and I talked about this topic a while ago and back then, I had no idea what it was like to be an internal PM. Now that I’ve experienced both sides, here’s my take for people weighing an internal platform PM role against an external facing PM role.
- As an internal PM, you have easy access to customers. Having a quick feedback loop makes such a big difference when trying to ship a good product. On the flip side, every customer (who is also an employee) has an opinion, and it is likely an intelligent opinion! Deciding when to listen to your customer and when to trust your gut becomes challenging
- External PMs face pressure from their largest revenue-generating customers to ship features, and ship them fast. On the internal PM side, most products aren’t revenue-generating. This can translate to a lower sense of urgency, which could be a good thing or a bad thing depending on where you are in your life and career
- Related to the above, as an internal PM, you have a captive audience of customers. If your product experience is crappy, your customers have nowhere to go. While this will show up in complaints from unhappy employees, it’s not as bad as paying customers voting with their wallets and going to a competitor
- As an internal PM, is the product you’re going to be working on core to the business or ancillary to the business? There’s great opportunities on both sides, but if it were me, I would aim to be as close to the core business as possible. For one thing, it’s easier to show impact when there’s less distance between the bottomline and what you work on. Additionally, whenever there is a slump in the industry, companies often slow their investments on the ancillary side of the business
- Prioritizing a backlog and justifying the development of a feature when you have external paying customers is kinda easy. Just say Customer X is paying us $30M and you can mostly convince your stakeholders. On the internal PM side, it can be nebulous and often defaults to the listening to loudest, most influential voice within the company. It’s hard to be objective!
- External products have sales teams, customer enablement teams, documentation teams, customer success teams and the list goes on. Internal products? Not really. Usually that means the PMs are filling this gap. Develop a feature but your customers don’t know it exists? It’s your job to inform them. A complex feature your customers find difficult to adopt? You are the customer service rep who needs to handhold them. Overall, there’s fewer support functions available to internal PMs
Clearly, one type of product role isn’t better than the other. Whichever path you pursue, go in with your eyes wide open and weigh the tradeoffs, because there are always tradeoffs!