3 things I wish I knew when I was applying to Google’s APM program
I just finished my first year as an APM at Google. My journey started 3 years ago where, after attending an info session on Google’s APM program, I decided to submit an application. Here are 3 things I wish I knew back then.
1. What a PM actually does 👨💻
“PMs are the CEO of the product” is perhaps the most common analogy for the role of a PM. But that’s not exactly right. For one, PMs, unlike CEOs, don’t have any direct authority over their team. It’s also not particularly helpful since it doesn’t really explain what that means for your day-to-day.
As I see it, a PM is responsible for 2 things:
1) Deciding what product/feature to build
PMs are responsible for determining what to build, which means that PMs need to understand who their users are and what needs those users have.
In practice, PMs do this by analyzing a lot of data, conducting user research (possible in partnership with a UX researcher), and talking to sales, marketing , or even the users directly. The very best PMs are also able to work closely with engineers and translate technology directly into marketable products.
The PM will write up their proposal in a product requirements document, or PRD for short.
2) Ensuring the product/feature is successful
After deciding what to build, the PM isn’t off the hook. Instead, they’re now responsible for ensuring it gets built well, successfully launches, and continues to be an excellent product.
If there’s something that needs to happen for the product to be successful, it is the PMs job to ensure that it gets done.
If that sounds kind of vague, that’s because it is! It could involve things like: creating wireframe mocks, running weekly check-in meetings, working on a marketing or sales plan, obtaining launch approvals, triaging bugs, tracking success metrics, and many more!
2. How to prep for interviews 🧠
PM interviews are hard, especially if you’ve never done one before. The good news, though, is that with some effort you can get a lot better at them!
Preparation materials
There are dozens of books, websites, and articles on PM interview prep. But Cracking the PM Interview will get you almost everything you need to know. Read the book, then re-read it. Then practice!
Practice, practice, practice
By far, the best way to get better at PM interviews is to practice. If you can, try to find people who can mock interview you. But even if you can’t, you can practice on your own by going through the questions in Cracking the PM Interview or on thepminterview.com and answering them as if it were a real interview (as in, saying your answers aloud). You’ll know when you’ve answered well and when you haven’t.
Think like a PM
It also helps to think like a PM in your day-to-day life. Think about the different products you use and ask yourself:
- What user need does this solve?
- What do I like about this product?
- What do I not like about the product?
- If I were the PM for this product, how would I improve it?
3. Deciding between PM vs. SWE 🤔
A common misconception among aspiring PMs, myself included at the time, is thinking that PM is a more prestigious and higher paying role than SWE. To the contrary, Google engineers are at the top of the food chain and are paid more too!
So for folks with a technical background, deciding which role to pursue isn’t about which is “better” because neither is objectively better. But chances are one of them is better suited to your individual interests. So it’s about which role you’d enjoy more.
The best way to decide is to try out both. An internship is like a free trial of a job, so if you’re fortunate enough to be able to intern in both roles you’ll be best equipped to make the decision.
If you’re not able to try both out, think about how they differ and which you’d enjoy more. Here’s some heuristics that might help. Compared to SWE, PM:
- Involves deciding what to build, but not how to build it.
- Has little to no coding day-to-day.
- Is more focussed on breadth than depth.
- Consists of more collaboration with other people via emails, chats, and meetings.
- Doesn’t have as tangible output (i.e. you’re more of a facilitator).
